For a long time I’ve been thinking about just how much Github has revolutionized open source. Yes, it has made managing the code base significantly easier but its real impact has likely been on the social aspects of managing open source. Github has rebooted how the innovation cycle in open source while simultaneously raising the bar for good community management.
The irony may be that it has done this by making it easy to do the one thing many people thought would kill open source: forking. I remember talking to friends who – before Github launched – felt that forking, while a necessary check on any project, was also its biggest threat and so needed to be managed carefully.
Today, nothing could feel further from the truth. By collapsing the transaction costs around forking Github hasn’t killed open source. It has saved it.
The false fear of forking
The concern with forking – as it was always explained to me – was that it would splinter a community, potentially to the degree that none of the emerging groups would have the necessary critical mass to carry the project forward. Yes, it was necessary that forking be allowed – but only as a last result to manage the worst excesses of bad community leadership. But forking was messy stuff even emotionally painful and exhausting: while sometimes it was mutually agreed upon and cordial, many feared that it would usually was preceded by ugly infighting and nastiness that culminated in an (sometimes) angry rejection and (almost) political act forming a new community.
Forking = Innovation Accelerated
Maybe forking was an almost political act – when it was hard to do. But once anyone could do it, anytime, anywhere, the dynamics changed. I believe open source projects work best when contributors are able to engage in low transaction cost cooperation and high transaction cost collaboration is minimized. The genius of open source is that it does not require a group to debate every issue and work on problems collectively, quite the opposite. It works best when architected so that individuals or functioning sub-groups can grab a part of the whole, take it away, play with it, and bring the solution back and it fit it back into the larger project.
In this world innovation isn’t driven by getting lots of people to work together simultaneously, compromising, negotiating solutions, and waiting on others to complete their part. Such a process can be slow, and worse, can allow promising ideas to be killed by early criticism or be watered down before they reach their potential. What people often need is a private place where their idea can be nursed, an innovation cycle driven by enabling people to work on the same problem in isolation, and then bring working solutions back to the group to be debated. (Yes, this is a simplification, but I think the general idea stands).
And this is why GitHub was such a godsend. Yes it made managing the code base easier, but what it really did was empower contributors. It took something everyone thought would kill open source projects – forking – and made it a powerful tool of experimentation and play. Now, rather than just play with a small part of the code base, you could play with the entire thing. My strong suspension is that this has rebooted the innovation cycle for many open source projects happens. The ability of having lots of people innovating in the safety of their private repository has produced more new ideas then ever before.
Forking = Better Community Management
I also suspect that eliminating the transaction costs around forking has improved open source in another, important way. It has made open source project leads more accountable to the communities they manage.
Why?
Before Github the transaction costs around forking were higher. Setting up a new repository, firing up a bug tracking system and creating all the other necessary infrastructure wasn’t impossible, but neither was it simple. As a result, I suspect it usually only made sense to do if you could motivate a group of contributors to fork with you – there needed to be a deep grievance to justify all this effort. In short, the barriers to forking were high. That meant that project leaders had a lot of leeway in how they engaged in their community before the “threat” of forking became real. The high transaction cost of forking created a cushion for lazy, bad, or incompetent open source leadership and community management.
But collapse the transaction costs to forking and the cost of a parallel project emerging also drops significantly. This is not to claim that the cost of forking is zero – but I suspect that open source community leaders now have to be much more sensitive to the needs, demands, wishes and contributions of their community. More importantly, I suspect this has been good for open source in general.
eaves.ca 
I agree with ‘revolutionized’, definitely, although if you look at how tool use has evolved over the last 10 years or so it can look like more of an evolution from the ground. Your title implies open source needed saving, which is a bit much. I think open source will always be a great place to start a revolution though. ;)
It’s not really github that did that, but DVCS: the underlying system used by git mercurial and bzr.
Any clone in a DVCS is a fork, you don’t need github for that.
That is what I was initially going to say as well, however, Github also includes everything that comes along with it. One click of a button and you have a web interface, a bug tracker, a graph of activity and branches and so on.
Didn’t we have that on SourceForge too? Yes we did.
To me GitHub shouldn’t get too much credit for this, it’s indeed DVCS or git itself.
Imo, GitHub should only deserve more credit if it would be open source.
SF does have those things to, but when GitHub came out there was no way to ‘one-click-fork’ a project (and I’m not sure if that’s the case now or not).
Yes, all the backend work is done by git, but the frontend niceness is all GitHub, and I think that’s a large part of what’s made everything so easy to work with.
I agree with ‘revolutionized’, definitely, although if you look at how tool use has evolved over the last 10 years or so it can look like more of an evolution from the ground. Your title implies open source needed saving, which is a bit much. I think open source will always be a great place to start a revolution though. ;)
This is exactly it, I tried explaining why git (and github) was awesome and the example that we looked at on github was RoR. The comment was essentially “So many forks! Ahhhhh!”. I couldn’t articulate why that was a good thing.
The genius judo move of git over previous centralized systems was to NOT take on the political question of who is allowed to commit to a repository of work. In centralized systems (eg: Subversion), the only way to read or write is to be granted access to the central repository.
Git essentially sidesteps the issue of who can commit and says “not my problem”. Because each copy of the git project repository is a full fledged version of it, you can take my repo and do whatever you want to it. I don’t need to give you write access to my project, you can make commits on your copy of it. Forked!
So without me having to understand what you think your idea is, you can clone my repository, make some improvements (on your fork), and then send those patches back to me. Then it’s up to me to review and integrate your work.
I only need to need to care about you once you’ve got something to show me.
Although GitHub uses the language of “fork” and these codebases are technically forks (original authors do not have commit access to the fork), these codebases behave much more like local copies in Subversion, CVS, etc.
With GitHub, people make a copy of the codebase. Some never make changes – they just want a stable release. Those who do often submit a pull request to merge the changes into the main codebase. Others want to add/modify features that are specific to their use case, and these changes are never merged. Others just want to play with the code. The purpose is not to start a new project in these cases.
As such, GitHub’s use of “fork” has led to some false conclusions about forking. True forks still happen. See the recent SlimGems fork of RubyGems, or JSHint of JSLint. The fears of true forking are real. True forks can fracture communities. Poor leadership and cooperation must be avoided to prevent bad consequences.
http://gnuu.org/2011/06/01/slimgems-a-drop-in-replacement-for-rubygems/
http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/
http://rolandtanglao.com/archives/2011/05/11/developers-need-be-github-period-its-social-coding-era-fork-branch-pull-reques-0 :-)
Pingback: 451 CAOS Theory » 451 CAOS Links 2011.06.17
Pingback: Best Open Source Project
I agree with jpmckinney, you completely missed the mark in calling github project clones a traditional project fork, because they are far from it.
In a fork the project diverges whether in community or project roadmap or both. In github project clones, a clone is not necessarily a fork, just a copy in someone else’s working area and all clones create a project mesh of sorts, but the same project nonetheless.
Pingback: Links 21/6/2011: Mozilla Firefox 5, GCC 4.6.1 RC | Techrights
Pingback: 创建成功的Python项目 - 博客 - 伯乐在线
Pingback: New Models of Organisation | SocialOpticSocialOptic