Open Stack

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 [dtroyer at 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.gandhi at rackspace.com<mailto:amit.gandhi at 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
dtroyer at gmail.com<mailto:dtroyer at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160216/db78916e/attachment.html>