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 -- Sean Dague http://dague.net __________________________________________________________________________ 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