Section 12.5. Commit Rights

12.5. Commit Rights

The question of commit rightsthat is, who gets to change the source files of a projectis a common ground for disagreement. Numerous open source projects have split over this. This is hardly surprising, since the source code is what defines what the product does, and whoever is granted sufficient access to a centralized SCM tool gets to define the source code. All product design and management is just wishful thinking until it becomes committed source code. Since commit rights are a sensitive issue, it is politically wise to make sure that changes to them have at least an agreed-on policy and a plausible audit trail.

In software companies, the usual procedure for deciding who has commit rights is quite simple: if you are paid to write code, then you have to able to commit that code. Nontechnical managers may sometimes also acquire commit rights, but their changes will be scrutinized carefully. Some methodologies declare that anyone in the project can modify any source file, but wise developers respect each other's work and make major modifications to source code written by other developers only after some discussion, or to fix a broken build. Occasionally, a truly irritating developer may be prevented from changing all files outside her given area, but this is a very strong sign of distrust.

In open source projects, the decision to grant commit rights is usually based on whose code the project leaders trust. Most projects have a personal email address or a mailing list to send requests for commit rights to. Most projects expect that the requester has previously submitted a number of useful bugs and patches to the source code for the project. When commit rights are denied, frustration tends to make the requester either give up on making contributions or flame the entire project and all the leaders. For this reason, it is helpful if open source projects describe what is expected of developers with commit rights and how to request commit rights; they should also clearly communicate the reasons for denying someone commit rights.

It's also helpful with open source projects if there is a document describing how to submit patches in a suitable format for project members to commit. Some projects have very specific requirements about how patches should be generated and what is needed in a patch (e.g., does documentation have to be updated too?)even the format of the subject of an email message is sometimes minutely specified. If you are dealing with hundreds of different patches, you will want to optimize how they are presented.

A related question is "Who gets read rights?" In closed source projects, this is often just the developers and their managers. Well-meaning sales and marketing people have inferred (and sold) features from the current, buggy source code of the next release too often to make it wise to give everyone in the company access. Open source projects give read rights to everyone, by definition; but again, just because there is functionality in the source code doesn't mean that it works yet.