Excerpts from Sean Dague's message of 2016-02-05 14:16:12 -0500: > 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 > services. > > It's fine that it's open source software. I just don't think it's OpenStack. > > -Sean
I don't understand the connection you're making. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev