[openstack-dev] [tc] persistently single-vendor projects

Thierry Carrez thierry at openstack.org
Thu Aug 4 08:10:27 UTC 2016


Devdatta Kulkarni wrote:
> As current PTL of one of the projects that has the team:single-vendor tag,
> I have following thoughts/questions on this issue.

In preamble I'd like to reiterate that the proposal is not on the table
at this stage -- this is just a discussion to see whether it would be a
good thing or a bad thing.

> - Is the need for periodically deciding membership in the big tent primarily stemming
> from the question of managing resources (for the future design summits and cross-project work)?

No, it's not the primary reason. As I explained elsewhere in the thread,
it's more that (from an upstream open source project perspective)
OpenStack is not a useful vehicle for open source projects that are and
will always be driven by a single vendor. The value we provide (through
our governance, principles and infra systems) is in enabling open
collaboration between organizations. A project that will clearly always
stay single-vendor (for one reason or another) does not get or bring
extra technical value by being developed within "OpenStack" (i.e. under
the Technical Committee oversight).

> If so, have we thought about alternative solutions such, say, using the team:diverse-affiliation
> tag for making such decisions? For instance, we could say that a project will get
> space at the design summit only if it has the team:diverse-affiliation tag? That way, projects
> are incentivized to purse this tag/goal if they want to participate in the design summit.
> Also, adding/removing tag might be simpler than trying to get into big tent again (say, after a project
> has been removed and then gains diverse affiliation afterwards and wants to participate in the
> design summit, would they have to go through big tent application again?).

Actually this is being considered for the Project Teams Gathering
events: we may not provide space for single-vendor projects (since the
value for contributors from one single organization to travel to a
remote location to have a team meeting is limited). Final decision will
be taken based on space availability at the chosen venue.

> - Another issue with using the number of vendors as a metric 
> to decide membership in big tent is that it rules out any project which may be 
> independently started in the open (not by any specific vendor, but by a team of independent contributors),
> and which is following the 4 opens, to be a part of the big tent.

The main issue I now see with this idea is that you REALLY don't want to
flip-flop between in and out based on reaching 89% or 91% on an abstract
metric. Which is why I'd suggest 18 months at single-vendor should only
trigger a *review* by the TC of the affected project. That review would
assess if there is any significant chance that the project grows a
diverse contributor base in the future (and if there is, the project
should stay in).

I expect we'll see two cases in those reviews. On one hand, smallish
projects that struggle to attract contributors or grow diversity, but
are trying and have nothing structural in them discouraging
contributions from other organizations. Those should definitely stay in.
On the other hand, projects that are clearly part of the marketing
strategy of one particular vendor, and the project is not generally as
useful to the rest of the community, and I'd advocate that those should
not stay under TC governance as an official OpenStack project.

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list