Open Stack

On 13:56 Feb 08, Flavio Percoco wrote:
> 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.

Nobody said providing commercial solutions is bad. Only providing commercial
solutions and having infra provide something in gate that's *dependent* on
a commercial entity is bad.

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

If Poppy was to be picked as OpenCDN as their reference implementation:

* Everything in the API should work with the reference implementation so it can
  be tested.

* If only a commercial solution can do something exposed in the API, that's
  bad. Your API is now dictated by some implementations.

You better believe there's going to be some investment in making OpenCDN work
if gate jobs are depending on it passing. If you want to introduce some shiny
new checkbox feature from a CDN, there's going to also be investment in making
it work with the reference implementation.

-- 
Mike Perez