On 06/14/2016 10:44 AM, Hayes, Graham wrote: > 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? > > 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. > > 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
I highly recommend you spend some time interacting with the Neutron, Nova, Cinder and Ironic communities to learn how they approach this issue. Each community has a slightly different approach to interacting with vendors with different pain points in each approach. I think learning from these projects regarding this issue would be a great way to formulate your best plan for designate. Also time spent with Mike Perez on this issue is an investment as far as I'm concerned. Thank you, Anita. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
