The Committer Model of Open Source

Projects like apache or subversion have relatively small lists of committers who can cooptate new members on the basis of proven activity and dedication in offering patches which were accepted.

Such projects run —not democracies as they pretend— but oligarchies, or in fact, aristocracies. These are the people who speak of ego, and their social system retraces medieval history: some initial warriors caught domains which they retain and protect, and which become less accessible to newcomers as time passes, and the systems become more complex and less manageable. This model doesn't scale.

A committer will have the ungrateful task of applying patches submitted by contributors to the main line of development, which only she can access synchronously. The contributors access it asynchronously, i.e. they get it at the time of creating their patches, but as it is a moving target, and since there is a delay, by the time the patches get applied, the main line has drifted away. The committer is thus a serialization machine. She makes decisions based on the accidents of conflicts, and her perception of the contents of the patches. This is an unfair model, but even more an inefficient one, and one feeding itself since dark time is spent out of formal management in changing these perceptions (advocacy, lobbying, politics, etc.)

For one thing, being a committer requires dedication, i.e. is very much like being an (unpaid) employee. When I say unpaid, this is of course naive. The committers I know are paid in fact by companies precisely for doing this job of being a committer in some strategic project.

-- MarcGirod - 30 Dec 2007