choosing and scm: political innovation or open innovation

For this post, assume that the primary advantage of open source is the fact that someone, much smarter than you can show up and contribute code that extends your open source project. You might have a great idea for a repository manager (like Nexus), so you release the source code until some open source license, and someone else comes along and extends it to support an unexpected repository format (nexus-yum-plugin).

To me, this is the reason why Open Source works. You expose your code to the world with the hope that someone comes along and takes your idea, develops it, and extends it. If you are smart you’ve defined a good plugin model (like Jenkins) so that people can extend you initial idea without having to invest too much time in learning about internals.

If you maintain a project, I think you have a critical choice to make DVCS (like git or mercurial) or a Centralized option such as Subversion. This choice encourages a certain type of innovation:

  1. If your open-source project uses a centralized source control system like Subversion, you are presenting potential contributors with an obstacle. Branching and merging with centralized VCS like Subversion (or even CVS) was and continues to be difficult when you compare similar operations to DVCS. Let’s pick on Subversion, when I used to use Subversion for larger projects, branching and merging felt like an awful process: first it was almost impossible to do it right unless you had access to the repository and could create a tag or a branch, second I can’t tell you how many times contributions were clobbered because the interfaces available were just awful.
  2. If your open-source project uses a decentralized source control system like Git, you are telling potential contributors to, go ahead, innovate on your own improvements, pull and merge changes from the upstream repository, and, one day, surprise us with your own pull request. Innovate on your own terms, and don’t ask for permission. Branching and merging with Git is a few orders of magnitude easier because you are not dealing with tags and branches as directories in a shared repository. You don’t checkout a particular revision, you clone the entire repository.

On one side of this debate, Subversion, communities based on it tend to be as centralized as the SCM. On the other hand, Git, communities based on Git tend to attract contributions from a wider audience, and an audience that isn’t as focused on making sure they are in agreement with the initial community.

In my experience, Subversion encourages a political organization: project leaders that set the direction of a closely held project. Git encourages a more open organization. If someone has a good idea, they can work in a branch in a way that is more natural.