Why Do Open Source Projects Fork?

Open source software (OSS) projects start with the intention of creating technology that can be used for the greater good of the technical, or global, community. As a project grows and matures, it can reach a point where the goals of or perspectives on the project diverge. At times like this, project participants start thinking about a fork.

Forking an OSS project often begins as an altruistic endeavor, where members of a community seek out a different path to improve upon the project. But the irony of it is that forking is kind of like the OSS equivalent of the third rail in the subway: You really don’t want to touch it if you can help it.

Open source software developer David A. Wheeler likens forking to a parliamentary no-confidence vote or a labor strike. It can cause a lot of hard feelings for the people involved. It can even tear a community apart.

We’re not talking GitHub-style forks here, either, which are actually short-lived branches that are either pulled back upstream or simply deleted when someone finishes developing a new feature. The forks we’re talking about are when a significant number of developers in an OSS community decide to branch off from the original project in an attempt to improve upon it and eventually replace it.

So why do OSS projects fork? The simplest answer is because of differences in opinion, which could be technical or personal in nature, but there are other reasons as well. A 2012 paper by researchers Gregorio Robles and Jesús M. González-Barahona, “A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes,” identified a number of key reasons for forking a project:

• Some contributors want to take the project in a different technical direction.
• Some contributors to the original project feel that their feedback isn’t being heard, that the maintainers are moving too slowly in accepting patches, or even that they are releasing too quickly — think of last year’s rumors of Docker and that project forking.
• The original project has been abandoned. Back in the 1990s, the Apache web server project took over for the abandoned NCSA HTTPd project.
• Commercial reasons arise. This happens when companies are involved and one wants to create a paid version of the original software or vice versa.
• Legal reasons upset the community. A project might move away from a GPL (GNU public license), a trademark dispute may arise, or someone may make a change with how the program uses encryption.
• Personal reasons get in the way. Irreconcilable differences of a non-technical nature lead to a rift between various parties, so the project forks.

How Does a Project Fork?

There’s a pretty orderly process for a how a fork proceeds. Other people have written articles and academic papers on how, why and when you should fork a project, so we won’t go into the details here. However, it should be noted that even though it’s seen as a last resort when all other options have been exhausted, forking typically results in a positive outcome.

What’s the End Result of a Fork?

So what are the possible outcomes when an OSS project forks? Both Wheeler and Robles and González-Barahona, who examined some 220 “significant” forks in depth, identified these potential results:

• Both the original project and the fork succeed. One notable example is the Android operating system, where Amazon and others have forked Google’s original operating system and made their own. Another would be BSD and its derivative projects, like FreeBSD, NetBSD and OpenBSD. This is the most common outcome.
• The fork merges back into the original project. This rarely happens, but is not impossible. You may remember when EGCS forked from GCC, the GNU Compiler Collection. The fork was successful, but to avoid issues with users integrating the new software, the changes were merged back into the original GCC code and released as the new GCC.
• The fork withers and dies. When libc split off from glibc, the glibc contributors dove deep into improving glibc, so much so that it overtook the fork, and eventually most users stopped using libc in favor of glibc.
• The original project fails. XFree86 moved away from a GPL-compatible license, so the project forked, giving birth to X.org, which was quickly adopted by most developers and users. Soon after, the XFree86 core team disbanded and development ceased on the project.
• Both of them fail. Robles and González-Barahona noted this occurred in less than 10 percent of the 220 significant forks they studied.

A Case in Point

Take the FRRouting project, a recent fork of network routing software Quagga. The fork arose out of the classic technical differences in the direction of the original Quagga project, compounded by a large and growing backlog of patches waiting to be merged upstream.

“Our engineers had developed tens of man-years of improvements on the upstream project,” said JR Rivers, Chief Technology Officer and co-founder of Cumulus Networks. “We had spent years trying to get that work integrated, but due to various circumstances, the pace was slow. Others either wanted access to our work or to build on top of it, so we found ourselves in a quandary.”

When the team embarked on the fork, they set out to do things differently from the outset. According to Donald Sharp, an engineer at Cumulus Networks and a maintainer at the FRRouting project, they “focused more on building the community than working on the code.” It helped that they already had a lot of new code waiting to be released.

And so, with the code checked in, the community organized and the new project launched, the team set off on a path less often traveled, and like all forks before them, they did it for the same purpose: to take a good product that they know well and are passionate about, and try and make it better.

Feature image via Pixabay.