Blogs

RedMonk

Skip to content

Measure success by merges, not forks

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.

by-sa

Categories: open-source, Uncategorized.