There is no open core in OpenStack
The most common model of monetizing open source is the “open core” model; the model where you build value add, proprietary features around an open source project that you package into a supported enterprise version. Eucalyptus, Alfresco and Cloudera choose this model in their respective industry segments. This post by Mike Olson also argues that “open core” is the only model that stands a chance in the open source world, and he may be right… but how can you make open core work with OpenStack?
For “open core” there must be a “core”
While there is an ongoing discussion to crisp up the definition of OpenStack core, I don’t believe that any artificially imposed “core” definitions tied to trademark control will make much difference to the market. OpenStack is the fastest growing open source movement in history. As OpenStack expands at an unprecedented pace, the reach of OpenStack upstream initiatives is swallowing any potential proprietary value add anyone could add around “the core.” Unlike with Hadoop or MySQL that are products with crisp definition, nobody really can tell what upstream OpenStack is today and how wide it will go.
OpenStack commoditizes value-add faster than value-add appears
The first sign of things to come was project Ceilometer. Several vendors had made forays to monetize metering and billing in OpenStack in the early days. Ceilometer quickly came and swept up the space as the default metering system for OpenStack, eradicating much of the value around that “value add” dimension. Today Ceilometer is starting to eat away at OpenStack monitoring as well.
The most common value-add component OpenStack vendors still differentiate with involves deployment and management. Think Canonical Juju, Dell Crowbar (used by default in the SUSE distro), StackOps, Fuel, etc. Enter TripleO and Tuskar. Goodbye differentiation around deployment and management.
The most recent example of this is OpenStack’s forays into the PaaS space via project Solum and certain Heat blueprints, which threaten the configuration management space.
Why does this matter?
Today, every time you bundle OpenStack with a proprietary, value-add component and sell it to a customer, there is a risk that a native OpenStack implementation of that proprietary component will shortly become available upstream. When this happens, your customer ends up on a fork, not supported by the broader OpenStack community.
OpenStack history so far has shown that seeding an early project in the community will always win over open sourcing something proprietary with a lot of code. “Oh, I’ll just open source it when OpenStack implements my value-add component upstream” – doesn’t work. Once you start on a proprietary route, you are on a fork and there is no way back.
Given most OpenStack adopters today buy into its community momentum first, and feature-function – a distant second, those in business of selling “OpenStack forks” differentiated by richer features are not likely to make it.
The discussion also begs a question. If there is no open core in OpenStack and there is no money in open source other than open core, who will win the OpenStack game?
