Mirantis | The #1 Pure Play OpenStack Company

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?

4 comments
Google Plus Mirantis

4 Responses

  1. Jordan

    Good analysis. And I like the quality of the blog posts by Mirantis. Keep on the good job guys !

    November 11, 2013 08:43
  2. Craig Oda

    Boris, some great points here. Many of us involved with open source businesses are skeptical of the open core model. As part of our ongoing debate around the open core business model, I wrote a blog post about five open source models that are successful.

    http://blog.socialmediasurfer.com/2013/11/linux-is-winning-why-you-should-care.html

    Open Core is unproven. I’m very curious to see who comes out on top of the OpenStack industry. it’s great to see Mirantis taking a stand on the “pure play open source” model. Thanks for fighting the good fight.

    November 12, 2013 13:56
  3. Rob Duncan

    well we are waay into 2014 and documentation on heat and tripleo is still appalling – RDO/puppet, Crowbar and rackspace/chef are easier to find references for. also what about Vmware NSX – seems to be a value add and negates problems with Neutron – which goes a bridge too far.
    Lonely sys admins need more that a blueprint and a git branch – WTFM -where’s the friendly manual?

    April 15, 2014 09:19
  4. Nick Chase

    I agree that the docs are not yet ideal. However, while Heat is an “integrated” project, TripleO is not.

    The Docs team (of which I am a member) has limited resources; the best way to improve this situation is to contribute. Can we count on you for some help?

    April 15, 2014 14:09

Some HTML is OK


or, reply to this post via trackback.