The viability of open source forking

Source code availability is a central factor in establishing trust in the open source community, as knowledge that the source is available can often allay fears about the future of a particular open source project or product. And yet, this trust can often be overstated.

When I wrote about a license change to Solaris 10 a few weeks ago, I consciously chose not to discuss OpenSolaris. At the time, Oracle was still working through its acquisition of Sun, and I felt it prudent to give Oracle time to lay out its vision for OpenSolaris. Although my feelings haven’t changed, based on the information currently available, questions regarding OpenSolaris are starting to generate notable discussion.

[ Keep up with the latest news and insights on open source with InfoWorld’s Technology: Open Source newsletter. ]

To fork or not to fork

Earlier this week the OpenSolaris mailing list was abuzz over the lack of information about a forthcoming release, as well as the overall development model for the open source operating system. Sun — whose Solaris is a proprietary distribution of the OS — helped form the OpenSolaris Governing Board (OGB). As such, decisions surrounding OpenSolaris releases and technology road maps have remained largely within Sun’s control. And given Oracle’s relative silence on its plans for Open Solaris, it was not surprising to see at least one commenter suggesting that the OGB take a stand and ask Oracle to clarify the future of OpenSolaris releases or threaten to sever ties with Oracle.

Said differently, “The source is available, so be warned, Oracle.”

OpenSolaris community member Ben Rockwood wrote a measured response:

Here is where I want to be careful. Asking for autonomy at this juncture would be very foolish I think. If they grant it, they will essentially expect us to fork and re-establish the community without Sun/Oracle resources. That means the website goes, communication is severed, employees are instructed not to putback to the autonomous codebase, etc. I think it would go very very badly and we’d essentially help kill the community.

The size of the community at present is pretty small and relatively inactive. Support for Nexenta, Belenix, etc, is orders of magnitude less so. These projects are productive and active, but the numbers are tiny compared to the official community. Add it all up and I think we have little reason to think that an autonomous community would really have any real support unless we get a sudden and massive influx of contributing developers. So it is, imho, a non-starter.

Another community member, Martin Bochnig, also suggested caution over the issue of a fork, asking:

How are you going to replace the bright brilliant skilled and experienced Sun kernel engineers?

Yet another OpenSolaris community member, Damian Wojslaw, wrote:

We do have a community. It’s alive and well. It’s a community of users and administrators. We don’t have community of developers. And this is why we can’t just fork off and start anew.

These words speak volumes. The community around an open source project or product can certainly be vibrant without having the resources to support a fork. In fact, this is true for many open source communities, which count numerous members, very few of whom would be qualified to develop the open source project further should a fork occur. Worse, even fewer would be interested in doing so.

Insurance when forking isn’t viable For enterprises, your best insurance against fork fallout is to adopt open source products from multivendor communities. This ensures the presence of multiple stakeholders, each of which can reasonably be expected to guide the open source project forward should a fork be required.

Unfortunately, multivendor communities are rare. Far more often, you’ll find open source products developed by a community controlled by a single vendor. In these cases, the likelihood of an organization to reasonably support a fork is higher if a strong partner or system integrator ecosystem exists around the open source project. Another fail-safe against fork fallout would be to implement the paid version of the open source project. Paying a vendor for its work is a good way of ensuring that the vendor isn’t motivated to encourage revenue in ways that end up hurting users.

The best advice, however, may be to simply ignore — or at least put much less weight in — the availability of source code when making a product selection. More often that not, you will have too much at stake elsewhere to take on maintaining a forked source code should difficulties arise.

Follow me on Twitter: SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

This article, “The viability of open source forking,” was originally published at InfoWorld.com. Read more of Rodrigues et al.’s Open Sources blog and follow the latest developments in open source at InfoWorld.com.