On Wed, Dec 18, 2013 at 10:58 AM, Sean Dague <s...@dague.net> wrote: > 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). >
+1 Doug > > -Sean > > -- > Sean Dague > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev