Most of the "open core" issues we've run into time and time again were because 
one company had control of both an open and a closed edition and used their 
sole control to prevent features from entering the open edition because they 
wanted to make money off of it in the closed edition.

This most certainly does not apply to Poppy. They have both things that make an 
open source project truly open. an open license, and open governance. Its the 
latter thing that prevents vendor lockin. The irony is, Poppy wants to join 
OpenStack to cement that governance to prevent vendor control which which is 
being used to try and exclude it.

The nice thing about standardizing on Poppy would be it might lower the bar for 
a truly open CDN to be created because there might finally be visible enough 
demand for it. "My users want the api, and there isn't an open backend.. let me 
go write one...."

The OpenSource world steps up with an implementation of something when it 
finally decides to scratch the itch. an open CDN has not been a significant 
enough itch to scratch so far.

An open api for CDN's on the other hand does seem like a useful thing to me, 
separate from an open CDN to back it. I'd greatly prefer to write apps against 
such a system instead of targeting the proprietary api's directly. It makes the 
open source code I write more open.

Yes, this is a sucky position to be in, but I think in this one case, its the 
lessor of two evils.

Thanks,
Kevin
________________________________
From: Dean Troyer [dtro...@gmail.com]
Sent: Tuesday, February 16, 2016 10:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On Tue, Feb 16, 2016 at 11:51 AM, Amit Gandhi 
<amit.gan...@rackspace.com<mailto:amit.gan...@rackspace.com>> wrote:
Poppy intends to be an abstraction API over the various CDNs available.  We do 
not want to be in the business of building a CDN itself.

Specific to the Poppy discussion, I think this is another point that makes 
Poppy not part of OpenStack: none of the services it wants to abstract are part 
of OpenStack.  I came up with another example of a project that takes the 
Compute API and translates it to gce or aws calls but we actually have this 
situation with the ESX hypervisor driver and multiple Cinder backends to 
commercial products.  But in those cases, the project is otherwise useful to an 
OpenStack deployment that does not include those products.

Now for the actual thread topic of open core and non-free backends.  We seem to 
be haggling over the declaration of one or more specific projects as 'open 
core-like', where the real discussion is in defining the general terms.  I have 
always thought of 'open core' in the Eucalyptus sense like what partially 
spurred the creation of Nova in the first place.  The same entity controlled 
both an 'open source' project and a commercial product based on it, where 
certain features/capabilities were only available in the non-free version.

What I think is important here is 'the same entity'.  This is where we need to 
be concerned, specifically with organizations that attempt to extract value 
from OpenStack yet hinder our advancement in return by holding back 
contributions.  And this may be the one place where the 'viral' nature of the 
GPL would have been useful to us in a business relationship. [[NO I do not 
intend to open that can'o'worms, only to illustrate our lack of that built-in 
mechanism to lessen the impact of open core]]

dt


--

Dean Troyer
dtro...@gmail.com<mailto:dtro...@gmail.com>
__________________________________________________________________________
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

Reply via email to