Open Stack

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"?

Doug

[1] https://review.openstack.org/#/c/273756/
[2] http://stackalytics.com/?project_type=all&release=all&module=poppy&metric=commits