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 <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
