Open Stack

Steven Dake (stdake) wrote:
> On 7/31/16, 11:29 AM, "Doug Hellmann" <doug at doughellmann.com> wrote:
>> [...]
>> To be clear, I'm suggesting that projects with team:single-vendor be
>> given enough time to lose that tag. That does not require them to grow
>> diverse enough to get team:diverse-affiliation.
> 
> That makes sense and doesn't send the wrong message.  I wasn't trying to
> suggest that either; was just pointing out Kevin's numbers are more in
> line with diverse-affiliation than single vendor.  My personal thoughts
> are single vendor projects are ok in OpenStack if they are undertaking
> community-building activities to increase their diversity of contributors.

Basically my position on this is: OpenStack is about providing open
collaboration spaces so that multiple organizations and individuals can
collaborate (on a level playing ground) to solve a set of issues. It's
difficult to have a requirement of a project having a diversity of
affiliation before it can join, because of the chicken-and-egg issue
between visibility and affiliation-diversity. So we totally accept
single-vendor projects as official OpenStack projects.

But if a project is persistently single-vendor after some time and
nobody seems interested to join it, the technical value of that project
being "in" OpenStack rather than a separate project in the OpenStack
ecosystem of projects is limited. It's limited for OpenStack (why
provide resources to support a project that is obviously only beneficial
to one organization ?), and it's limited to the organization itself (why
go through the OpenStack-specific open processes when you could shortcut
it with internal tools and meetings ? why accept the oversight of the
Technical Committee ?).

So the idea is to find a way for projects who realize that they won't
attract a significant share of external contributions to move to an
externally-governed project. I'm not sure we can use a strict deadline
-- some projects might still be single-vendor after a year but without
structurally resisting contributions. But being able to trigger a review
after some time, to assess if we have reasons to think it will improve
in the future (or not), sounds like a good idea.

-- 
Thierry Carrez (ttx)