<div dir="ltr">I would vote for the approach number 2. I think there are some distinct advantages for one company driving the development of a certain feature sets early in the life of the project, typically, the speed of development is faster, and it is easier to achieve focus early on. <div>
<br></div><div>Allowing important initiatives to become incubated projects early will actually increase the speed of innovation and will encourage companies to tackle real problems sooner.<br><div><br></div><div>Having said that, however, I believe that building sustainable communities is of paramount importance for the long term viability of <span class="" style>OpenStack</span> and its components. So, my preference would be to limit the incubation to let us say two cycles if a project failed to build a community. </div>
</div></div><div class="gmail_extra"><br clear="all"><div><span style="color:rgb(0,0,0);font-family:verdana,sans-serif">Alex Freedland</span><br style="color:rgb(0,0,0);font-family:verdana,sans-serif"><span style="color:rgb(0,0,0);font-family:verdana,sans-serif">Co-Founder and Chairman</span><br style="color:rgb(0,0,0);font-family:verdana,sans-serif">
<span style="color:rgb(0,0,0);font-family:verdana,sans-serif">Mirantis, Inc.</span><br style="color:rgb(51,204,255);font-family:comic sans ms,sans-serif"><br><br></div>
<br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 2:40 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<br>
The TC meeting yesterday uncovered an interesting question which, so<br>
far, divided TC members.<br>
<br>
We require that projects have a number of different developers involved<br>
before they apply for incubation, mostly to raise the bus factor. But we<br>
also currently require some level of diversity in that development team:<br>
we tend to reject projects where all the development team comes from a<br>
single company.<br>
<br>
There are various reasons for that: we want to make sure the project<br>
survives the loss of interest of its main corporate sponsor, we want to<br>
make sure it takes into account more than just one company's use case,<br>
and we want to make sure there is convergence, collaboration and open<br>
development at play there, before we start spending common resources in<br>
helping them integrate with the rest of OpenStack.<br>
<br>
That said, it creates a chicken-and-egg issue: other companies are less<br>
likely to assign resources and converge to a project unless it gets<br>
blessed as THE future solution. And it's true that in the past a lot of<br>
projects really ramped up their communities AFTER being incubated.<br>
<br>
I guess there are 3 options:<br>
<br>
1. Require diversity for incubation, but find ways to bless or recommend<br>
projects pre-incubation so that this diversity can actually be achieved<br>
<br>
2. Do not require diversity for incubation, but require it for<br>
graduation, and remove projects from incubation if they fail to attract<br>
a diverse community<br>
<br>
3. Do not require diversity at incubation time, but at least judge the<br>
interest of other companies: are they signed up to join in the future ?<br>
Be ready to drop the project from incubation if that was a fake support<br>
and the project fails to attract a diverse community<br>
<br>
Personally I'm leaning towards (3) at the moment. Thoughts ?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>