Fears about the future of an open source vendor or project are laid to rest with the knowledge that “the source is available”. Trust in an open source vendor, project or product is often linked to source code availability. However, this trust is at the very least overstated.

I wrote about a license change to Solaris 10 a few weeks ago and made the conscious decision not to talk about OpenSolaris. Seeing as Oracle was still working through its acquisition of Sun, I felt it prudent to give Oracle more time to lay out their vision for OpenSolaris. My feelings haven’t changed. I use OpenSolairs below as an example based on current information available. I do not want to imply anything about the future of OpenSolaris. Large companies can take time to make decisions.

OpenSolaris is an open source operating system and Sun Solaris is a proprietary distribution of OpenSolaris. While Sun helped form an OpenSolaris Governing Board (OGB), decisions surrounding OpenSolaris releases and technology roadmaps remained within Sun’s control.

We can fork, right?!??:
Earlier this week the OpenSolaris mailing list was abuzz about the lack of information about a forthcoming release and the overall development model for OpenSolaris. Not surprisingly, a one commenter suggested 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 cautious about suggesting a fork, asked:

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

Finally, 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.”

A vibrant community can exist even while that community wouldn’t be reasonably able to support a fork. This is true for many open source communities – lots of users, very few of whom would be qualified to continue developing the open source project should a fork occur, and even fewer who would be interested in doing so.

Insurance when forking isn’t viable:
Adopting open source products from multi-vendor communities is the best insurance for enterprises. There is by definition multiple stakeholders that could reasonably be expected to guide the open source project forward should a fork be required. However, open source products developed by a single vendor controlled community are far more common. 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 suggestion is to use the paid version of the open source project. Paying the vendor for its work is a good way of ensuring that the vendor isn’t motivated to do awkward things that encourage revenue while hurting users.

The best advice may be to simply ignore, or at least put much less weight in, the availability of source code when making a product selection.

Follow me on twitter at: SavioRodrigues

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