[openstack-dev] [all] [tc] "No Open Core" in 2016

Flavio Percoco flavio at redhat.com
Mon Feb 8 18:26:16 UTC 2016


On 08/02/16 09:24 -0500, Sean Dague wrote:
>On 02/08/2016 08:54 AM, Flavio Percoco wrote:
><snip>
>> Would our votes change if Poppy had support for OpenCDN (imagine it's being
>> maintained) even if that solution is terrible?
>>
>> I guess my question is: When do we start considering a project to be
>> safe from
>> an open source perspective? Because, having support for 1 opensource
>> technology
>> doesn't mean it provides enough (or good) open source ways to deploy the
>> software. If the only supported open solution is *terrible* then
>> deployers would
>> be left with only commercial solutions to choose from.
>
>There is a lot of difference between 1 and 0 options, even if 1 isn't a
>great option. It also means the design has been informed by open
>backends, and not just commercial products.
>

If I'm not misinterpreting the above, you're saying that design adviced by open
source backends give better results. While I'm a huge fan of basing designs on
open source solutions, I don't think the above is necessarily true. I don't
think a solution that comes out of common features taken from commercial
products is bad.

Just to be clear, I do prefer designs based on open solutions but I don't think
those, like Poppy, that provision commercial solutions are bad.

Sorry if I misunderstood you here.

>I think one could also consider Neutron originally started in such a
>state. openvswitch was definitely not mature technology when this effort
>started. You pretty much could only use commercial backends and have
>anything work. The use in OpenStack exposed issues, people contributed
>to proper upstream, things got much much better. We now have a ton of
>open backends in Neutron. That would never have happened if the projects
>started with 0.
>

++

This is exactly where I wanted to get to. So, arguably, the Poppy team could
"simply" take OpenCDN (assuming the license allow for) put it on GH, get a gate
on it and come back to the TC requesting inclusion with the difference this time
it'll have support for 1, very old, open source, CDN software.

This wouldn't be seen as a "nice thing" from a community perspective but,
technically, it'd suffice all the requirements. Right?

I don't think *anyone* will actually contribute to OpenCDN ater that happens and
it'll still require the TC to say: "That solution is not well maintained still,
we need to make sure it's production ready before it can be considered a valid
open source backend for Poppy"

>The flip side is  that CDN is a problem space that no consumers or ops
>are interested in open backends. That's ok, however, if that's the case,
>it doesn't feel OpenStack to me. Just being overlays for commercial
>services seems a different thing that the rest of what's in OpenStack
>today.

Agreed that there's no much interest in having open backends for CDNs but there
*is* interest in CDNs, which are an important part of nowaday's cloud
applications. I personally want my cloud to suggest me something that *works*
and give me a seamless way to integrate with it the same way I integrate with
the DNS solution, messaging solution, etc.

In other words, I want my cloud to provide this and to do so, I agree it doesn't
need to be an "official" project for clouds to deploy it but I do think it's a
valid solution to have in the cloud tools-belt.

>
>I think this is a place where there are lots of reasonable and different
>points of view. And if it was clear cut there wouldn't be the need for
>discussion.

++

Before we get to make any call, I want to make sure we've enough arguments that
we can base our opinions on. In fact, this very email currently has two
different opinions in favor and against including Poppy, although I believe I've
formed my opinion already.

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/ff28c52e/attachment.pgp>


More information about the OpenStack-dev mailing list