Open Stack

On Wed, Dec 18, 2013 at 10:58 AM, Sean Dague <sean at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/7c35d05b/attachment.html>