On 06/02/16 12:12 +0800, Thomas Goirand wrote:
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.
Providing a driver that sits on top of an open source solution (which apparently doesn't exist in this case) doesn't mean everyone will deploy it on top of it. People could choose non-open technologies and that doesn't - certainly, shouldn't - change the way Poppy works. The same applies for every other services that does *provisioning*, which is exactly what Poppy does. I fail to see how Poppy doesn't provide a provisioning API to CDN technologies/services that can be multi-tenant/multi-datacenter. If it doesn't, then I believe the issue is in Poppy's API and not caused by the lack of open source CDN solutions
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, this, I believe, is certainly an issue but one we shouldn't be discussing in this email thread. [snip] Flavio -- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
