Open Stack

Excerpts from Dean Troyer's message of 2016-02-16 12:57:58 -0600:
> On Tue, Feb 16, 2016 at 11:51 AM, Amit Gandhi <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.

I'm not sure why it should be abstracting anything that's already part
of OpenStack. That only makes sense for some types of projects, and
while "CDN-as-a-service" might be interesting that's not what the Poppy
team is building.

> 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.

I brought up Poppy to illustrate the point that definitions that
seem clear in the abstract can be less clear in the concrete. All
of the Poppy code itself is open. There is no more advanced or more
complete version available elsewhere. Yes, it requires some other
service to run.  None of the service providers control the project,
which as you point out below is the source of concern with "open
core".

So I think the project team is doing everything we've asked.  We
changed our policies around new projects to emphasize the social
aspects of projects, and community interactions. Telling a bunch
of folks that they "are not OpenStack" even though they follow those
policies is rather distressing.  I think we should be looking for
ways to say "yes" to new projects, rather than "no."

Doug

> 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
>