Open Stack

On 12/18/2013 10:37 AM, Steven Dake wrote:
> 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.

I think this is really good concrete feedback, and definitely puts me on
the #2/3 path.


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

Agreed.

One of the things I think we are missing with the incubation project is
checkpoints. We really should be reviewing incubated projects at the end
of every cycle (and maybe at milestone-2 as an interim) and give them
some feedback on how they are doing on integration requirements, or even
how they are doing keeping up with what's needed for incubation (and
de-incubate if required).

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/2eb2621d/attachment.pgp>