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

Matt Aslett writes an interesting follow up to his suggestion that open core vendors give up control over the “core” of their product offering. Matt writes:

“…open core vendors should consider releasing the source code for their core open source project under a more permissive license, or better still via an existing community/foundation.”

If the open source core has value it will attract a true community that will expand its development, with the ongoing contribution of the original vendor of course, while if the proprietary extensions are valuable enough the original vendor ought to be able to compete with proprietary rivals even if they are using the same code to build rival products.”

I agree with Matt’s conclusion, but I don’t think that established open core vendors can make this move. A vendor could choose the open community route from day one and reap its benefits. However, utilizing the open community strategy after the vendor has built an open core business is not likely to have the same results.

Let’s start with an example of a leading open core vendor ABC in the middleware market. ABC controls the development of their GPL’d community edition product. Some of ABC’s paying and non-paying customers have contributed fixes and maybe even a new feature to the community edition. Utilizing the open core business model, ABC is now a recognized brand, has upwards of $10M in revenue and is growing in the high double digits. Let’s say ABC decides to release their community edition product under a permissive license such as the Apache Software License 2.0 (ASL) and further attempts to take it to an existing open source foundation such as the Apache Foundation.

The key driver behind ABC’s move is to benefit from a larger community developing the community edition portion of ABC’s commercial product. But where would this community come from?

First, it’s unlikely that another commercial software vendor, XYZ, will join this new “open community” project. XYZ would not have the established user base or associated brand that ABC does; two key elements needed to sell the proprietary extensions. Also, since ABC has a head start on the proprietary extensions, and has likely chosen to develop higher value extensions first, XYZ has little opportunity to differentiate by delivering valuable proprietary extensions. It’s hard to envision the business case for XYZ to enter the community around ABC’s community edition project.

Second, you could argue that individual contributors will contribute to the project more than they were able to in the past when ABC solely controlled the project. This is completely valid. But I doubt that the contributions will be significant compared to those of a third-party vendor whose business relied on the project.

Now consider if the ABC had started developing its open core product in an open community fashion from day one. Other vendors with business interests would have been encouraged to join the community from early on. These vendors would each have had an opportunity to gain a user base and brand affiliated with the project. Each vendor would have had the benefit of starting with an equal footing, or thereabouts.  This situation is exemplified with Apache Tomcat, where at least 3 different commercial open source software vendors claim to be “the leaders of Tocmat development”.  Each vendor uses Apache Tomcat as the open core portion of a larger commercial product.

To me, the timing of choosing an open community model is critical. For established vendors, I feel it’s too late to consider an open community. But maybe I need to rethink this position?

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

I just posted this as a comment to Josh’s reply to my reply to his JavaOne 2008 pitch:

Josh, come on dude, you’re lumping me in with VCs now?? ;-)

About 1.5 years ago, I used to argue that a project isn’t “a true OSS project” if there isn’t an open community with input and control spread across multiple unrelated entities. I used to hold Apache projects or kernel.org as the gold standard. But then I looked around at OSS vendors that the market held up as poster children. I discussed/argued this notion of “true OSS project” with JBossians. In the end, I realized that single-vendor controlled communities were going to be the rule, not the exception. But I guess you’re suggesting that even when there is a single vendor in control of the project, the vendor can choose to concede some power to the community?

I agree with you 100%. The companies that I list are financially successful, but, relatively speaking, less successful at building a community. As you point out, this has a lot to do with adding financial targets to the open source business model equation. It’s interesting you mention that some of these companies have reached out to you and others for advice on growing OSS communities.

I truly want to believe that the majority of OSS vendors will choose to be more open to third party input and thereby drive a more vibrant community around their projects. However, I need to be convinced that any of the larger OSS vendors will choose to change their business practices. And if these more well known OSS vendors aren’t about to go “truly open” (whatever that means ;-) , it’s unlikely that a VC-backed OSS startup is going to risk losing control of their OSS project.

Let me put my business hat on and play devils advocate: Why exactly do larger OSS vendors need to encourage a more vibrant community around their single-vendor controlled OSS project than what they already have? These leading OSS vendors will continue to drive community traction as new users seek OSS solutions and turn to “the leaders”. More importantly, these OSS vendors are faced with the challenge of converting an already large group of users into paying customers. Does growing the community pie to a larger number truly impact the slice that is willing to pay? It can’t hurt…but does it help in the near term (i.e. the duration over which their revenue targets are most relevant)?

Now let’s see if any of the leading OSS vendors choose to implement strategies to grow their communities by becoming “more open”. Stranger things have happened ;-)