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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
