Tuesday, May 25, 2010

Committocracy as an alternative for conflict resolution in OSS projects

I my previous post I presented an unsparing criticism of Apache's voting procedures. In this post, I describe a new voting procedure where each committer's voting rights derive from the number of commits made by the committer in question. To avoid rewarding micro-commits, only a single commit-point is awarded per day for one or more commits. No points are awarded for a committer who makes no commits on a given day.

Non controversial questions are settled by consensus. However, whenever a decision cannot be reached by unanimous agreement, a vote is called for. The commit-point for or against a motion are summed, the total accumulated commit-points determining the outcome.

Such a system endows a collaborative software project, open source or not, to reach agreement in a timely and orderly fashion. It is much less vulnerable to disruption by unscrupulous participants than Apache's current voting procedures. I designate an organization where voting power derives from the number of commits made by an individual, typically a software developer, as a committocracy.

Feasibility

Given any reasonably-open version control system, it should be fairly easy to write software which assigns commit points to each committer. During a vote it is a matter of simple arithmetic to tally the commit-points expressed for or against a motion.

In the case of git, the following command can be used to compute the commit-points accumulated by Alice.
git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l

Worse of both worlds or best of both worlds?

A committocracy is less efficient than the BDFL model for decision making, and compared to the Apache-way, it grants less power to newcomers. However, a committocracy is a fair system in the sense that the same rules apply to all. Today's committer with the most committer-points can be different than that of tomorrow. Moreover, compared to the Apache-way, a committocracy drastically reduces the risk of a project going haywire after admitting a new member. As a corollary, a project can safely reduce the wait-and-see period preceding the admission of new committers. Thus, newcomers may be granted committership status more quickly.

Psychological effects

Immediately after electing a new committer, accepting him or her as an equal member of the community has powerful positive effects on the psyche of the electee. In a minority of cases it results in the electee becoming a major contributor of the project. However, this positive effect is often short-lived. After a few months of modest activity, it can even transform itself to sense of entitlement which can be devastating at the hands of a less-than-scrupulous committer wielding veto powers. Fortunately, most people are fairly decent and do not abuse their rights in any blatant way.

In a committocracy, voting power accrues with each day involving a commit. As the entitlement of the committer grows with each contribution, the positive psychological effects of belonging to the community may be longer lasting, in particular because accrual in voting rights it is deserved, i.e. based on "merit". However, since I am not aware of any committocracy in existence, I can only speculate on the longer duration of said positive effects.

Is a committocracy a meritocracy?

No, not exactly. Granting one voting point per day rewards participants most committed to the project over a lengthy period. It does not directly take into account the value of each commit. In a very general sense, granting veto rights to all committers can also be considered as a meritocracy because it rewards participants with most endurance in arguments. It is just a different, and in my opinion less pertinent, measure of merit.

Does it matter?

What is the point of a committocracy , since it obviously does not perfectly capture the notion of merit? Moreover, why change the current voting system if only a few people complain about it?

While a committocracy is not a perfect or even a very good measure of merit, it is still a much better measure than a 0 or 1 switch correlative with veto powers. Since OSS contributors surrender so much of their independence to the OSS organization, in this case the ASF, the organization must ensure that its rules are as just as possible.

7 comments:

Christian Grobmeier said...

Assume a project starts in 2004. Person A develops it 2 years, earning 500 commit points. Then he looses interest and the project is near to close down. Person B starts to work on it in 2007. He also develops 2 years, but could only make 350 commit points. But those commits were very huge, refactoring everything to a new, higher level. The project gets public interest and A decides to come back.

He has not done anything for 2 years. But he has more commit points. Even when he doesn't know a single line of the refactored code, he has more "power" as person B.

Some of B's decisions are not good in A's eyes. He starts to refactor them again. B is frustrated and leaves because he has not enough power to veto.

I think community models are based on trust and respect. I don't think you can express trust and respect in math formulas. You can try, but I don't think it will be good. If you do it, then you should consider the criticality of a commit and the timeline of commits.

For example, commit points from 2004-2006 should in most cases not be as strong as commmit points from 2008-2010. In most cases, because if 2008-2010 commits are only touching details, then the previous commits are more critical to the project.

Ceki said...

You could modify the scenario with person A leaving having made 200 commits laying the general design, and than person B making 201 "minor" commits. B has done "less" to the project than "A" but has more voting power. It is easy to imagine cases where a committocracy is less than perfect. However, note that in both scenarios a committocracy does not perform worse than giving all committers veto powers. Wielding veto powers, if A *or* B decide to be disruptive, they can.

G. said...

I strongly believe that one should know who to add to a team before he does. The rest is trust. If a contributor works for 1 years on a project and you add him, problems might be minor.

Also in commitocracy there is usually always one leader who has the most power. Can he be overwhelmed if he has 500 commits and 4 others with each 300 commits veto against him?

I think the solution is more related to: how to find out whom to trust? Who is proceeding this project into the same direction and who is nitpicker and only working on his own ego?

Ceki said...

In a committocracy, the motion collecting the most commit-points prevails which is quite different than the motion favored by the committer with the highest commit-points carrying the day. So, if four comitters with 300 points vote one way, and the leading committer with 500 points votes the other way, the vote is won by the four committers because 1200 > 500.

Even two committers with 300 points carry more weight than a single committer with 500 points, as 600 > 500.

Jochen Wiedmann said...

Ceki, that's as good an idea as a moneytocracy. Obviously, the people with big money would argue that their voice should carry more weight, because they did a better job to the community by building business and so on ...

Thanks, but no thanks, let's stick to the good ole' meritocracy with all its disadvantages @Apache.

Ceki said...

How you got from committocracy to moneytocracy is beyond me. It's as preposterous as the equivalence between universal healthcare and Communism. There is some relation between the two ideas but certainly no equivalence.

Carl said...

@Jochen: No, this isn't a moneytocracy. It's not based on what you possess, but on your track record.

If a shop is considering which products to stock, and they make decisions based on the recommendations of rich customers, then that is a moneytocracy. But if, instead, they make decisions based on the recommendations of long-term, frequent customers, that is sensible.