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
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
