GitHub has enabled a new type of development that’s not just distributed, as provided by the underlying software Git, but also social. Suddenly, it’s absolutely trivial to find interesting software, fork it, and hack around. It’s not difficult to find examples of projects with 50 or more forks, and a number exist with hundreds or more (Linux has nearly a thousand).
But here’s the problem, and it’s a problem I encountered regularly with Gentoo’s internship program. It’s not forking that’s the hard part, it’s merging. Hacking around in a codebase is a long, long way from a fork that’s in mergeable status, with good architecture, clean code, and helpful documentation.
Merging code is a particularly egregious problem with corporate-driven open-source software, because the company behind it may have processes in place behind the firewall, lawyers complaining about copyrights, and so on.
Therefore I submit that the true measure of an open-source project is the ability to merge code regularly — reviewing all of the open pull requests and acting on the ones that are ready to join the primary codebase. When you’ve got an active community of contributors but fail to accept their contributions, what do you think will happen? Someone is going to fork not just your code, but also your community — you’ve lost control of the project entirely and there’s a new BDFL in town.
This is why it’s so important to get open-source governance right, and to truly behave as an open-source project, not just throw open-source code over the fence.
Even for Companies: Github is your Resume | Ryan Stewart – Mountaineer Coding says:
August 20, 2012 at 12:25 pm
[…] I caught a post by James Governor that resonated because I think Adobe is doing it right. The premise of the post is that your code is all you need for PR. Sometimes that’s releasing code, but more importantly, when you control a project, it’s about making your code easy to access and to take contributions for. As Don says, measure success by merges, not by forks. […]