Over the last several weeks, there has been a length discussion amongst Apache Foundation members about how the Foundation manages access to source control, with a focus on Subversion.
Anyone can read http://www.apache.org/dev/open-access-svn.html to see a summary of the central idea that started this discussion: that the default authorization scheme for Subversion at Apache should be to grant technical permission to commit to all committers across the Foundation. The purpose of this message is to start a discussion here about the culture of commit rights. The purpose of this message is *not* to create an additional debate about the UCB (universal commit bit) itself, which, at the request of the VP of Infrastructure, is happening on the operations@mailing list. (?Does Comdev have a Wiki?) Let me start by defining two terms: 'Commit Permission' and 'Commit Rights'. 'Commit Permission' is a _technical_ status. If you have commit permission, and you run an 'svn commit' command, it will succeed. 'Commit Rights' is a _social status_. You have commit rights when a community has voted to invite you to commit. The people with commit rights on a project are the 'committers'. This message is about commit rights. It skips right over the arguments about changing the relationship between commit rights and commit privileges, to focus on how communities manage rights. Commit rights are not necessarily a simple, binary, phenomenon. Committers on projects are expected to follow community policies, procedures, and norms. One simple example of this is RTC. If a project operates under RTC conventions, committers don't go off and commit things without review. There are many more examples. If a project has agreed to drive towards a release, committers are expected to not disrupt the process by committing big, new things. Some projects insist that every commit be tied to a JIRA. All in all, however, Apache projects have tended to treat commit rights as a big deal. You don't get commit rights until you earn them via merit. Some projects are very conservative in evaluating merit. Some projects look for some level of overall community engagement as a prerequisite to commit rights. The question at hand here is, 'is this really a good idea? Would project grow and thrive better if they set a lower bar to grant commit rights?' Some people (Greg Stein, e.g.) have written eloquently on the historical justification for conservative commit control. Historically (i.e. in CVS), it was difficult to monitor changes and it was difficult to cleanly undo an inappropriate change. So, it was necessary to set a high bar for commit rights, so as to reduce the risk of something awful happening. In the modern world, on the other hand, the Foundation provides email with diffs for review, and Subversion makes it reasonably straightforward to reverse an untoward commit. Thus, this argument claims, projects have little to lose by granting commit rights more easily. What, on the other hand, do they have to gain? Long-term success of an open source projects depends on continued acquisition of new participants. Projects that don't grow risk shrinking and dying. When a person shows up at a project and reads the message, 'we don't trust you until you've posted 15 patches, etc.' that is not exactly a welcoming message. Some people see it as a challenge and rise to it. Other people are put off. There are several notable examples of successful open source projects outside of the Foundation that adopt the opposite tactic. Their publish a policy like: "Commit rights to this project are granted upon request. However, committers must read, understand, and comply with our policies. When you start out, you may want to ask for review, or commit to a branch, and get feedback from the community." It seems that the people who show up at these projects are, almost universally, responsible adults who are happy to comply. This 'welcoming' policy has the effect of drawing people in. What I've presented, so far, is arguable a radical change to the usual Apache culture. It moves 'karma from merit' entirely from the 'commit' threshold to the 'supervise' threshold. I already know that there are people at Apache who don't like the idea, or at least don't think it makes sense for their projects. I'm not writing to suggest that this scheme be forced upon anyone. This is comdev@. Here, I think, we talk about ways of helping projects grow and succeed. Writing as the IPMC chair, I'm inclined to think that the Incubator would to well to encourage this model for new projects. By far, the biggest reason for podlings to fizzle is their failure to grow. I don't mistake this for a magic bullet, but I think it could help. To recapitulate a bit, so far I've presented some historical context and an argument for an alternative model of _commit rights_. It has no particular implication for the management of _commit privileges_. If a project adopts this model, it still adds people to the ACL that controls the subversion repository, one at a time. If a project adopts some form of these scheme, the PMC is still responsible for supervision. 'Commit on request' means that the PMC has, potentially, more people to supervise after less experience. Some projects will not see this as a good tradeoff. Others might adopt the attitude of, 'If only we had enough people show up and ask for commit rights to actually give us more supervising to do.' There's a weaker form of this idea that looks at two populations of potential contributors: the members of the Apache Software Foundation (members@) and all of the people who have been granted commit rights on all of the projects (committers@). Projects that don't feel prepared to offer commit-on-demand to the world at large might feel inclined to do so for (one or both of) these groups. Not because all communities work the same way, but because all communities at Apache share a core value: committers respect the policies and procedure of the community. Once someone has shown that they are willing to play nicely over _there_, we might do well to welcome them with open arms _over here_.
