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 leader—who is usually the inspired developer, but sometimes is someone else who is more suited to the task—starts 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:
Open source software is not planned, but evolves according to the changing values and goals of the community.
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.