Apache
The Apache Software Foundation is probably the most respected open source code community. Host to nearly 100 massively important projects like httpd, Subversion and Tomcat, it has thoughtfully and pragmatically built highly effective governance over a long period, tweaking its procedures so they work well without getting in the way of progress.
Many thanks to Jim Jagielski of the Apache Foundation for the data he provided for this evaluation. Unusually for these evaluations, I have not edited any of Jim’s text (apart from for layout) and agree with all his scores. It’s no surprise to me that Apache scores a perfect 10.
| Rule | Data | Evaluation | Score |
|---|---|---|---|
| Open, Meritocratic Oligarchy | How Apache Works | The so-called “Apache Way” has been sometimes characterized as “community over code” though that phrase is now deprecated. Instead, the ASF considers itself “community created code.” The main idea is that the creation and fostering of an open, healthy community will result in exceptional code.
The ASF goes to great lengths to ensure that a project is seen, and actually is, a community project, and not lead by any single person. By being a purely meritocratic environment, developers are able to quickly prove themselves and obtain positions of responsibility and authority. However, development is all peer-based; for example, whether a committer has been part of the project for 5 years or 5 days, their votes are counted the exact same; no one’s opinion is “more important” than a peer’s. This level playing field makes it easier for new blood to join projects and feel as integral parts of the community. At the core of the project is a group of individuals which are the PMC (Project Management Committee) members. This group has final authority over the direction and management of the project and the codebase. Due to the volunteer nature of the ASF, it is expected that this group will be transient in nature, and so the PMC will vote in new members based on merit and effort. The normal route is that new potential PMC members are first given commit priviledges (allowing them to actually commit code changes to the codebase), making them project contributors. After a period of time, as their merit and effort increase, they are recommended and voted on for PMC membership. Code patches and development is dependent on the “3 +1 Rule” which means that at least 3 PMC members must agree with and approve a patch, feature, software update, etc… before it becomes part of the official codebase. The ASF also allows for vetoes (-1) which, when based on technical reasons, can not be over-ruled or ignored. These protections ensure a more comprehensive buy-in of effort while limiting the damage possible by “rogue committers” (those extremely rare individuals that are not acting in the best interests of the project, the community, and the ASF). As noted below, the legal, corporate arm of the ASF (the board, the membership,…) does not control or direct the projects themselves. |
+3 |
| Modern license | Apache License 2.0 | The Apache License, a BSD derivative, is a modern, OSI-approved FOSS license. The AL places very few restrictions on the distribution of code, as compared to more “viral” licenses such as the GPL. The flexibility and freedoms offered by the AL allowed for more varied usage and distribution of the codebase, and allows for almost unfettered use in commerical and proprietary software.
The AL is ideally suited for software that implements Open Standards and Open Protocols or software which is designed to be a foundation for more extensive development. Software under the AL can be very easily used within software under just about any other license, open or otherwise. |
+1 |
| Copyright accumulation | Individual Contributor License |
The ASF does not require that the copyright holder assign copyright of the code or patch to the ASF or the project. Contributors are simply asked to signed an Individual Contributor License, which simply states that the person is authorized to provide the software to the ASF and the ASF can re-license the code. | +1 |
| Trademark policy | Policy | The ASF realizes that as a non-profit, public charity, our trademarks are important to the community and to the foundation itself, since they reflect the brand and the reputation of the projects. Because of this, there is a comprehensive, foundation-wide policy that all projects must enforce. This ensures that all communities are on equal footing and that all external agencies which may wish to use our marks (1) know the rules and (2) are treated equally. | +1 |
| Roadmap | Contributors | Projects are self-sustaining and self-directed entities. The “corporate” arm of the ASF provides no direction or influence over the directional roadmap of any ASF project. Also, since all developers operate as individuals, and not as representatives of their employers, no external agency (company, organization, etc…) can provide control or influence as well.
The roadmap is derived from the needs and desires of the developer and user community. A common phrase is “scratching one’s itch”, which means that if a developer thinks a feature would be useful, and at least 2 other developers agree, the feature or capability becomes part of the official codebase. There are no formal release schedules… if a project decides they want to create such a schedule, that is fine, but most projects operate under the ‘early and often’ rule. Of course, security patches are treated specially and will pretty much all the time trigger a release. There is a standard release process that all ASF Projects must adhere to. The key aspects of how the ASF works is that any PMC member may be the release manager (RM), and they can create a release pretty much at any time. To ensure adequate oversight, releases require at least 3 +1s from other PMC members (binding votes). It is also important to note that releases may NOT be vetoed. Once someone has taken on the mantle of release manager for a release, the responsibility for that release lies completely on his/her shoulders. All of this is to make as few restrictions as possible on creating releases, so we can ‘release early andoften.’ Of course, most RMs will float the idea to the project first (“Hey, I’m thinking about doing a release next week”) to gauge support or get some feedback. Sometimes the RM will decide to postpone the release due to the feedback but, again, that is his/her prerogative. All ASF projects use the normal X.Y.Z release numbering where X is a major release (not backwards compatible API-wise), Y is the minor release (API-compatible) and Z is the patch release. Some, such as Apache httpd and Apache APR also use a Minor Even=Official; Odd=Development numbering scheme (eg: 2.3.2 is a development version, whereas 2.4.3 is the “stable” branch). |
+1 |
| Multiple co-developers | As noted, ASF projects are built around the realization that developers will come and go, based on the fact that their are all volunteers. The community focus ensures that projects will survive the absence of any single developer. Projects are also designed to not be dependent on any external “sponsor” for work or support.
All ASF projects have seen this “ebb and flow” of developers and have handled that change. |
+1 | |
| Forking feasible | With the pragmatic Apache License, forking of any and all ASF code is extremely feasible. The open history of projects also ensure that the forked community has access to all the development knowledge throughout the history of the project at the ASF. | +1 | |
| Transparency | Mailing Lists | All development of projects, including code votes, roadmap discussions and the like are done in the open, on archived public mailing lists. Other methods of collaboration, such as IRC, Wiki’s, etc are avoided and discouraged due to the time-sensitivity to this synchronous methods and the lack of archival-history capability. Within the ASF there is a phrase “if it didn’t happen on the mailing lists, it didn’t happen at all.”
This openness makes it easier for new interested parties to jump in and get up to speed on a project. It’s creates a lower barrier-to-entry than other methods. The ASF also feels that the more open a project is, the more welcoming it is; full transparency implies that there is nothing to hide. It also ensures the level playing field so crucial for the continued success of projects: nothing is more damaging to open source than decisions made behind closed-doors, especially regarding software development. It creates a wall between the existing developer community and both the user community and the new-potential-developer community. |
+1 |
| Summary (scale -10 to +10) | +10 |
The full open-by-rule series is indexed on the Essays page.
Filed under: Governance | Tagged: Apache, Open-By-Rule |
Wild Webmink 
[…] ☆ Is Apache Open-By-Rule? Wild Webmink […]