<div dir="ltr">On 21 August 2014 12:12, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">Let the ones that are primarily interested in<br>
</div>
good quality of that code (vendors) to drive development. And if some<br>
plugins become garbage, it's bad news for specific vendors; if neutron<br>
screws because of lack of concentration on core features and open<br>
source plugins, everyone is doomed.<br></blockquote><div><br></div><div>Completely agree with this sentiment. Is there a crisp distinction between a "vendor" plugin and an "open source" plugin though?</div>
<div><br></div><div>The Snabb NFV (<a href="http://snabb.co/nfv.html">http://snabb.co/nfv.html</a>) driver superficially looks like a vendor plugin but is actually completely open source. The development is driven by end-user organisations who want to make the standard upstream Neutron support their NFV use cases.</div>
<div><br></div><div>We are looking for a good way to engage with the upstream community. In this cycle we have found kindred spirits in the NFV subteam., but we did not find a good way to engage with Neutron upstream (see <a href="https://review.openstack.org/#/c/116476/">https://review.openstack.org/#/c/116476/</a>). It would be wonderful if there is a suitable process available for us to use in Kilo e.g. incubation.</div>
<div><br></div><div>Cheers,<br></div><div>-Luke</div><div><br></div><div><br></div></div></div></div>