Socializing Development

Four years ago Linus Torvalds laid the groundwork for a new version control system, called Git, that would allow the distributed team of kernel hackers to collaborate and coordinate the extensive work that was being done on the Linux kernel. Today, Git adoption has exploded, now in use on high profile open source projects like WINE, Ruby on Rails, Perl, Android, Prototype, VLC, X.org, Fedora, and thousands of others.

Unlike centralized version control systems that enforce a bureaucracy around who is allowed to commit to an authoritative repository, Git encourages would-be contributors to fork the main repo and commit to their copy as they please. When they’re ready, contributors can simply point the core team at their fork and request that their changes be merged in. If the upstream repo changes before a patch series can be included, tracking upstream changes with Git is very easy (no need to re-roll patches!).

Drawing on experiences I’ve gleaned from cofounding and running GitHub (the world’s largest and most active Git hosting site) for the last year, I will introduce the concept of “Social Coding” and cover a number of case studies that demonstrate how Git has altered the way in which open source contributions are accepted, tested, and finally merged into the canonical repository. Some examples will be the Linux kernel (and their lieutenant hierarchy), Ruby on Rails (and their explosion in contributions after moving to Git), and ClickToFlash (which came back from the dead after moving off Google Code and onto GitHub). There are many strategies that can be adopted depending on the size of the project, the number of collaborators, and the philosophy of the core team. One of the hardest things for new Git users is to determine which workflow will be best for their project.