Selecting tools for open source projects is akin to preparing for a space launch. There are so many things that can go wrong and one must attempt to think through all the disaster scenarios of which one can conceive.
More often than not, developers and community managers either satisfice with the first acceptable tool they come across, or reflexively reach for whatever tool is most familiar. Neither of these is optimal – especially if you’re concerned with the long-term viability of the tools you’re using.
We at Psiphon wanted to ensure that our project was running on the most advanced software appropriate to a serious, long-term open source project. While a lot of the technical assumptions of open source projects have remained constant since the practice’s beginnings, others have changed under the community’s feet.
Ensuring there is something we can do.
One such major change is the shift in version control technology. It used to be that CollabNet’s Subversion was, as its named implied, the counter-cultural tool of the new wave; toppling the CVS monolith which had forced sub-optimal practices and fostered sloppy code maintenance. Now DVCS, that is distributed version control systems are emerging as the new norm. Unlike the previous generation’s clash-of-the-titans between SVN and CVS, there are several contenders each with their own schools of supporters and none with an un-contestable hegemony.
When I set about enumerating all the various open source tool hosts, it was clear that one’s preference in DVCS was the most salient distinguishing feature amongst all the different tools. DVCS, as the name implies allow a peer-to-peer style of version management – the software doesn’t enforce a single, canonical version of the software. This has a number of technical benefits (easier alteration of software, better off-line editing, etc.) but it also enforces legitimacy of community managers – since there’s no big stick of original source control to enforce hegemony.
Conceptually DVCS has been around for a while, but has only recently seen widespread adoption. While there are a number of options for DVCS there are really three major front-runners, Git, Mercurial and Bazaar. Because Psiphon aims to be accessible, and I couldn’t spend a year comparing DVCS packages, I decided to exclude all but the big three from inspection.
Mercurial (Hg)
Along with sibling package, Git, Mercurial was kicked-off by the withdrawal of the free version of BitKeeper. Developed largely in python with some C libraries, Mercurial has a wide support base. Its viability as a package took a shot in the arm recently as Google announced Hg support in their GoogleCode hosting platform. Mercurial is also the tool of choice for users of BitBucket, a popular project hosting service. Mercurial is renowned for it’s intuitive nature and intelligent CLI. Mozilla uses Mercurial, as does Symbian OS (the Nokia-developed operating system for mobile devices) among many others.
Git
Git was blessed from its beginnings. Created by Linus Torvalds and implemented for use on the Linux kernel in response to the removal of BitKeeper; Git isn’t going anywhere any time soon. Git is also used on the popular project hosting service GitHub – popular amongst Ruby-on-Rails projects, including the RoR project itself and its sister-project the AJAX library Prototype. Git is considered the market leader, if only for the simple fact that the Linux kernel uses it for development. Git has been criticized for it’s user-unfriendliness and often unintuitive CLI.
Bazaar (bzr)
Bazaar was developed by Canonical software for use in maintaining its premiere Linux distribution Ubuntu. It has been since incorporated into their open source tools package Launchpad. Launchpad and Bzr are used by several flagship open source projects, notably Sun Microsystem’s MySQL project, the Zope python web framework and Ubuntu and family.
The Upshot
While technical capacity is an important consideration, the user-base of a tool like version control for an open source project is often as important. If a potential developer is forced to learn an additional tool it increases the barrier to entry, narrowing the scope of contribution. Further, while DVCS is quickly becoming a critical component for open source development, it must be considered amongst concerns of integration with other tools – a strong VCS cannot compensate for an otherwise weak tool chain.
Ultimately, a VCS doesn’t make a community and can’t run a project for you – the object is to select the tool least offensive to contribution and most conducive to good development habits amongst your contributors. We’ll see in coming entries how each of the systems fare as I set about finding a new home for Psiphon’s open source development.
Summer of Psi Blog 