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
