[openstack-dev] [all][tc] Require a level playing field for OpenStack projects

Doug Hellmann doug at doughellmann.com
Tue Jun 14 16:16:05 UTC 2016

Excerpts from Hayes, Graham's message of 2016-06-14 14:44:36 +0000:
> On 14/06/2016 15:00, Thierry Carrez wrote:
> > 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 ?
> >
>  From our perspective, we (designate) currently have a few drivers from 
> proprietary vendors, and would like to add one in the near future.
> The current drivers are marked as "release compatible" - aka someone is
> nominated to test the driver throughout the release cycle, and then
> during the RC fully validate the driver.
> The new driver will have 3rd party CI, to test it on every commit.
> These are (very) small parts of the code base, but part of it none
> the less. If this is passes, should we push these plugins to separate
> repos, and not include them as part of the Designate project?

No. What you're doing is perfectly acceptable. Obviously the more
testing you can do, the better, but it's up to the Designate team to
decide what code contributions it considers it can support as part of
it's official code base. Whether that is organized in one repository or
many is also up to the owners of the code.

The problem has come up because other teams have decided they cannot
manage the large number of disparate drivers. Those have been moved
out of the main source tree, and those repositories are now being
de-listed from the "official" list in the governance repo.

> As another idea - if we have to move them out of tree - could we have
> another "type" of project?
> A lot of projects have "drivers" for vendor hardware / software -
> could there be a way of marking projects as drivers of a deliverable -
> as most of these drivers will be very tied to specific versions of
> OpenStack projects.

The location of the code is an implementation detail when it comes
to describing the thing we ship.  A "deliverable" can be made up
of more than one repository. If the drivers are so tightly tied to
the core parts, then I suggest just keeping them together in one
deliverable, or even one repository.

> I fully agree with the sentiment, and overall aim of the requirement,
> I just want to ensure we have as little negative impact on deployers
> as possible.
>   -- Graham

More information about the OpenStack-dev mailing list