Since its inception open source forking has often been a topic of debate. For some, forks spell disaster while others see it as good and inherent to the nature of open source. The plain and simple truth however is that it can be both– and which side ultimately becomes truer than the other depends on specific circumstances and the actions you take in response to them.
The Good
Although the very definition of forking– when a development based on the source code of another project becomes independent of the original– has its emphasis on separation and can therefore have a negative connotation, it is not bad or wrong. It’s good in a sense that it can introduce changes to software which can benefit many other users. It can even be necessary for the good of a project. For instance, a dying project can be brought to life again by a fork.
Forking can also help ensure that the software remains free and open source, like in the case of LibreOffice. Another good thing that can come out of forking is when a fork is folded back into the original project or replaces it. In these cases, often the fork introduces much needed improvements.
The Bad
Forking is essentially a right of developers of open source projects. But being a right doesn’t make some of its consequences any less damaging.
In some cases forking meant the division of communities, users and resources; a division that eventually led to one or both projects failing. The unified effort that was once funneled into one project split into two, and with fewer people on board the quality of the software suffered. In many of these cases each fork also focused on changes that benefited only a particular set of users and not all of them.
Because of these consequences, even those that have founded forks like Nextcloud founder Frank Karlitschek says that forks should be avoided at all costs. “In general forking is not a good thing,” Karlitschek has said. “It comes with significant drawbacks and it should be the last option. It disrupts and harms the community, and in the worst case it can split the community in half.”
What to Do in the Face of Forking
But what if forking is unavoidable? One of the best things to do would be to focus on the direction and quality of the software. Remember what it is you set out to achieve with the software and achieve it. There may be major adjustments necessary, but don’t let those adjustments stagnate the project.
And don’t be discouraged by a limited number of initial developers or users. It may take some time, but as long as you remain faithful to what you promise the software will do and achieve it with uncompromising quality, users and developers will eventually notice and offer their support.
Until then, make it as easy as possible for users to transition to the fork, and stay positive. It’s not always clear from the beginning whether a fork will fail or succeed. According to some statistics, fork failure is not as common as most would think. In a study of 220 forked projects conducted in 2011 by researchers Gregorio Robles and Jesus M. Gonzalez-Barahona of the Universidad Rey Juan Carlos in Spain, the percentage of forks that are discontinued is less than 15%, with less than 9% involving the discontinuation of both the original project and the fork.
So just because a fork is in your immediate future doesn’t mean disaster and discontinuation will soon follow. True there are downsides to forking, but there are plenty of cases too where everyone wins in the end.