Yes, it is, but in my humble opinion, not consistently.
Apache defines itself as a meritocracy. At the same time, the foundation's mission statement includes references to "collaborative software development". If I had to reduce the ASF into a single word, it would be collaboration.
The ASF is exemplary in the way it welcomes newcomers. Users are encouraged to post questions, however trivial, and developers are encouraged to make contributions, however minimal. The ASF culture is about openness and collaboration. Participation, even critical, is welcomed.
In his description of the ASF, Lars Eilebrecht talks about the chain of merit. A person is fist a user of software developed by a given Apache project, then becomes a committer, and later Project Management Committee (PMC) member, and usually after several years of devoted service, an elected member of the ASF. Thus, the "ideal" career path at Apache is user, committer, PMC member and ASF member.
In majority of cases, a project committer is usually also a PMC member. So, committer status is accompanied with voting rights. The said voting rights include veto power. If for any given decision, a committer votes -1 (a veto), then a 3/4 majority is required to override that veto. Given that a -1 vote effectively shuts down any proposal, most committers are very reluctant to use their veto rights. However, some committers not realizing the destructive power of their veto, make cavalier use of it.
Certain projects have an imbalanced committer structure, with one highly active developer, usually the project founder, accompanied by several less active committers. In such a project, given the 3/4 majority rule, it is entirely possible for a new and highly self-confident committer to bring a project to its knees by simply vetoing (or hinting at veto) new proposals. This deadlock can easily become permanent if the dissenting new committer can gain the support of just one additional other committer.
Had the Apache model been a completely fair meritocracy, a very active developer would have more voting power than a much less active developer. However, if the active developer dares to mention that he (or she) is more active, then, according to the currently prevalent ASF culture, he will loose a great deal of credibility. At present time, hinting at "leadership" or extra-merit is a socially unacceptable attitude at Apache. In other words, within the bounds of a single project and its associated group of committers, not only Apache is not a meritocracy, it involuntarily promotes a situation which can be described as "representation without taxation", a tongue-in-cheek reference to the slogan emblematic of the American Revolution.
In defense of the Apache model, I should observe that it is very simple. Treating everyone equal is the simplest representation model imaginable, and in case you had any doubts, simplicity is a highly desirable characteristic to have. The perfect equality in addition to veto powers gives everyone ample representation power, thus encouraging participation. As a committer, you cannot reasonably say "Why should I vote? My vote does not count." Nevertheless, the fact that a committer's representation powers does not increase proportionally with his contributions is cause for concern.
Do you think you can come up with a better model? If you do, I welcome your proposals describing social mechanisms where one's representation powers are adjusted according to one's contributions.
3 comments:
Hi! If you allow me to exert some "lobbing without taxation" here I'd suggest to keep the current model. Not because of its simplity but because of the atmosphere. Havin lurked around for a short time as a junior committer I'd say that the equality during voting had been invaluable to me. Not that I dared anything significant or imagined I would actually contradict any of the senior members. But psychologically this felt as a "borthehood". And that was precisely due to the percieved equality in decision making.
On the other hand of course I'd witnessed disruptive behavior too. My guess is that a two-tier system could be used to break deadlocks.
For example if a project chair feels things are going out of hand he could invite other senior ASF members with experienced in conflict handling. Perhaps these could be distinguished members comprising some sort of "social guidance committee".
Many options are open to what could happen next. One possibility is that these individuals would be allowed to cast their votes breaking the 3/4 deadlock. The important thing here is that this would need to be people which would use their reputation more than their position and voting powers.
So ASF members with most merit wouldn't have their rights boosted in their "home" projects - which IMO would decrease the "bus factor" and potentially damage the community spirit - but would instead grown in their ability to intervene and be the judges in conflict situations arising in other projects. Which is still a kind of meritocracy.
Well I guess this is not very different from the existing model - but hey I've said that I like it already :)
Hi Anton,
As you mention, there are ways of circumventing deadlock. However, involving senior Apache members (e.g. board members) goes contrary to the definition of a meritocracy. Presumably, board members have not worked within the project in question; and thus should not wield any power beyond the oversight for the application of the foundation's rules.
I think the person inventing simple rules for attributing voting rights according to one's merit would do a great service to collaborative development.
Happy holidays in the mean time ,
Well, actually I found that tiered rights seemed to be the highly workable solution.
At the top: The benevolent dictator(s).
From there on down you have different tiers that each have different rights and responsibilities.
Disadvantages: If the dictator(s) are terrible, then the project suffers. This could be possibly alleviated by a voting system to make it an "elected dictator"
Advantages:
-The more you have put into a project, the more rights you have, and the last time I was working on an opensource project, the "core developers" had veto power only overrideable by the dictator. It helped core developers ensure that the library they had put so much effort into didn't get pulled in a way that was detrimental to their needs.
Post a Comment