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