Open Stack

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.

Nice summary.  I agree that some clarification would be helpful given to
match our current reality.

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

I agree with your take.  I'm not too worried about coming up with a
strict definition for what a reasonable open source backend is.  We can
throw in some desirable traits like you have done, and then leave it to
the TC to evaluate.  I think that's a reasonable part of the TC's job.

-- 
Russell Bryant