I recently attended to an interesting talk by Santiago Gala about the ASF, he talked us about the organization and other aspects of the project. I would like to speak about the organizational processes of the ASF as there are many interesting points:
The ASF is a nonprofit foundation that was created with the aim of establishing a legal entity to which companies and individuals could donate funds for the project. This legal entity also provides a mechanism to protect volunteers from legal attacks against any of the Apache’s projects and helps to protect the brand against potential abuses by other organizations.
The philosophy of the ASF is based on meritocracy, ie people with more merit get higher responsibilities. However, the merit can sometimes be difficult to quantify, for example, what is more remarkable: fix a critical bug or give legal advice to the project? Sometimes, developers tend to think that software contributions are more important but there are other contributions such as translations or answer questions for beginners, which are very valuable because they can help to attract new users and give a good image to the project.
The chain of merit within the ASF is:
– User: users do not have any organizational role but they contribute in a very important way, they report bugs, propose new features or help other users on mailing lists.
– Committer: committers have write access to the code repository. In order that the foundation can protect them from potential legal attacks they must sign the Contributor License Agreement (CLA).
– PMC member: PMC members are elected due to merit. They have right to vote for the community-related decisions and the right to propose an active user for committership
– ASF member: they have the right to elect the board (we will see later waht is this board), to run as a candidate for the board election, to propose a committer for membership and to propose a new project for incubation.
The ASF is governed by the following groups:
– Board of directors: the board manages corporate resources but does not take technical decisions. something peculiar about this board is that they use STV (single transferable vote) as a voting mechanism (a system to which minorities are well represented).
– PMCs (Project Management Committees): the PMCs are responsible for the technical management of the projects under the direction of the board. All decisions are taken in the development mailing lists so they are archived and new people can have access to this information. Private lists are recommended to treat personal issues (such as problems with a developer).
One of the most peculiar things Santiago told us was about decision making and conflict resolution within the ASF. They use a technique called “lazy consensus” on which three positive and no negative votes are sufficient to approve a proposal. A veto requires an alternative proposal or at least a clear technical explanation of the reasons for opposing. If no agreement is reached after a discussion and there are people interested in the proposal goes ahead, the person who made the veto has the right to try (by his own) to develop its alternative proposal (do-ocracy). This was proposed by James Duncan Davidson in an email to the tomcat-dev mailing list and was called “Rules for Revolutionaries“, James said that in open source software projects there is a natural tension between revolution and evolution, to allow both to coexist within the project he proposed that any revolutionary could establish a branch in which to go experiment with new code seperate from the main trunk.