Open Stack

> -----Original Message-----
> From: Sylvain Bauza [mailto:sylvain.bauza at bull.net]
> Sent: Wednesday, December 18, 2013 5:04 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Diversity as a requirement for incubation
> 
> Le 18/12/2013 11:40, Thierry Carrez a écrit :
> > 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
> >
> > 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 ?
> 
> I would vote for (1). FWIW, incubated projects are robust enough to fail
from
> a resource perspective.
> That definitely goes to what an incubated project is : to me, incubated
> projects *will* be integrated, but they currently aren't due to some
> *technical* (code compliancy, unittesting, frameworks, integration with
> other projects) concerns.

I would go the entirely opposite direction. It is difficult to get community
support for unrecognized projects, especially when that support is usually
in the form of FTEs from interested companies. Without some assurance that
the project will make it into OpenStack, it is significantly more difficult
to get companies to assign resources. Coming up with another status doesn't
seem to solve that problem unless that status is 'this will be in OpenStack
soon, start collaborating' which, to me, is what incubation is designed to
do. If the new status requires no investment from OpenStack, then it doesn't
signal any strong commitment, making it less clear that other vendors should
support the effort.

I would say that fixing some technical issues pre-incubation seems fine, but
expecting every project to have a diverse (as in multi-vendor) team before
the project has achieved any type of status is difficult. Also, any general
technical requirements should be documented beforehand. For Barbican, there
seems to be a lot of goalpost moving in that people just say what they want
and there is very little way for us to know what those requirements will be.


Additionally, measuring diversity of a project is also difficult. The
current measure being used is commit percentage, which is terrible. If a
project bakes for a while with a core set of developers, it will take a long
time for new contributors to make a dent in the percentages. It also
incentives bad behavior, e.g. wrapping up lots of small commits into one big
one, etc. We need more inclusive measures, maybe including intent to deploy,
etc. 

Barbican has been open since its inception. It has never been closed or
limited in any way. However, we didn't really start getting interest until
we reached our MVP. We have interest now, but even though people have
started contributing, it will take a while to chip away at the commit
percentages. 

For me, I would be fine with #2 or #3 (they seem very similar), but I don't
think #1 is realistic. Keep in mind that many of the current OpenStack
programs & projects were incubated without diverse communities. This doesn't
seem to have caused outsized headaches.


> If we assess that incubated projects could not part of Openstack one day
or
> so, that won't help community adoption and/or resources dedication.

If something gets kicked out of incubation, it is explicitly because it
didn't garner any additional community support. By being in incubation, the
project becomes the owner of a particular set of features. If no one joins,
it's either because the no one is interested in that feature set, the
project's community is not receptive or the project already meets the needs
of the user and they don't need to contribute devs. I see this as happening
very rarely, but only if we get better measures for diversity.


Jarret
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6087 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/7496b16a/attachment.bin>