The viability of open source forking

OpenSolaris reminds us why open community matters far more than open code

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.
1 2 Page 1
From CIO: 8 Free Online Courses to Grow Your Tech Skills