Afraid of open core lock-in? The alternative could be worse

Why the threat of lock-in needs to be balanced against the danger of selecting a vendor that can't fund future product evolution

A debate has been raging over the popular open core business model that many open source vendors are using today. Opponents caution buyers from using open core products because of a bait-and-switch that will lock consumers into a closed source product. Proponents of the open core model argue that it balances the rights of users with the revenue aspirations of vendors.

That there is no one true open source business model that vendors use should come as no surprise to InfoWorld readers -- support subscriptions, professional services, dual licensing, and open core are but a few of the adopted business models. It's important to recognize that the business model employed by an open source vendor has a direct impact on your rights and freedoms as a customer.

[ Peter Wayner explains how to profit from open source without selling out. | Keep up with the latest open source trends and news in InfoWorld's Technology: Open Source newsletter. ]

As little as five years ago, the support subscription business model was the de facto choice for new open source vendors. In this model, there was only one version of the product, with equivalent features and functions, available to all users. Paying users could get professional support for the product. But customers realized quickly that they could run the product without support, while addressing their support issues themselves or through community forums. As a result, 15 percent of paying support subscription customers decided not to renew their support subscriptions. This, of course, had an impact on both paying and nonpaying customers, because it reduced the revenue available for further product development.

The open core business model grew in popularity as way to address the lack of a sustained revenue caused by the failure of the support business model. The open core model relies on a core product released under an open source license. The vendor also creates and sells an extended version -- often with enterprise features, additional testing, and integration -- under a commercial, not open source, license on a subscription basis. The license or contractual terms typically prevent a company from continuing to use the product if it stops paying the subscription. In many cases, the source code for the commercial product is also not made available (unlike an open souce product).

As ComputerWorld UK columnist Simon Phipps writes, this open core approach can appear to rely on the open source version of the product not being sufficient for enterprise needs:

To use the package effectively in production, a business probably won't find the functions of the core package sufficient, even in the (usual) case of the core package being highly capable. They will find the core package largely ineffective without certain "extras," and these are only available in the "enterprise version" of the package -- which is not open source.

To use those features, you are forced to be a customer only of the sponsoring company. There's no alternative, no way to do it yourself if the value delivered doesn't justify the expense involved or if you are time-rich and cash-poor. Worse, using the package locks you in to the supplier. If they prove a bad choice as a supplier, or if your business needs change, you have no real choice beyond "take it or leave it."

Phipps makes a valid case in theory -- one that IT buyers should be aware of. However, IT buyers and others that rely on an open core product have more bargaining power than Phipps' analysis suggests.

IT buyers can negotiate to put the source code of the commercial "enterprise version" in escrow should the vendor get acquired or go out of business.

Additionally, because the product core is open source and fully functional in its own right, albeit for less-than-enterprise usage, there's little to prevent a fork of the open source code. This fork could be driven by a new vendor, a collection of business partners, or a collection of customers that rely on the open source project. Contributors to the fork could deliver the enterprise capability that's lacking in the open source core product. This possibility serves to keep the open source vendor from using a crippled open source core to entice and trap users into a commercial version.

And this possibility is not just theory. Marten Mickos, former CEO of MySQL and current CEO of cloud startup Eucalyptus, which follows an open core business model, cites one case where it happened:

Compiere followed an open core model, and yet at one point a fork emerged based on the open core of Compiere. This indicates that open core companies operate within the major forces of free and open source software, and so it also indicates that the market is self-adjusting. If you go too far into the closed mode, you lose traction among open source users and you expose yourself to the threat of forks. Nothing prevents others from developing as [free and open source software] some feature that the vendor has reserved for paying customers only. If you go too far into the open source mode, you may weaken your business model and fail to attract revenues to pay for your operations. Ultimately, customers are the arbiters of success. If they are ready to pay for access to the product or service, the company will have to be seriously mismanaged in order to fail.

I tend to agree with Mickos' pragmatic view on open core products. Open core vendors must work to optimize revenue while not becoming too open or too closed. It's imperative that IT buyers keep vendors from sliding to either end of that spectrum. Using a product from a vendor that is "too closed" puts IT buyers at risk of working with a product around which the ecosystem has dwindled. Alternatively, if the vendor is "too open" and can't generate sufficient revenue to invest in further product development, IT buyers are at risk of adopting a product that can't keep up with market requirements.

Follow me on Twitter at 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, "Afraid of open core lock-in? The alternative could be worse," was originally published at Read more of Rodrigues et al.'s Open Sources blog and follow the latest developments in open source at

Copyright © 2010 IDG Communications, Inc.

How to choose a low-code development platform