Coding 3 min read

Authors ≠ Committers: why most Open Source projects should switch to distributed revision control

I had been thinking about the idea behind this post for a while now, but reading this post about getting newbies involved in open source just convinced me to write it down.

Being a concept developed in the Open Source world, it is no wonder that distributed revision control systems give their best in that context. There are many pros and cons, that other people described in detail better than I can do. Of all the features they offer, however, the one I prefer is the least technical one, and it is related to the way they encourage new developers to contribute to open source projects. In that perspective, git and mercurial are a lot more effective than svn, for example.

It all comes as a side effect of authors and committers being two different roles. This can encourage new contributors, who are approaching a new project for the first time, and individuals who may not have the time and energy to dedicate long periods of their time to a project, but may be able to contribute with just a few patches.

How GitHub displays both the author and the committer of a single change. Oh, and yes, there is something wrong with the dates. 😉
How GitHub displays both the author and the committer of a single change. Oh, and yes, there is something wrong with the dates. 😉

Think about that. Recognition is one of the most important drivers for Open Source contributors but, unfortunately, centralized revision control (subversion, CVS and the like) doesn’t help in giving credit to newcomers or occasional contributors.

That’s because, generally, sending a single patch (or even a few of them) is not enough to be granted commit access to a project repository (and rightly so) and the commit itself must be done by a project member with enough privileges.

With svn or cvs, the committer of a changeset figures as its author, and the original author of the code is often just mentioned in the notes or in some “credits” list.

With git or mercurial, on the other hand, the author and the committer of a changeset are not necessarily the same person: each commit can then retain the original author name.

I believe that some coders would be much more willing to contribute to Open Source software if they know their name will be included in the official commit logs, especially given the existence of sites like Ohloh, that track contributions by single commits. I would be much more willing to engage in a project if I knew that my changes would be attributed to me no matter who commits them.

That is why I believe what I said in the title: if you are about to start a new Open Source project, you should pick git or mercurial as your revision control system. Do it not just because they are better (and I strongly believe they are), but also because they will make it easier for you to credit any contributor you’ll get.


If you are unfamiliar with the whole concept of distributed revision control, I suggest you to visit hginit.com or gitref.org, they both offer intuitive and effective tutorials about the benefits of using mercurial or git.

Related Posts

View All Posts »
2 min read 3 comments

As I already had the chance to write in a previous post, I really appreciate distributed version control systems; I consistently use them at work and for many of my side projects. I typically switch b...

What’s wrong with Milan’s Open Data initiative

What’s wrong with Milan’s Open Data initiative

3 min read

I spent some time playing with the Open Data published by the City of Milan, aiming to visualize public transport coverage. While I managed to create a heatmap, I was left unsatisfied by the data presentation and format. The initiative is promising but could be dramatically improved by adopting modern standards like GeoJSON instead of Shapefiles and including simple preview capabilities.

2 min read 1 comment

A while ago I wrote about a few problems we were having with the way our issue tracker was misused and concluded that the tools we use have a crucial role in directing our behavior towards good or bad...

3 min read 2 comments

During the last weeks, I’ve been writing a lot of code while commuting. Since I was working on an application that uses Facebook’s and Amazon’s APIs and I was working offline, I often found myself una...