<div dir="ltr"><div>I think we're all happy that if a project *does* have a broad support base we're good; this is only the case for projects in one of two situations:<br>- support is spread so thinly that each company involved in the area has elected to support a different solution<br>
- the project is just not that interesting to a wider audience<br><br>It might be less about 'should we even allow its incubation' - yes, in exceptional circumstances we probably should, because it serves a useful purpose in that case of divided loyalties - but what checks should be in place to avoid problems of favouritism over technical merit, and of spreading our support thinly over areas of low demand. Neither of these things is directly a problem of diversity itself (e.g. the 'company gets bored'/'company goes tits up' problem); instead, the diversity serves as a warning flag indicating that decisions should not be taken lightly.<br>
-- <br></div>Ian.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 December 2013 11:40, 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>