If you have never been involved with an open source project, one of the great sources of mystification (and anxiety) for you might be how a group of people spread out all over the world with a wide range of motivations can come together to work on a complex project and produce something coherent and useful. Of course, we know that such things do happen. (For a beautiful illustration of it happening under conditions of extreme lack of visible coordination, watch Jon Udell’s classic analysis of the evolution of a Wikipedia page, Heavy Metal Umlaut.) We know that it can work. But, from the outside, it’s hard to understand how.
The truth is that there is a wide range of governance structures that work for different open source projects, and none of them are particularly mysterious once you come to understand them better. Some projects, like Moodle and Linux, have structures that bear some superficial resemblance to normal management structures in that they have strong central managers who make a lot of final decisions. I say “superficial” resemblance because, in many cases, these managers are acting as part traffic cop and part adjudicator, rationalizing contributions and suggestions for direction from all corners of the community more than they are giving top-down commands.
Other open source projects, like Sakai, take a more distributed approach to management. When they can, they tend to modularize the development so that small groups can work largely independently from each other and can reduce the coordination required to those areas in which their pieces have to work together, either from a technical perspective through integration or from a functional perspective through, for example, common user interface conventions. For those functions where cross-module decision-making has to happen, the community develops mechanisms that look a lot like a representative democracy. In some cases, community members will vote directly on an issue that needs to be resolved. In other cases, they will select representatives to work together in a small group to work through the issues. Just how much (and what kind) of coordination is required depends on a number of factors. Software that has a significant user interface generally requires more coordination than software that does not. Programs where the modules share a lot of technical integration interfaces or services also tend to require more coordination than those that do not. Projects that are in the beginning of their life cycle tend to require more coordination those that are mature.
Over the years, the Sakai community has tried a number of different coordination structures. One of the most recent innovations (and experiments, really) is the Product Council (PC), of which I am a member. What follows here is my own personal meditation on how the PC came about, what function it is attempting to serve and how successful we’ve been at it so far.