Apache: Meritocracy, Consensus and Despotism
March 19th, 2005 by HenIt is oft said that Apache is a meritocracy. This is only half of the truth.
Apache is a constant choice between meritocracy and consensus. You decide if people believe strongly on an issue. If you think they do, you seek consensus and if you think they don’t you wax meritocratic.
This is a real trap for a pmc chair. A large part of the pmc chair role (in my opinion) is to fill in the gaps that are not being filled. A variant of ‘the buck stops here’; if there’s something that needs to be done, and no-one is volunteering, then the chair had better bloody well do it. Or at least form a press-gang.
This means that the chair is being meritocratic in many places, because they are filling in the gaps that people don’t care about. I find this is amplified in an umbrella project, like Jakarta, because much of the caring is focused on the subproject level rather than the project level. Thus one can find oneself being meritocratic on relatively weighty issues and the direct community to gain consensus from is actually very small. Thus may be born a despot.
Despotism is no bad thing in the short term, but in the long term it creates reliance on a singleton and as we are all mortal (attention-span of 2 years it seems) the loss of that singleton can sap momentum.
This is a key ingredient of the Apache way, avoid despotism to achieve better community health.
It would be interesting to create a worthless metric by which we run a script against a CVS repository to analyse the likelyhoods of despots and alert if they are found. The same thing would be useful at companies, please list codebases where we lack knowledge failover.
Back to Apache, one method that I have found very useful is the announcement-of-meritocracy. It goes much like this: “I think XYZ should happen, if I don’t hear a -1 by XXXDay, I’ll go ahead and do it. “. This is effectively an invitation for a consensus discussion and while it’s unnecessary for most activities at Apache, it’s very useful for a chair who is trying to avoid the slide to despotistry. Much of the Jakarta site overhaul has been founded on this trick.
Another classic, and obvious, method to deal with the consensus/meritocracy choice is the mock-up. Decide something should be done, do it, but don’t apply it to CVS/production. Instead put it up privately, call for opinions and then call for a vote. This is a general rule for sales anywhere, but it works well in open-source communities. It has the same dangers as it does for a business, don’t spend too much time on the mock-up as a failed vote may depress.
One of the best things about managing/serving an open-source community is that your coding itch starts to click on new subjects. My Jakarta thoughts nowadays are centered on how we can create an index of Jakarta, in which the subprojects can continue to be highly autonomous; and how we can apply that to the rest of Apache. Then how we can add associations to that so that the Java@Apache association is obvious.
Interesting stuff, but to a large extent sitting in the cracks and a great stick bun on despotability. Fortunately there is a group of people interested in the same thing, other pmc chairs 