Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160208/f3c40ad5/attachment.pgp>