February 26, 2009
There is a fascinating culture emerging around distributed version control systems (DVCS), facilitated by software, but responding to (and suggesting) shifts in collaboration styles. It is very easy to imagine these practices percolating through other areas of information production.
I am still a bit new to distributed versioning, but a primary difference between distributed versioning and traditional centralized versioning is how easy/hard it is for an outsider to contribute ideas/expressions/work back to the project. Part of what makes this all work smoothly are very good tools to help merge disparate branches of work – it sounds chaotic and unmanageable, but so did concurrent version control when it first became popular (that is, allowing multiple people to check out the same file at the same time, instead of locking it for others while one person was working on it).
This post, Sharing Code, for What its Worth, does a great job explaining some of the advantages of distributed version control systems. Sometimes you just want to share/publish your work, not start a social movement. Sometimes you want to contribute back to a project w/out going through masonic hazing rituals. DVCS facilitates these interactions, far more easily than traditional centralized/hierarchical version control systems.
Wikipedia runs on a centralized version control system, but the Linux Kernel is developed on DVCS (as Linus Trovalds explains/insists himself here). We are just starting to use github at work, and I have watched it increase the joy of sharing – reducing the disciplined overhead of perfecting software for an imagined speculative use and coordinating networks of trusted contributors. The practice really emphasizes the efficient laziness of agile programming, and helps you concentrate on what you need now, not what you think you might need later.
In some ways, this style of collaboration is more free-loving than an anonymously editable wiki, since all versions of the code can simultaneously exist – almost in a state of superposition. However, there is a hidden accumulation of technical debt that accrues the longer you put of combining different branches of work. And, sometimes you may actually want to start a community or social movement around your software, which is still possible, but is now decoupled and needs to be managed carefully.
I think we can start to see hints of this approach breaking free from the software development world in this recent piece of intention-ware described in Crowdsourcing the Filter. (I met some of the Ushahidi team earlier this year – -and was impressed by how competent and grounded they seemed – tempering both the hype and nostalgia). As Benkler has argued, ranking and filtering is itself just another information good, and amenable to peer production, but the best ways of organizing and coordinating – distributing and then reassebling – this production, still need to be worked out.