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.
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.
Regards
-steve
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
