Open Stack

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.

Allowing important initiatives to become incubated projects early will
actually increase the speed of innovation and will encourage companies to
tackle real problems sooner.

Having said that, however, I believe that building sustainable communities
is of paramount importance for the long term viability of OpenStack 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.

Alex Freedland
Co-Founder and Chairman
Mirantis, Inc.




On Wed, Dec 18, 2013 at 2:40 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Hi everyone,
>
> The TC meeting yesterday uncovered an interesting question which, so
> far, divided TC members.
>
> We require that projects have a number of different developers involved
> before they apply for incubation, mostly to raise the bus factor. But we
> also currently require some level of diversity in that development team:
> we tend to reject projects where all the development team comes from a
> single company.
>
> There are various reasons for that: we want to make sure the project
> survives the loss of interest of its main corporate sponsor, we want to
> make sure it takes into account more than just one company's use case,
> and we want to make sure there is convergence, collaboration and open
> development at play there, before we start spending common resources in
> helping them integrate with the rest of OpenStack.
>
> That said, it creates a chicken-and-egg issue: other companies are less
> likely to assign resources and converge to a project unless it gets
> blessed as THE future solution. And it's true that in the past a lot of
> projects really ramped up their communities AFTER being incubated.
>
> I guess there are 3 options:
>
> 1. Require diversity for incubation, but find ways to bless or recommend
> projects pre-incubation so that this diversity can actually be achieved
>
> 2. Do not require diversity for incubation, but require it for
> graduation, and remove projects from incubation if they fail to attract
> a diverse community
>
> 3. Do not require diversity at incubation time, but at least judge the
> interest of other companies: are they signed up to join in the future ?
> Be ready to drop the project from incubation if that was a fake support
> and the project fails to attract a diverse community
>
> Personally I'm leaning towards (3) at the moment. Thoughts ?
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/1bb5d19e/attachment.html>