[openstack-dev] [all] [tc] "No Open Core" in 2016

Thierry Carrez thierry at openstack.org
Fri Feb 5 10:57:35 UTC 2016


Hi everyone,

Even before OpenStack had a name, our "Four Opens" principles were 
created to define how we would operate as a community. The first open, 
"Open Source", added the following precision: "We do not produce 'open 
core' software". What does this mean in 2016 ?

Back in 2010 when OpenStack was started, this was a key difference with 
the other open source cloud platform (Eucalyptus) which was following an 
Open Core strategy with a crippled community edition and an "enterprise 
version". OpenStack was then the property of a single entity 
(Rackspace), so giving strong signals that we would never follow such a 
strategy was essential to form a real community.

Fast-forward today, the open source project is driven by a non-profit 
independent Foundation, which could not even do an "enterprise edition" 
if it wanted to. However, member companies build "enterprise products" 
on top of the Apache-licensed upstream project. And we have drivers that 
expose functionality in proprietary components. So what does it mean to 
"not do open core" in 2016 ? What is acceptable and what's not ? It is 
time for us to refresh this.

My personal take on that is that we can draw a line in the sand for what 
is acceptable as an official project in the upstream OpenStack open 
source effort. It should have a fully-functional, production-grade open 
source implementation. If you need proprietary software or a commercial 
entity to fully use the functionality of a project or getting serious 
about it, then it should not be accepted in OpenStack as an official 
project. It can still live as a non-official project and even be hosted 
under OpenStack infrastructure, but it should not be part of 
"OpenStack". That is how I would interpret "no open core" in OpenStack 2016.

Of course, the devil is in the details, especially around what I mean by 
"fully-functional" and "production-grade". Is it just an API/stability 
thing, or does performance/scalability come into account ? There will 
always be some subjectivity there, but I think it's a good place to start.

Comments ?

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list