[openstack-dev] Diversity as a requirement for incubation

Steven Dake sdake at redhat.com
Wed Dec 18 15:37:35 UTC 2013


On 12/18/2013 03:40 AM, Thierry Carrez 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

I apparently posted on the prior thread regarding Barbican my 
experiences with Heat incubation.  Option #2 is best.

Managers at companies are much more willing to invest R&D money into a 
project which is judged to atleast have a potential path to success.  I 
think this is because at many companies Managers are judged in their 
reviews and compensated based upon how effectively they manage their 
people resources to achieve their goals.

I spent countless hours on the phone in the early days of Heat trying to 
fulfill the unwritten "diversity" requirement that I forsaw being a 
potential problem for Heat to enter Incubation.  In the end, I was 
completely unsuccessful at convincing any company to invest any people 
in an R&D effort, even though Red Hat was all-in on OpenStack and the 
Heat eight person development team at Red Hat was all-in on Heat as 
well.  In the end, I think the various managers at different companies I 
spoke to just couldn't justify it in their organization if Heat failed.

This radically changed once we entered incubation.  Suddenly a bunch of 
people from many companies were committing patches, doing reviews.  Our 
IRC channel exploded with people.  The small core team was bombarded 
with questions.  This all happened because of the commitment the 
OpenStack TC made when we were incubated to indicate "yes Heat is in 
OpenStack's scope, and yes we plan to support the project from an 
infrastructure perspective to make it successful, and yes, we think the 
implementation meets our community quality guidelines."

I will grant that if this behavior doesn't happen after incubation, it 
should block integration, and maybe seen as an exit path out of incubation.

> 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 ?

In the early days of incubation requests, I got the distinct impression 
managers at companies believed that actually getting a project incubated 
in OpenStack was not possible, even though it was sparsely documented as 
an option.  Maybe things are different now that a few projects have 
actually run the gauntlet of incubation and proven that it can be done 
;)   (see ceilometer, heat as early examples).

But I can tell you one thing for certain, an actual incubation 
commitment from the OpenStack Technical Committee has a huge impact - it 
says "Yes we think this project has great potential for improving 
OpenStack's scope in a helpful useful way and we plan to support the 
program to make it happen".  Without that commitment, managers at 
companies have a harder time justifying R&D expenses.

That is why I am not a big fan of approach #3 - companies are unlikely 
to commit without a commitment from the TC first ;-) (see chicken/egg in 
your original argument ;)

We shouldn't be afraid of a project failing to graduate to Integrated.  
Even though it hasn't happened yet, it will undoubtedly happen at some 
point in the future.  We have a way for projects to leave incubation if 
they fail to become a strong emergent system, as described in option #2.

Regards
-steve





More information about the OpenStack-dev mailing list