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

Gareth academicgareth at gmail.com
Fri Feb 5 17:15:45 UTC 2016

I think that will become a clear definition but not a strict one :) In
Huawei, each release of product will be evaluated by availability,
security, usability, maintainability and something else. Those design
ideas looks difficult but could drive projects stronger.

On Sat, Feb 6, 2016 at 12:49 AM, Russell Bryant <rbryant at redhat.com> wrote:
> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Gareth (Kun Huang)

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang at freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ¥1 to an open organization you specify.

More information about the OpenStack-dev mailing list