The most common model of monetizing open source is the “open core” model. 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?
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.
Here is an example. The most common value-add component OpenStack vendors still differentiate with is around deployment and management. Canonical Juju, Dell Crowbar (used by default in SUSE distro), StackOps, Fuel and so on. Enter TripleO and Tuskar. Goodbye differentiation around deployment and management.
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. Given most OpenStack adopters today buy into its community momentum first and feature function second — a distant second — those in business of selling “OpenStack forks” differentiated by richer features are not likely to make it.