Wild Webmink

The open core business model has been feted as the new default open source business model, especially by venture capitalists; so much so that the presence of an open core model is a great indicator of VC funding behind a new company. But I assert it does not deliver and sustain the principle that delivers cost savings and flexibility to the customer – software freedom. As a consequence, businesses who live-or-die by open core risk the fate of Compiere ERP unless they can manage the incredibly delicate balance their customers will discover they demand.

This essay was triggered by a discussion in mid-2010. In an interview Mårten Mickos, the former CEO of MySQL and then newly appointed CEO of cloud technology company Eucalyptus, indicated that Eucalyptus is open core. He said:

“We deliver a fully functional cloud with Eucalyptus software. You can download it on a GPL v3 license. But, additionally, we provide enterprise features only if you pay for them … it’s open core,”

While that sounds reasonable, there are unstated issues in that approach and I challenged them in my blog. Responding there, Mårten asserted open core is nothing new, that the Apache founders invented it and that it is fundamental to open source – a view contested by Mårten’s former colleagues Henrik Ingo and Brian Aker.

A Game On Software Freedom

All systems have loopholes. It has been said that any system contains within itself by implication the game that will exploit it. Exploiting the loopholes is almost always an unintended consequence of the system. The open core model exploits open source and is a game on software freedom. The fact the game is played does not invalidate software freedom, but it suggests we need to revisit definitions and make the game harder to play.

Open core is a game on rather than a valid expression of software freedom, because it does not cultivate software freedom for the software user. In an open core business, there is a core package which is open source and which delivers basic functions. That package can be used freely under the terms of an open source licence, and there’s no issue involved at this point – as Lampitt asserts,

the customers enjoy, in a way, guarantee of liberty from the vendor; if things go sideways for the vendor, there is a sort of a “guaranteed escrow” of the source code.

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”. In many cases, ending your subscription with the supplier will mean losing your rights to use the Enterprise Version all together.

Hiding The Problem In Plain Sight

It is typical of open core apologists to skip this point entirely, preferring to put opposition such as mine down to religious fundamentalism and trying to hide the problems in plain sight. They confuse “dual licensing” (which can respect customer liberties) with open core (which can’t) without observing dual licenses doesn’t apply to the closed add-ons most “open core” vendors sell.

They speak of “vibrant communities” but in most cases those are user communities, not communities of alternative co-developers offering an alternative to the closed add-ons. They speak of “lively ecosystems” without noting that most open core vendors use their power over the code to try to ensure those ecosystems are built of partners, not alternatives. Open core is also not a guaranteed win, even for a great system like Compiere ERP. According to its founder Jorge Janke:

Compiere certainly did not fail due to its technology. It failed due to lack of sales and marketing expertise, execution and the wrong bet to “upgrade” open source minded partners and customers to a traditional, commercial model. I think that the Commercial Open Source model is still valid, but Compiere overstepped the balance between proprietary and open product components.

This is not to say it’s never OK to wrap additional services around an open source project. In different ways, both the GPL-ish and BSD-ish wings of the open source movement depend on that ability. Mårten’s assertion that Apache “invented open core” is a fascinating interpretation, though.  I asked Justin Erenkrantz, then president of the Apache Software Foundation, how he viewed open core. He replied:

Open core – as it is practiced within Apache – is that the functionality which makes the product compelling to its users is freely available and released through the auspices of the foundation. It is critical that the open offering be able to stand on its own and address the needs of the community or it will not be attractive enough to merit a diverse community which adheres to Apache’s standards. Since the open offering is released under a permissive license and developed in a transparent manner, the various collaborators within the Apache community – many of which have significant revenue streams or venture capital backing – are able to offer their own products which incorporate and complement the open option.

Yes, the whole premise of Apache was that its founders could share the various Apache projects as a “core” for other work, but in every case the Apache project is complete and sufficient for deployment at an enterprise level including “the functionality which makes the product compelling to its users”. As Mårten himself is prone to say, some people have money and need time, and others have time and want money. Open source allows both to participate freely; open core does not.

Conclusions

To generalize the analysis, the problem with open core is that instead of delivering and cultivating software freedom, the open core business model induces dependency on closed software and lock-in to a vendor. Open core businesses hope that you will be willing to trade your freedom for tangible short-term benefits or even just for “shiny”.

They stand to benefit massively from having you locked-in; they want to trade your freedom for their profit. So while open core businesses truthfully say they are sustaining open source core software, their actual business is nothing to do with open source. It’s a bait-and-switch, wrapping the same old lock-in in the flag of open source and hoping you won’t notice.

This is not just a philosophical game. ‘Software freedom’ may sound abstract, but it is the system of thinking behind the very practical and tangible benefits that have drawn vast numbers of businesses to use open source. As I have written previously, the four freedoms (to use, study, modify and distribute the software without restriction) have created a vast market by enabling cost-savings and flexibility. So a business model that cultivates a casual disregard for and discarding of those liberties while pretending otherwise deserves to be challenged.

[First published in ComputerWorldUK]

This essay is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
While you are not compelled to do so, the author would welcome notification of derivatives, especially translations which will be gladly posted here. If your intended use is commercial, please do ask for permission as it is usually granted; it is  withheld because of past abuses.