Open Stack

On 02/05/2016 01:17 PM, Doug Hellmann wrote:
> Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:
>> On 02/05/2016 05:57 AM, 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 ?
>>
>> If a project isn't fully functional* then why would we accept it at all?
>> Imagine this scenario:
>>
>> 1) Heat didn't exist
>> 2) A project exactly like heat applies for OpenStack, that lets you use
>> templates to create resources to a specification
>> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing
>> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse
>> templates longer than 200 characters.
>
> There's a more concrete case being considered right now that is less
> clear to some [1].
 >
> The Poppy project provides an open source service to wrap content
> delivery network APIs. They follow all of our other best-practices,
> but there is apparently no practical open source CDN solution.
> OpenCDN was mentioned, but it seems dead.

This doesn't surprise me, since most of the "value-add" from a CDN is in 
the "we have points of presence and peering agreements" and less about 
"we use software XYZ". Take, for instance, a typical CDN pricing 
structure. You pay tiered on some combination bandwidth used and the 
number of points-of-presence you want your content served from.

Open source projects aren't usually set up around making big capital 
expenditures and buying lots of bandwidth, so the lack of a FOSS CDN 
isn't exactly Poppy's fault.

> In the absence of any open source solution, the Poppy service is
> only useful when connected to commercial services. The Poppy team
> has provided drivers for several of these (I see akamai, cloudfront,
> fastly, and maxcdn in their "providers" package). Stackalytics shows
> the contributors on the team are mostly from Rackspace[2].  I'm not
> aware of Rackspace owning any of those services, though I'm sure
> they have relationships with one more more.

Even in the absence of an open source CDN, I struggle to call poppy 
"open core" in the spirit of "you must buy our enterprise plan" because 
it still doesn't require paying any single vendor. I can still choose 
the commodity (bandwidth, datacenter locations, etc) provider.

This actually proves my point about the community/TC being intelligent 
and being able to make decisions about this sort of thing. A written 
rule about open core might mean we couldn't allow Poppy into the tent, 
but because we have the broader 4-Opens we can look at it and say "yeah, 
it requires you pay for a service, but it's clearly enabling many 
vendors and making it EASIER to switch, which is great."

> My understanding of the "no open core" requirement is about the
> intent of the contributor.  We don't want separate community and
> "enterprise" editions of components (services or drivers).  The
> Poppy situation doesn't seem to be a case of open washing anything,
> or holding back features in order to sell a more advanced version.
> It happens that for Poppy to be useful, you have to buy another
> service for it to talk to (and to serve your data), but all of the
> Poppy code is actually open and there are several services to choose
> from.  There is no "better" version of Poppy available for sale,
> if you buy a PoppyCDN subscription.
>
> So, is Poppy "open core"?
>
> Doug
>
> [1] https://review.openstack.org/#/c/273756/
> [2] http://stackalytics.com/?project_type=all&release=all&module=poppy&metric=commits

I'd say no, Poppy is an open source project/product that makes it easier 
to use the different vendors of commodity services, and that's not a 
reason to boot it.

Sidebar: I recall a few years ago that Rackspace's CDN offering was 
based on Akamai, so read into that whatever you want I guess. They at 
least used to have a relation with Akamai at some point.

-- 
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.