My friend Patrick Masson has started an EDUCAUSE wiki page to develop a working definition of “openness”. I’m going to sidestep the hot debate around that topic and focus instead on the distinction he makes between openness and transparency, which he defines as “provid[ing] the stakeholder community access to–and perhaps even a platform to inform–the reasoning, debate, considerations, outcomes, etc. that affected an authority’s organizational, operational or strategic decision, whereas openness shifts authority for decisions to the stakeholder community.”
Transparency is a highly underrated virtue that often gets lost in conversations about openness. If you have the theoretical right to influence the direction of an open project, but you can’t practically exercise that right because you don’t know what the heck is going on (never mind why it is going on), then the value of openness to you is diminished greatly. Transparency is also vitally important for people and institutions that don’t care that much about open source per se but want to minimize their risks in adopting a product, whether it is open or not.
It turns out that meaningful transparency his hard to achieve, particularly in an open source community, where decisions are communal and distributed. You can’t expect everyone to have the time, knowledge, or skill to follow the listserv discussions closely (assuming that all the important conversations are happening on the listservs and not in chat or face-to-face), understand the context of the conversations, and follow all the implications. I think that’s one reason why some people get nervous when they consider adopting open source software. It’s very hard for them to understand how the software actually gets produced. And if they can’t understand it, then they can’t really trust it either.
Open source projects can be organized in a wide variety of ways. In Sakai, the community has a dues-supported foundation that facilitates the collaboration among the participants and generally tries to make the work going on in the community as visible and comprehensible as possible. What follows here are some suggestions for the Sakai-curious—as well as current members of the Sakai community who may feel like they’re a little bit out of touch with what’s going on—about how to better understand what the Sakai Foundation and community are up to.
- Start with the Sakai Executive Brief: Every six months, Sakai Foundation Executive Director Michael Korcuska publishes a report regarding critical activities of the community and the Foundation. They are very well-written. If you are just checking in from time to time and want to get an overview of current activity, the brief is the place to go. The latest one is here and the rest are here.
- Subscribe to the Sakai Announcements listserv: This email list will provide you with information about what’s happening in the big and medium picture without inundating you with lots of fine-grained details and community discussion. (Those are available to you on the other listservs whenever you’re ready for them.) You can subscribe to the listserv here.
- Follow the Sakai Foundation staff blogs: All Sakai Foundation staff are now blogging. This serves two purposes. First, since their salaries are paid for by membership dues, members can now see what they’re getting for their dues money. Second, because each of these staff members is facilitating work on some important aspect of project (e.g., quality assurance, plans and priorities for future releases, communications, etc.), following the staff blogs is a good way to get an overview of what the community is up to. You can find the Foundation staff blogs here.
- Check out the Sakai wiki: It used to be that the wiki was a mess and nearly useless to anybody who wasn’t already immersed in the details of Sakai development. That’s not true anymore. An enormous amount of effort has been put into wiki gardening. Now you can browse around, find some area of particular interest to you, and drill down into just those details without spending hours just trying to figure out how the darned thing is organized. The wiki is here.
- Come to the conferences: As hard as the Foundation and community work to ensure that as much relevant information is available online as possible (for example, any tentative decisions made in face-to-face meetings are surfaced on the listservs for community input and voting before final decisions are made), you just can’t beat live human contact for information density. Sakai hosts an annual conference and encourages regional conferences (not entirely unlike MoodleMoots) throughout the year. This year’s conference is going to be in Denver in June. The wiki page for the conference is still under construction as of this writing, but when it’s finished you should be able to find information about it from either the Sakai announcements listservor the wiki, and probably from the Foundation staff blogs as well.
Thanks for the great post, Michael. I’ll be getting Pieter to work on stealing this for the website and wiki 😉
“You can’t expect everyone to have the time, knowledge, or skill to follow the listserv discussions closely, understand the context of the conversations, and follow all the implications.”
This is spot on. Many folks, accustomed to models where they may not have an opportunity to participate, or “participation” is limited to the role of a consumer, may expect organizational decision-making (indeed any information) to be delivered (directed) to them as marketing or promotion.
For folks transitioning from consumers to prosumers, taking on the responsibility of self-organizing can seem daunting (how do I find relevant information?), futile (is this all of the information or the correct information?), and backwards (shouldn’t this organization be
keeping me up to date rather than me looking for updates?). However self-organizing groups is one of the most powerful resources of open communities. The members of these groups will have an affinity for the specific topic/issue because of their personal experience or expertise. Who better to drive development user-stories, use cases and solutions than the actual users dealing with the topic at hand as part of their day-to-day operational activities?
I think you are right, you can’t expect every member of an open community to have the time, knowledge, or skill to participate in all of the decision-making, and the best part is that they don’t have to. They only need to contribute to what is important to them. If everyone adds their best effort to their biggest itch, the whole project advances through the collaborative effort.
BTW anyone who has an affinity for defining “Openness” please feel free to help (if you have an affinity for that sort of thing).