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

Sean Dague sean at dague.net
Fri Feb 5 19:16:12 UTC 2016

On 02/05/2016 01:17 PM, Doug Hellmann wrote:
> Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:
>> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
>>> 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 ?
>> If a project isn't fully functional* then why would we accept it at all? 
>> Imagine this scenario:
>> 1) Heat didn't exist
>> 2) A project exactly like heat applies for OpenStack, that lets you use 
>> templates to create resources to a specification
>> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
>> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
>> templates longer than 200 characters.
> There's a more concrete case being considered right now that is less
> clear to some [1].
> The Poppy project provides an open source service to wrap content
> delivery network APIs. They follow all of our other best-practices,
> but there is apparently no practical open source CDN solution.
> OpenCDN was mentioned, but it seems dead.
> In the absence of any open source solution, the Poppy service is
> only useful when connected to commercial services. The Poppy team
> has provided drivers for several of these (I see akamai, cloudfront,
> fastly, and maxcdn in their "providers" package). Stackalytics shows
> the contributors on the team are mostly from Rackspace[2].  I'm not
> aware of Rackspace owning any of those services, though I'm sure
> they have relationships with one more more.
> My understanding of the "no open core" requirement is about the
> intent of the contributor.  We don't want separate community and
> "enterprise" editions of components (services or drivers).  The
> Poppy situation doesn't seem to be a case of open washing anything,
> or holding back features in order to sell a more advanced version.
> It happens that for Poppy to be useful, you have to buy another
> service for it to talk to (and to serve your data), but all of the
> Poppy code is actually open and there are several services to choose
> from.  There is no "better" version of Poppy available for sale,
> if you buy a PoppyCDN subscription.
> So, is Poppy "open core"?

Whether or not it is, I'm not sure how it is part of a Ubiquitous Open
Source Cloud Platform. Because it only enables the use of commerical

It's fine that it's open source software. I just don't think it's OpenStack.


Sean Dague

More information about the OpenStack-dev mailing list