On 02/05/2016 06:57 PM, 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 ?
As I understand, Poppy a kind of middleware that does network access (an "wrapper API"), right? This is comparable to let's say Pidgin, which accesses proprietary services like Google talk, Yahoo messenger and such. I have no problem with such a software, which I consider completely free, even if they access a non-opened reverse engineered network protocol. The problem, to me, is different. It is more related to what kind of value Poppy brings to OpenStack as a whole. And to me, that's where the problem is. It's very low value, because its area is very far from what we do: bring a fully open cloud. And Poppy only publishes to external (commercial) service providers, it doesn't publish things within let's say a multi-datacenter OpenStack deployment through a VM image it would use. Moreover, its requirement of Cassandra DB is a no-go (this has already been discussed in another thread: Cassandra doesn't work well on OpenJDK at all, which makes it non-free as it requires a Java interpreter which is non-free itself). If I had to upload Poppy to Debian, it would be uploaded to contrib (which is the area where free software requiring non-free software to run or be built are uploaded). Contrib isn't officially part of Debian. So, to accept Poppy, IMHO, it would have to: 1/ Get away from Cassandra and use a db driver which is truly free. The "Your own DB provider here" in the README.rst is not satisfying enough, and another db provider *must* be promoted to 1st class citizen. 2/ Puppy *must* permit to use OpenStack deployments only across multiple datacenters (multiple regions?) and be completely useful without the need of external resources. Until these 2 issues aren't solved, I see no point in accepting Poppy under the big tent, even if I consider Poppy itself fully free-software (and not open-core as Thierry wrote). The above points 1 and 2 are solvable, and maybe the authors will want to do something about it. I hope this helps, Cheers, Thomas Goirand (zigo) __________________________________________________________________________ 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