How an open source project is managed defines the type of community and product that it will create. It is therefore critical that you put some thought into the suitability of the governance model of software you wish to adopt or develop.
In this post I’ll draw together a few recent observations about governance in various open source projects in order to highlight some common issues.
The WebKit governance model and Apple’s general lack of transparency are also issues that would negatively impact Mozilla if Firefox adopted WebKit.
This conclusion was derived from comments by Mike Shaver, Mozilla’s VP of engineering, published in the same article. For example:
I think we would have a hard time maintaining our momentum and depth of community empowerment in the WebKit setting. The level of visibility around patches and review is a lot higher in our world, as one example, and we don’t have bugs disappearing into an Apple-only bug system… We learned about fork maintenance and integration the hard way (and had to learn it a couple of times, to be honest), so that’s not trouble that we want to borrow.
In this case it can be seen that the Firefox team are unwilling to contribute to the WebKit project as they feel that they would not have sufficient control over the product to enable them to continue innovation in the direction they need.
Conversely, since Gecko adopts a very open development model it is used in a number of products that are quite differenct from a standard web browser (such as the Songbird music player, the Miro video player, and ActiveState’s Komodo IDE). Each of these products contributes development effort to Gecko and therefore contributes to its sustainability and quality. This is possible because Mozilla careful separate the web browser functionality from the core rendering engine that is useful in various web based applications.
However, managing an open development project is not without its costs. Balancing the demands of a diverse community and your own needs takes time and effort. The more open a model you adopt the more effort is required.
The trick is to carefully segment your product and to write a governance model for each sub-project that maintains control the control you need in key parts of the software stack whilst allowing a more open model in shared components.
Most models start off with all control in a single central location – thus providing a bottle-neck for the management of third party contributions. Over time trusted parties may be given control over specific parts of the system in order to spread the management load.
This can be seen in projects like the Linux Kernel, an example of a “Benevolent Dictator” governance model where all control is held by a very small number of individuals, in the case of Linux that is Linus Torvalds. However, due to the hard work of Linus (and a handful of carefully selected people) the Linux Kernel recieves contributions from a wide range of third party contributors, each focussing on a specific part of the kernel.
Getting the right balance between central and distributed control is hard. Ken Drachnik, marketing manager for open source software infrastructure products at Sun told OStaic:
we have spent quite a bit of time working on our open source governance models to ensure our communities are open to all and utilize the Open Source Initiative (OSI) approved open source software licenses.
It’s even harder when you have to balance the demands of multiple upstream components, Roberto Galoppini observes:
OpenLogic scaled federated support to hundreds of components and, by focusing on enterprise customers, found established development and governance best practices that themselves didn’t scale beyond a few hundred components.
Understanding how open source software is developed is vital to the success of your project, regardless of whether you are producing or consuming software. OSS Watch are are here to help you develop that understanding and will be running a “Community Building and Ooen Source Development Workshop” in which governance will be a primary topic.