<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 10:58 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 12/18/2013 10:37 AM, Steven Dake wrote:<br>
> On 12/18/2013 03:40 AM, Thierry Carrez wrote:<br>
>> 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>
> I apparently posted on the prior thread regarding Barbican my<br>
> experiences with Heat incubation. Option #2 is best.<br>
><br>
> Managers at companies are much more willing to invest R&D money into a<br>
> project which is judged to atleast have a potential path to success. I<br>
> think this is because at many companies Managers are judged in their<br>
> reviews and compensated based upon how effectively they manage their<br>
> people resources to achieve their goals.<br>
><br>
> I spent countless hours on the phone in the early days of Heat trying to<br>
> fulfill the unwritten "diversity" requirement that I forsaw being a<br>
> potential problem for Heat to enter Incubation. In the end, I was<br>
> completely unsuccessful at convincing any company to invest any people<br>
> in an R&D effort, even though Red Hat was all-in on OpenStack and the<br>
> Heat eight person development team at Red Hat was all-in on Heat as<br>
> well. In the end, I think the various managers at different companies I<br>
> spoke to just couldn't justify it in their organization if Heat failed.<br>
><br>
> This radically changed once we entered incubation. Suddenly a bunch of<br>
> people from many companies were committing patches, doing reviews. Our<br>
> IRC channel exploded with people. The small core team was bombarded<br>
> with questions. This all happened because of the commitment the<br>
> OpenStack TC made when we were incubated to indicate "yes Heat is in<br>
> OpenStack's scope, and yes we plan to support the project from an<br>
> infrastructure perspective to make it successful, and yes, we think the<br>
> implementation meets our community quality guidelines."<br>
><br>
> I will grant that if this behavior doesn't happen after incubation, it<br>
> should block integration, and maybe seen as an exit path out of incubation.<br>
<br>
</div></div>I think this is really good concrete feedback, and definitely puts me on<br>
the #2/3 path.<br>
<div class="im"><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>
><br>
> In the early days of incubation requests, I got the distinct impression<br>
> managers at companies believed that actually getting a project incubated<br>
> in OpenStack was not possible, even though it was sparsely documented as<br>
> an option. Maybe things are different now that a few projects have<br>
> actually run the gauntlet of incubation and proven that it can be done<br>
> ;) (see ceilometer, heat as early examples).<br>
><br>
> But I can tell you one thing for certain, an actual incubation<br>
> commitment from the OpenStack Technical Committee has a huge impact - it<br>
> says "Yes we think this project has great potential for improving<br>
> OpenStack's scope in a helpful useful way and we plan to support the<br>
> program to make it happen". Without that commitment, managers at<br>
> companies have a harder time justifying R&D expenses.<br>
><br>
> That is why I am not a big fan of approach #3 - companies are unlikely<br>
> to commit without a commitment from the TC first ;-) (see chicken/egg in<br>
> your original argument ;)<br>
><br>
> We shouldn't be afraid of a project failing to graduate to Integrated.<br>
> Even though it hasn't happened yet, it will undoubtedly happen at some<br>
> point in the future. We have a way for projects to leave incubation if<br>
> they fail to become a strong emergent system, as described in option #2.<br>
<br>
</div>Agreed.<br>
<br>
One of the things I think we are missing with the incubation project is<br>
checkpoints. We really should be reviewing incubated projects at the end<br>
of every cycle (and maybe at milestone-2 as an interim) and give them<br>
some feedback on how they are doing on integration requirements, or even<br>
how they are doing keeping up with what's needed for incubation (and<br>
de-incubate if required).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">+1</div><div class="gmail_default" style="font-size:small"><br>Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><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>
<br></blockquote></div><br></div></div>