The Linux kernel, arguably one of the most important FLOSS projects, was managed without a version control system until 2002. Linus Torvalds, the project leader, disliked centralized version control systems, which he considered unsuitable for kernel development. The Linux kernel is a very large and complex software project, has extraordinary quality demands and also attracts thousands of developers. Changes were meticulously tracked through a distributed hierarchy of delegates, but the system was showing strain.
In 2002 Linus finally decided that a “distributed version control system” (DVCS) would match the project's needs. The Linux kernel was migrated to the proprietary BitKeeper version control system, a selection which sparked great controversy because of its closed license. In 2005, licensing disputes eventually led to the creation of freely licensed distributed version control system and the DVCS named Git was created.
Distributed Version Control Systems operate on a different model than repositories managed by a centralized, client-server system. The DVCS model is peer-to-peer and, while it can be configured to resemble traditional client-server transactions, it can also support more complex interactions. In a DVCS system, every developer works locally with a complete revision history, and changes can be pushed and pulled from any other peer repository. The version control system has vastly improved support for merging across multiple repositories, and all working checkouts are effectively forks, until they are merged back onto a canonical trunk.
The demands on the Linux kernel project prefigured demands on other projects. In the past few years distributed version control systems have dramatically increased in popularity. Mercurial, Bazaar, and Git have emerged as the most popular open source DCVS systems, and hosting services have launched offering each of these systems free of charge for open source projects. Google Code began supporting Mercurial, alongside Subversion, repositories in mid 2009 (Paul, 2009b). Cannonical, the company which sponsors the Ubuntu GNU/Linux distribution, offers free Bazaar hosting to open source projects on Launchpad.net. In February 2008 GitHub.com launched, a “social coding” site which provides Git hosting and rich social networking tools to all developers using the site, gratis for FLOSS code. Bitbucket.org offers similar social networking tools around Mercurial, and describes itself as “leading a new paradigm of working with version control”.
The centralized hosts of peer-to-peer protocols broker a new balance between centralization and federation. They facilitate coordination, but do not mandate it. A site like GitHub can track and aggregate multiple branches of development, but branching does not require any permission or upfront coordination. Instead of requiring an upfront investment of attention and energy to coordinate development activities, DVCS concentrate on improving the mechanisms for developers to track, visualize, and merge changes. The costs of coordinating collaboration is deferred, and the communication overhead required to synchronize and align different branches of code is (hopefully) reduced.
There is a fascinating culture emerging around DVCS, facilitated by software, but responding to (and suggesting) shifts in collaboration styles. As one developer explains:
“SourceForge is about projects. GitHub is about people… A world of programmers forking, hacking and experimenting. There is merging, but only if people agree to do so, by other channels… GitHub gives me my own place to play. It lets me share my code the way I share photos on Flickr, the same way I share bookmarks on del.icio.us. Here’s something I found useful, for what it's worth… Moreover, I'm sharing my code, for what it's worth to me to share my code… I am sharing my code. I am not launching an open source project. I am not beginning a search for like minded developers to avoid duplication of efforts. I am not showing up at someone else’s door hat in hand, asking for commit access. I am not looking to do battle with Brook’s Law at the outset of my brainstorm”
—Gutierrez, 2008
Sometimes developers simply want to publish and share their work, not start a social movement. Sometimes they want to contribute to a project without going through masonic hazing rituals. DVCS facilitates these interactions far more easily than traditional centralized version control systems and the hierarchical organizations which tend to accompany them. Part of what makes this all work smoothly are very good tools to help merge disparate branches of work. This all sounds chaotic and unmanageable, but so did concurrent version control when it first became popular.
An inquiry into the channels and formats that disperse, publicize and create audiences for ideas, objects, and data. Online / offline / at the thresholds. Distribution via a particular channel is not always the end point. Distributed material may possibly be adapted, modified, hacked, remixed and re-distributed by a user or group. This modification may or may not be legal depending on intellectual property and licensing issues. But the user might do it anyway.
In anecdotal accounts of switching to DVCS, developers describe an increase in the joy of sharing—the tools help reduce the focus on perfecting software for an imagined speculative use and the overhead of coordinating networks of trusted contributors. The practice really emphasizes the efficient laziness of agile programming, and helps people concentrate on the immediate requirements, rather than becoming preoccupied with endless planning and prognostications.
In some respects, this emerging style of collaboration is more freewheeling than an anonymously editable wiki, since all versions of the code can simultaneously exist—almost in a state of superposition. Wikis technically support the preservation of diversity in a page's history, but in a centralized wiki the current page is the (ephemeral) final word. DVCS are developing richer interfaces to simultaneously represent diversity, and facilitate the cherry picking of features from across a range of contributors. The expression of a multiplicity of heterarchical voices is explicitly encouraged, although there is a hidden accumulation of technical debt that accrues the longer a merger of different branches of work is delayed. Of course, sometimes you may actually want to start a community or social movement around your software, and that is still possible but is now decoupled, and needs to be managed with purposeful intent.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.