CVS development group

This page contains Jim Kingdon's opinions on the CVS development group: how it functions, how it should function, and why we do things this way instead of other ways. Disclaimer: this page represents Jim Kingdon's opinions only, and is not the opinion of the CVS developer group. For the official policies, see the HACKING and DEVEL-CVS files in the CVS source distribution.

Quick Summary

The CVS development group consists of a set of developers who have gained admission to the development group by submitting good changes to CVS in the past. The developers make decisions about what sorts of changes to CVS are appropriate (individually, in the absence of controversy, or by a process of rough consensus, if needed).

The CVS Development Group is not a Democracy

Actually, few successful free software projects that I know of are democracies. The one exception I am aware of is Apache; I gather that they have a core group which votes on every proposed change to Apache.

Democracies have the danger of getting bogged down in questions of who is granted the right to participate, and how decisions are conducted (various kinds of votes, consensus processes, &c). They also probably tend to be inefficient (ranging from somewhat inefficient to totally nonfunctional), which is sometimes intentional in contexts like government but which is probably more of a problem for software development.

The CVS Development Group has a few democratic provisions, most notably concerning having the group reach consensus on accepting new developers. But few decisions are subjected to this type of formal consensus process, and there is no voting.

The CVS Development Group is not Run by a Single Maintainer

The model of a single maintainer is the most widespread and arguably most successful model for developing free software. Here are a few of the tasks which people try to assign to the single maintainer, and how we seek to get them done in the CVS development group.

Grant approval to each change to the software

In the CVS developer group, we expect the developer group to have a shared understanding of what changes are suitable, and for each developer to communicate with the other developers in cases where this may be unclear. Such communication is sometimes via formal policies and is often less formal.

Grant sub-maintainerships to other people

For example, this might take the form of maintainership of particular parts of the program, or the ability to make changes to the software subject to veto (reversal) by the maintainer. I don't know how other maintainers feel about this, but I'm not very comfortable making personnel decisions, especially unilaterally. The CVS developer group does have one key personnel decision: acceptance of new developers. This is done by a fairly involved process (albeit a somewhat informal one) which includes consensus of all the existing CVS developers. Given the centrality of this decision, it is better to err on the side of not yet adding a new developer.

Work with contributors

Most people who contribute to the software do not start out producing high quality submissions. They may not understand the coding standards (written or unwritten). They may not understand various technical considerations which control how the software is put together. They may not understand how the project seeks to balance adding new functionality versus stabilizing existing functionality. So encouraging and helping contributors is pretty much necessary, at least to some extent, if the project is to accept outside contributions. My feeling on this subject is that the more people who have a shared understanding regarding the project works, the more people who are capable of spreading that shared understanding. I also regard it as obvious that there is little point in making great efforts on behalf of everyone who shows up, and that one should focus ones encouragement on those who seem the most likely to contribute to the software. The most promising candidates can also endure a certain amount of neglect and still learn and contribute, in my experience.

Fix bugs

The reason for a maintainer to do this is in part practical. If the bug is obvious or easy to fix, it is often less work to just fix it than to try to process a great number of submissions and bug reports, which eventually converge on the correct fix. However, in my experience is it completely impractical to expect one person to fix all bugs. Even projects with a single maintainer generally do not have this expectation, as far as I know.

The CVS Development Group is run by Rough Consensus and Running Code

The model of Internet Rough Consensus is defined in [Crocker97] to consist of the following elements:

• Decisions made by those who show up.
• Decisions require participants to do their homework.
• Details developed by those who do the work.
• Progress requires balance and cooperation.

Here are some thoughts on how these principles are embodied by the CVS development group:

Decisions made by those who show up

For CVS development, the process of showing up mostly consists of participating in email lists, writing web pages, and the like. People who do not do these things tend to not get involved, or drift away from participation if previously involved. This is as it should be.

Decisions require participants to do their homework

This is perhaps the key element of this model (also embodied in the phrase "running code"), and is embodied in the CVS development group with measures such as the specification in DEVEL-CVS that developers should only use the mailing list to discuss changes which "someone plans to implement, or has implemented". Homework may consist of writing code, writing documentation, writing test cases for the test suite, explaining the rationale for one choice over another, and other such activities.

Details developed by those who do the work

Although in many ways CVS details are subject to review by the entire group (via the coding standards, for example), in many other cases details are left to the person who makes a particular change. Those who want to change the details may find they only can do so if they are willing to do the work of re-writing the code in question.

Progress requires balance and cooperation

It is not clear to me whether CVS has achieved this goal as well as we might, but I feel that we have been more successful this way than many free software projects. By success I mean directing our energy into productive directions such as improving the software and attracting new contributions (such as graphical user interface clients for CVS), rather than unproductive directions such as arguing.

For More Information

HACKING and DEVEL-CVS are available via cvsweb.

[Crocker97], "Evolving Internet Name Administration", D. Crocker, Consortium www.imc.org, 2 Sep 1997, http://www.right-net.com/SVCS-INET/9-2-97/tsld001.htm.

The most influential paper on free software development models has been The Cathedral and Bazaar by Eric Raymond.

"Free Software Business Models", Jim Kingdon, December 1996, has some introductory material on free software development processes but it goes into little detail.