Open Stack

Excerpts from Kyle Mestery's message of 2016-06-15 09:05:59 -0500:
> On Tue, Jun 14, 2016 at 9:15 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> > Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
> >> Hi everyone,
> >>
> >> I just proposed a new requirement for OpenStack "official" projects,
> >> which I think is worth discussing beyond the governance review:
> >>
> >> https://review.openstack.org/#/c/329448/
> >>
> >>  From an upstream perspective, I see us as being in the business of
> >> providing open collaboration playing fields in order to build projects
> >> to reach the OpenStack Mission. We collectively provide resources
> >> (infra, horizontal teams, events...) in order to enable that open
> >> collaboration.
> >>
> >> An important characteristic of these open collaboration grounds is that
> >> they need to be a level playing field, where no specific organization is
> >> being given an unfair advantage. I expect the teams that we bless as
> >> "official" project teams to operate in that fair manner. Otherwise we
> >> end up blessing what is essentially a trojan horse for a given
> >> organization, open-washing their project in the process. Such a project
> >> can totally exist as an unofficial project (and even be developed on
> >> OpenStack infrastructure) but I don't think it should be given free
> >> space in our Design Summits or benefit from "OpenStack community" branding.
> >>
> >> So if, in a given project team, developers from one specific
> >> organization benefit from access to specific knowledge or hardware
> >> (think 3rd-party testing blackboxes that decide if a patch goes in, or
> >> access to proprietary hardware or software that the open source code
> >> primarily interfaces with), then this project team should probably be
> >> rejected under the "open community" rule. Projects with a lot of drivers
> >> (like Cinder) provide an interesting grey area, but as long as all
> >> drivers are in and there is a fully functional (and popular) open source
> >> implementation, I think no specific organization would be considered as
> >> unfairly benefiting compared to others.
> >>
> >> A few months ago we had the discussion about what "no open core" means
> >> in 2016, in the context of the Poppy team candidacy. With our reading at
> >> the time we ended up rejecting Poppy partly because it was interfacing
> >> with proprietary technologies. However, I think what we originally
> >> wanted to ensure with this rule was that no specific organization would
> >> use the OpenStack open source code as crippled bait to sell their
> >> specific proprietary add-on.
> >>
> >> I think taking the view that OpenStack projects need to be open, level
> >> collaboration playing fields encapsulates that nicely. In the Poppy
> >> case, nobody in the Poppy team has an unfair advantage over others, so
> >> we should not reject them purely on the grounds that this interfaces
> >> with non-open-source solutions (leaving only the infrastructure/testing
> >> requirement to solve). On the other hand, a Neutron plugin targeting a
> >> specific piece of networking hardware would likely give an unfair
> >> advantage to developers of the hardware's manufacturer (having access to
> >> that gear for testing and being able to see and make changes to its
> >> proprietary source code) -- that project should probably live as an
> >> unofficial OpenStack project.
> >>
> >> Comments, thoughts ?
> >>
> >
> > I think external device-specific drivers are a much clearer case than
> > Poppy or Cinder. It's a bit unfortunate that the dissolution of some
> > projects into "core" and "driver" repositories is raising this issue,
> > but we've definitely had better success with some project teams than
> > others when it comes to vendors collaborating on core components.
> >
> 
> I don't see this as the "core and driver" problem bringing this issue
> up, as it exists out side of that. But it's true that in the case of
> Neutron, something had to give when we had 40+ drivers and a handful
> of cores maintaining both the neutron code itself and those drivers.

Sure! What I meant was that it's a shame so much maintenance fell to so
few folks. I wasn't second-guessing the hard choice to clarify what the
Neutron team felt you could support. That's completely within your
purview.

Doug