Section 1.6. How Does Open Source Grow?
1.6. How Does Open Source Grow?So, there the inspired developer sits, with a handful of competent developers contributing to the project, all of them working away to make the software better. How does this work? The inspired developer is now the acknowledged leader of the project, but the position doesn't come with much authority. Frequently, no legal agreements of any kind define the relationships in the community, except for the open source software license used to declare the software's terms of use. Usually there is a shared source code repository, perhaps a web site that is used to organize the work of the project, and an email list that is used for communication. Any rules or structure are informal and are a matter of community acceptance and voluntary compliance. Very few projects have stated these rules in writing. The Apache Software Foundation's community process is a rare example of a formal process, but even this process must be voluntarily accepted. Because of this loose structure, an open source project is usually more like a high school rock band in a garage than the orderly and planned engineering process used in designing complex products such as automobiles. Rock bands break up and re-form quite often before (and after) they become successful. Open source projects are the same. As a result, an informal community culture forms. Generally, the project leaderwho is usually the inspired developer, but sometimes is someone else who is more suited to the taskstarts setting the agenda and making a few rules. For example, is testing important? Is backward compatibility important? Are users welcome to participate or are they an annoyance? Are decisions made by a group vote or by one person? The structure of open source communities can be all over the map. Some have a project leader and others have a community of developers. For example, the Apache Software Foundation is a meritocracy. There are no project leaders per se, but natural leaders emerge as they gain respect from peers working on the project. One measure of a programmer's status in the community is the level of access he is given to the source code repository. Some developers must submit source code to the group for approval. But others are allowed to make changes to the source code on their own. This is known as being a committer, and it usually carries a high degree of status. Any programmer who is a committer on the Apache Web Server project is hot stuff among his peers. The focus of all this community activity is on improving the software. Is there a plan or a roadmap for how the software will evolve? In most cases, the answer is no. Even in mature products used by millions of people, such as Apache, there is no written roadmap explaining what functionality will be developed in the current version and what will be added in later versions. There are just programmers writing code to make the software better. Open source software, then, can be thought of as evolving, pulled along by the vision of the project leader, the core group of developers, and feedback from users. If the need is focused, well defined, and well understood, the software usually reflects that. If the need is unclear and vague, the software reflects that, too. This leads us to the third principle of open source:
For IT developers and managers, this point is significant. It means that to understand how an open source project is likely to grow, one must first understand the shared values of the community. It is not uncommon for an open source community to change after the initial needs are met. The pace of change and the addition of new features might slow down dramatically once the project leader and developer community have achieved their goal. At that point, one project leader might step down and new leadership might emerge to take the project in a different direction. |
