<div dir="ltr">I think this depends on the nature of the project.<div><br></div><div>For deployment tools, as we also have witnessed in OPNFV, it tends to have multiple solutions. So it is normal to have multiple such projects although they are solving the same problem generally speaking.</div><div><br></div><div>For projects that has a clear definition on a specific set of features of functionalities which are critical to any cloud infrastructure, then overlapping should be strictly avoided. I don't think for a team that proposes a new project that got a significant overlap with existing project has seriously studies the community or a good intention to collaborate within the community.</div><div><br></div><div>Of course there will be exceptions for implementations in different langs but generally I would prefer to take a strong stance on strictly avoiding the overlap. The benefit we would got as a community is that we will have developers working on projects that is clearly defined both individually and collaboratively without any confusion.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 23, 2018 at 9:50 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[This is meant to be one of (I hope) several conversation-provoking<br>
questions directed at prospective TC members to help the community<br>
understand their positions before considering how to vote in the<br>
ongoing election.]<br>
<br>
In the course of evaluating new projects that have asked to join<br>
as official members of the OpenStack community, we often discuss<br>
whether the feature set of the project overlaps too much with other<br>
existing projects. This came up within the last year during Glare's<br>
application, and more recently as part of the Adjutant application.<br>
<br>
Our current policy regarding Open Development is that a project<br>
should cooperate with existing projects "rather than gratuitously<br>
competing or reinventing the wheel." [1] The flexibility provided<br>
by the use of the term "gratuitously" has allowed us to support<br>
multiple solutions in the deployment and telemetry problem spaces.<br>
At the same time it has left us with questions about how (and<br>
whether) the community would be able to replace the implementation<br>
of any given component with a new set of technologies by "starting<br>
from scratch".<br>
<br>
Where do you draw the line at "gratuitous"?<br>
<br>
What benefits and drawbacks do you see in supporting multiple tools<br>
with similar features?<br>
<br>
How would our community be different, in positive and negative ways,<br>
if we were more strict about avoiding such overlap?<br>
<br>
Doug<br>
<br>
[1] <a href="https://governance.openstack.org/tc/reference/new-projects-requirements.html" rel="noreferrer" target="_blank">https://governance.openstack.<wbr>org/tc/reference/new-projects-<wbr>requirements.html</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Standard Engineer</div><div>IT Standard & Patent/IT Product Line</div><div dir="ltr">Huawei Technologies Co,. Ltd</div><div dir="ltr">Email: <a href="mailto:huangzhipeng@huawei.com" target="_blank">huangzhipeng@huawei.com</a></div><div dir="ltr">Office: Huawei Industrial Base, Longgang, Shenzhen</div><div dir="ltr"><br></div><div dir="ltr">(Previous)<br><div>Research Assistant</div><div>Mobile Ad-Hoc Network Lab, Calit2</div><div>University of California, Irvine</div><div>Email: <a href="mailto:zhipengh@uci.edu" target="_blank">zhipengh@uci.edu</a></div><div>Office: Calit2 Building Room 2402</div><div><br></div><div>OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado</div></div></div></div></div></div></div></div></div>
</div>