Describes the different control mechanisms in Open Source.
Examples and illustrations.
In the first part of this series [1] we looked at some of the background that surrounds open source and software development. In this part, we will discuss and focus on successful open source projects and try to understand what makes them so successful.
There are two well known open source development models. The first model, is one most famously followed by Linux[2] and in some sense Perl[3]. It is often known as the "benevolent dictator" (BD) model. In this model, a well known authority or established figure is the overall controller of the entire project. Overall design and long term decisions are taken by this person. All bug fixes, coding issues and implementation details could be handled by associates or maintainers for the individual parts of the code. The name for this model stems from the fact that while the leader of the project chooses to remain neutral and evaluate proposals on their merit, once in a way, a particular design decision could be made by the dictator right against the code maintainer's choice. This privilege of pulling rank in an open source project is used rather infrequently.
In the case of Linux, Linus Torvalds[4], guides the code and in many ways, the overall direction that the Kernel takes (note the Kernel != Linux). In the meantime, he has been content to let companies battle to position Linux in various positions, as they see fit. By being neutral to the various niches, he can avoid seeming to lean towards any particular company or distribution. Larry Wall[5] has also performed a similar role for Perl, although with recent versions of Perl notably Perl6 [6!] this BD known as a "language designer", albeit that term is used as wine would be in a different bottle.
This model is highly adaptable and mobile. In the truest sense of the word, this model can allow developers to modify code quickly and easily to suit requirements. This model depends highly on the BD and his ability to foresee the eventual direction of the project, manage design issues and if the need arises apply bug fixes and write quality code
The other model is the one adopted in various degrees by OpenOffice, Apache, Mozilla, Debian[7] and the *BSD teams. In this scheme, there is no clear figurehead leader or controller. A team of various people involved in the project by their contributions, their skill and management abilities become co-ordinators. In a common scenario, it would imply that a core group of programmers actually are allowed to make design changes and set goals. A set of people at a lower level are allowed to commit code into the CVS (Concurrent Versioning System) Repository that is maintained for the code. Thus, bug fixes, security issues and other low level details can be maintained at a different level while the core group can concentrate on more important issues.
In the case of each of the examples, a core group exists which is usually composed of members of the community that are well respected. From time to time, the groups may recompose themselves [8] and add or delete members. From the evidence of the BSD lineage[9], this model is prone to forking. A fork in an open source project occurs when key members are unable to agree on critical design or implementation issues. Such members are then free to stop working with the current setup, and start on a new system altogether, using the current setup as a starting point. Forking, while seemingly negative and dangerous[10], actually leads to better focus and from the evidence that is present[11], better code and better software.
This model is scalable and less prone to individual idiosyncrasies. Decisions on controversial issues are mostly resolved by voting of some sort and thereby a fairer picture usually results. This scheme also allows for a much larger volunteer group to exist as the levels at which people interact are much clearly structured, leading it to be easier to manage
In both the models, some common elements exist. A program is developed in two clear phases. The first stage is when the code is considered "experimental", "bleeding edge" or "alpha". At this point, various features that are being considered are publicly debated upon and argued passionately till some form of agreement is reached. These discussions usually occur over mailing lists in which the eventual users and developers are present. Once features are fixed, various developers across the world could either in isolation or as part of a team write code that satisfies the requirements[12]. This code is then downloaded, complied, testing and sometimes even deployed by users, volunteers and developers worldwide. These development versions are often updated on a frequent basis and are usually distinguishable by a particular versioning or naming scheme. After sufficient testing and bug fixes are in place, the code is deemed to be a "stable" or "release" version. This is usually given a different version number. This version also has fewer updates and often the recommended version for average users to obtain
This phenomenon is most noted in the Linux distribution Debian which maintains a highly stable and relatively old setup for users while maintaining a highly upto date and bleeding edge version for developers to test. Most users in the open source world, when not unduly concerned about stability rarely ever install stable versions and prefer to be as bleeding edge as possible.
The essential reason why open source works lies in the manner in which the eventual users of the project guide the progress of the project right from the start. By being active parts of the process, they facilitate early prototyping and proof by demonstration about what is possible and what is not. Code is released early and released often. The source code being freely accessible allows more developers to examine the code and suggest potential improvements, bug fixes and other constructive criticism that can improve the code. Open source projects are often the clearest example of a meritocracy where you are often judged by the merit of your code and your suggestions. In that sense, as you argue either for or against some code, there is a large amount of ego gratification that can be achieved while still being constructive. In the words of Gerald Weinberg [13], this critical element is best termed as "egoless" programming.
Another vital and perhaps underplayed element of the open source model is that a large amount of chaos pervades the entire architecture. Rigidity and formalism are rarely any part of an open source project. From elementary chaos theory and evolutionary biology, we know that the most adaptive, dynamic and successful systems operate at the edge of chaos. Too much rigidity and the system dies as it cannot evolve. Too much chaos and the system is destroyed. The balance is what open source projects seemingly achieve the balance and operate at maximum efficiency. Consider this - from the depths of chaos theory and the rigidity of formal complex mathematics arise the strikingly beautiful and amazing fractals[14] that like open source will remain to be a marvel of this information age.
[1] http://www.geocities.com/madhumkurup/write/selling1.html
[2] http://www.kernel.org
[3] http://www.perl.org
[4] http://www.cs.helsinki.fi/~torvalds/
[5] http://www.wall.org/~larry/
[6] http://www.perl.org/perl6/
[7] http://www.debian.org
[8] http://www.bsdtoday.com/2000/October/News306.html
[9] http://www.cs.ruu.nl/wais/html/na-dir/386bsd-faq/part1.html
[10] http://users.andara.com/~sdinn/halloween.html
[11] http://www.openresources.com/documents/halloween-1/node4.html
[12] http://www.stsc.hill.af.mil/crosstalk/2000/jul/henderson.asp
[13] http://www.geraldmweinberg.com/Bookstuff/Each_Book/Psychology.html
[14] http://www.unizh.ch/~chaos/mand/