Commit access allows an independent open source contribute access to your project’s source tree. Over the years I’ve found that it is best to be very liberal when granting commit access to my projects. If the developers has submitted a patch that has solved a particular problem that even remotely shows they understand how my project is designed, I grant them access. Think about it. Somebody that has posted a patch has: learned how to download the source, has learned how to build your project, has stepped through your code to find and understand their bug or new feature, and most importantly has shown a tremendous amount of initiative. Contributors are usually very honored when they are granted commit access. It gives them a sense of ownership and pride. They are usually relatively careful because they are so afraid that their code is out in the wild and can be viewed by anybody.
Sure, you may have a lot of turnover on who commits or not, but you sometimes get somebody that wants to stick around for the long term. Especially if you start to give them more resposibility on the project and respect their abilities. Sure, being so liberal often leads to poor commits and you having to rewrite some things. The real value here is the unit tests and blazing the initial trail if we’re talking about a new feature. As long as the potential contributor has unit tests that go along with their bug or feature patch, I’m usually more than happy to welcome them to the community.
What are your experiences?
BTW, liberal policy is my own. Other projects at Red Hat may or may not be as liberal.
Aug 28, 2009 @ 21:39:36
Bill,
this is why I love the rise of DVCS. We can now minimize commit access, and instead move to a pull model.
Cheers,
Dion
Aug 28, 2009 @ 22:22:41
I agree with you, commit access shouldn’t be granted after month of effort – this will most likely discourage “would be” contributor and also lead to a messy stack of patch to handle…
However, this issue may not longer so important, as distributed source control system, such as Mercurial and Git, seems to become the new standard. In a distributed system, a so called project leader has just control over the “reference repository”. He just pulls changesets from anyone he wants… Therefore you don’t have to get the commits access to become a “real contributor”, you just need to have your repository pulled… In essence, if you ever submit changeset that is pulled from your repository, you instantly become a contributor.
Aug 28, 2009 @ 23:22:30
I agree. Many a project I was sucked into in the past as people were so trusting and open. Suddenly I felt it was my responsibility to tidy things up, put on a good show etc…
Interestingly, I see github being a popular repository partly for the reason where it almost doesn’t wait for access to be granted: you can take anything, press the “fork” button and you have your own repo to work on (the originator can then pull from yours if you want them to). It also keeps original maintainers honest, as there is no strict master in git – only what people deem as the “source of truth”.
Aug 29, 2009 @ 00:04:22
Dion, Romain. I’m looking forward to working with Git, et al. eventually because I was always fond of the idea of everybody working in their own branch and merging things back to trunk. But a “pull” model or a central repository not being so important anymore worries me a bit. I can imagine a blog where somebody writes how they introduced this new feature or bug…Sounds awesome for collaboration, but to have to more formally support this from a release perspective? Sounds a bit scary to me…
Aug 29, 2009 @ 00:05:46
BTW, with Git becoming popular Commit Access sort of loses its social status, which is kinda sad when you think about it…
Aug 29, 2009 @ 01:06:32
Yeah I think it is a bit sad the “social status” is going away… I guess there is some cred that comes with having your changes pulled into the master etc…
Sep 07, 2009 @ 09:01:59
I like liberal communities. Just take a look at http://www.ops4j.org. We give anyone teh right to commit as soon as he registers in our bug tracking system. And for 3 years, since I’m involved, it just worked fine.