What CIOs need to know about open source forking

Picture this: Your company is ticking along nicely, making use of a reliable and well-engineered piece of software to support some important business process, when suddenly it becomes apparent that all is not well in the project's developer community. A fork is in the cards, and the very future of the project hangs in the balance.

Before we get to the crucial questions of whether a fork is really such a bad thing and what a CIO should do when faced with one, let's first be clear about what we're talking about.

In their study of software forks, researchers Gregorio Robles and Jesus M. Gonzalez-Barahona of the Universidad Rey Juan Carlos in Spain define a fork like this:

Forking occurs when a part of a development community (or a third-party not related to the project) starts a completely independent line of development based on the source code basis of the project. To be considered as a fork, a project should have:

And to put things in perspective, it's worth remembering that forking is not that common. Although forks have become more frequent in the last few years, the number of forks has not grown in proportion to the number of free software projects, the researchers found.

Looking at forks from both sides now

Forks may not be all that common, but that doesn’t make the thought of one any less unnerving if the project in question is one your company relies on. So how should CIOs think about forks?

"At one extreme, forking is one of the fundamental rights you have with open source code and we talk about how great it is to have the freedom to fork — it can be a good way to revive a dying project," says Allison Randal, president of the Open Source Initiative.

As an example, Randal points out that before the LibreOffice fork, OpenOffice.org was suffering from "human problems" that prevented the code from moving forward. The LibreOffice fork was successful and now has overshadowed OpenOffice.org.

Unfortunately, forking doesn't always produce such a positive outcome. "I have seen cases when forking a project divides the community, introduces tensions, cuts resources and ultimately kills both projects," Randal says. "If a project splits and you have only half the people working on each side, you get a situation where each is vying for the same users, and they don't get a critical mass. Then you are in trouble."

But there are things you can do to make sure you come out on the right side of the split.

If a fork is announced, you “should treat it as a standard risk assessment exercise," is Randal's advice. "You need to evaluate both forks and see if one has a critical mass of developers — that is the key. You also need to see if one is getting a critical mass of users. If so, then bet on that one because it will win — even if there is no company behind it. If a fork is successful then companies will come in to provide support for the fork."

Real life can be messy

Sometimes it won't be quite so clear if a fork is going to be successful, and neither side will quickly get a critical mass of developers and users. "In that case you should take a wait and see approach, or you could use a different project — or at least look for a back pocket alternative," Randal says.

When Nextcloud forked from ownCloud earlier this year it was the co-founder of ownCloud, Frank Karlitschek, who was behind the fork, and it was he who founded Nextcloud. Despite this, he says that forks are to be avoided whenever possible. "In general forking is not a good thing. 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 spit the community in half," he says.

Karlitschek adds that he was acutely aware when he founded Nextcloud that for a CIO whose company makes use of a project, and who may be paying for a subscription or support package, instigating a fork causes problems that need to be minimized if possible. "If a company (like ownCloud) has customers then you have a responsibility to them, and something you always want to do in a fork situation is keep them happy. You need to make sure it is possible for users to make a smooth transition (to the fork) with no financial loss — and that is really tricky."

He says that with Nextcloud it was important to ensure that that the initial release was a "drop in replacement" for ownCloud that was 100 percent compatible, and Nextcloud also offered to honor ownCloud customers' existing support contracts.

A potential problem for CIOs when trying to judge which branch of a fork to back is that the eventual winner is not always obvious for non-technical reasons, according to Michael Meeks, a key member of the LibreOffice project.

"Branding is a problem when you fork," he points out. "Engineers think a fork is all about features, and LibreOffice is feature packed. But it still took a long time for LibreOffice to take off even though both LibreOffice and OpenOffice are zero cost and you can move freely between them. Building a brand is expensive, and it can be frustrating for a fork if it doesn't have the resources to build the brand.”

Should CIOs fear forks?

The best way to answer this question may be to look at historical data about what happens when a fork occurs.

In their research, Robles and Gonzales-Barahona set out to “document all significant forks.” As of August, 2011, they identified 220 forked projects. In fewer than nine percent of such cases both the original project and the fork were discontinued. And when you take out the case where a project is forked because of the (possible or actual) discontinuation of the original, the original project gets discontinued about 10 percent of the time, and the fork gets discontinued only slightly more frequently (14 percent of the time).

That means that nine times out of 10 the original project or a fork from it will continue to exist to provide you with the software that you have been relying on. That's why Nextcloud's Karlitschek says the best thing to do when faced with a fork is to keep your cool. "My advice to CIOs is to relax, see how the two projects develop and see which one ends up with better features. And then decide in a few months which one to back. It's not something they have to do immediately."