Open Stack

On 08/02/16 10:52 -0800, Mike Perez wrote:
>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.

This is not my interpretation of what was written in the email I was replying to
but I take I might have misread it (as I actually mentioned).

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

Sure, still valid though. The Poppy team could even have its own reference
implementation, TBH. That's why I asked what I asked in the email Sean replied
to:

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

Cheers,
Flavio

P.S: I'm playing the devils advocate here. I want to make sure we discuss some
of these things through and there's enough feedback from the community.

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