Open Stack

On 02/05/2016 12:14 PM, Ryan Brown 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.
>>
>> 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.
> 
> Would *any* TC count that as a project that could join under our current
> system? I don't think so. The TC (and community) would say something
> along the lines of "WTF are you thinking? Go read the 4 opens and try
> again"

I think it is a point of strength that so many in our community
including the TC both individually and collectively are able to
communicate perspectives and decisions without referencing profanity.

So I happen to disagree with your current characterization as worded.

Thank you,
Anita.

> 
> I don't think adding "no open core" would change a decision the
> future-community and future-tc might make, because they will be elected
> by aforementioned community. Adding buzz-requirements like "must be
> fully-functional, production grade, webscale open-cloud softwidgets"
> isn't going to help future-us.
> 
> Footnotes:
> 
> * in my view, an openstack product that requires you to pay a vendor is
> as functional as an openstack product chock-full of syntax errors
> 
> ** Shed Cat Enterprise Leopard is strictly fictional, and not based on
> any company that currently or ever has existed.
>