A debate has been raging over the popular open core business model that many open source vendors are utilizing today. Opponents caution buyers from using open core products because of a bait-and-switch that will lock-in buyers to 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 open source vendors utilize would come as no surprise to InfoWorld readers – support subscriptions, professional services, dual licensing and open core are but a few of the business models utilized. It’s important to recognize that the business model an open source vendor utilizes has a direct impact on your rights and freedoms when utilizing a product from the vendor.

As little as five years ago, the support subscription business model was the de facto choice for new entrants into the open source vendor arena. In this model, there was only one version of the product, with equivalent features and functions, available to all users. Paying users were able to get professional support for the product in question. But customers realized quickly that they could run the product without support and address their support issues themselves or through community forums.

Vendors watched as 15 percent of paying support subscription customers decided not to renew their support subscriptions. This of course had an impact on paying and non-paying customers, since the revenue lost could have been used to fund further development of the product.

The open core business model grew in popularity as a means of addressing the lack of a sustained revenue trigger.

The open core model relies on a core product released under an open source license. However, that core product is expanded upon, often with enterprise features, additional testing and integration. The vendor sells this superset product under a commercial, not open source, license on a subscription basis. There are often license or contractual terms that prevent a company from continuing to use the commercially licensed product if they stop paying the subscription. In many cases, the source code for the commercial product is not made available.

ComputerWorld UK columnist Simon Phipps writes:

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

Simon makes a valid case in theory – one that IT buyers should be aware of.

However, IT buyers and others that rely on a given open core product, such a business partners that sell services around the product, have more bargaining power than Simon’s analysis suggest.

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

Additionally, since the core of the product is open source, and is fully functional in its own right, albeit for less than enterprise usage patters, little prevents a fork of the open source code. This fork could be driven by through a new vendor, a collection of business partners or a collection of customers that rely on the open source project in question. Contributors to the fork could deliver the enterprise capability that is lacking in the open source core product. While this too is theory, it’s theory that serves to keep the open source vendor from extracting too much value out of the community that forms around open source products.

Marten Mickos, former CEO of MySQL and current CEO of cloud start-up Eucalyptus, which follows an open core business model, writes:

“For instance, 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 FOSS 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 Marten’s pragmatic view on open core products. Open core vendors must work to optimize revenue while not becoming too open or to closed. It’s imperative that IT buyers keep vendors form sliding to either end of that spectrum.  Using a product from a vendor that is “too closed” puts IT buyers at risk of using a product around which the ecosystem has dwindled.  Alternatively, if the vendor is “too open”, and isn’t able to generate sufficient revenue to invest in further product development, IT buyers are at risk of using a product that isn’t able to 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.”