Open Stack

The OpenStack community wants to encourage collaboration by emphasizing
contributions to projects that abstract differences between
vendor-specific products, while still empowering vendors to integrate
their products with OpenStack through drivers that can be consumed
by the abstraction layers.

Some teams for projects that use drivers may not want to manage
some or all of the drivers that can be consumed by their project
because they have little insight into testing or debugging the code,
or do not have the resources needed to manage centrally a large
number of separate drivers. Vendors are of course free to produce
drivers to integrate with OpenStack completely outside of the
community, but because we value having the drivers as well as the
more general support of vendor companies, we want to encourage a
higher level of engagement by welcoming vendor-specific teams to
be a part of our community governance.

Our Requirements for New Projects list [0] includes a statement
about establishing a "level and open collaboration playing field"

  The project shall provide a level and open collaboration playing
  field for all contributors. The project shall not benefit a single
  vendor, or a single vendors product offerings; nor advantage
  contributors from a single vendor organization due to access to
  source code, hardware, resources or other proprietary technology
  available only to those contributors.

This requirement makes it difficult to support having teams focused
on producing a deliverable that primarily benefits a single vendor.
So, we have some tension between wanting to collaborate and have a
level playing field, while wanting to control the amount of driver
code that projects have to manage.

I'm raising this as an issue because it's not just a hypothetical
problem. The Cisco networking driver team, having been removed from
the Neutron stadium, is asking for status as a separate official
team [1]. I would very much like to find a way to say "yes, welcome
(back)!"

To that end, I've been working with fungi and ttx to identify all
of our options. We've come up with a "spectrum", which I will try
to summarize here but please read the associated governance patches
for the full details. (Please note that although we've split up the
work of writing the patches, each author may not necessarily support
all of the patches he has submitted.)

1. A resolution reaffirming the "level playing field" requirement,
   and acknowledging that it effectively precludes official status
   for teams which only develop drivers for proprietary systems
   (hard black) [2]

   This would have the immediate effect of denying the Cisco team's
   request, as well as precluding future requests from similar teams.

2. A resolution reaffirming the "level playing field" requirement,
   and acknowledging that it does not necessarily preclude official
   status for teams which only develop drivers for proprietary
   systems (soft black) [3]

   This would allow driver-specific teams for systems as long as
   those drivers can be developed without access to proprietary
   information. The TC would have to consider how this applies to
   each team's request as it is evaluated.

3. A resolution and policy change removing the "level playing field"
   requirement (hard white) [4]

   This would completely remove the problematic wording from the
   governance documents (eliminate the restriction on benefiting a
   single company and consider access to specific information for
   some contributors to not be a problem).

4. A resolution and policy change loosening the "level playing field"
   requirement (soft white) [5]

   This would add an exception to the existing wording in the
   governance documents to exempt teams working only on drivers.
   They would still be subject to all of our other policies, unless
   similar exceptions are included.

5. Consider driver teams to be a completely different animal, defined
   in drivers.yaml instead of projects.yaml (grey option) [6]

   This establishes drivers as second-order objects that are necessary
   for the success of the main projects, and for which requirements
   can be loosened. It would establish a new category of team without
   the level playing-field requirement and some of the other team
   requirements that seem not to apply to driver teams because they
   are essentially a public facet of a single vendor.

6. A resolution requiring projects that consume drivers to host all
   proposed drivers. (red option) [7]

   This would require teams with projects providing driver interfaces
   to also host, in some form, drivers from vendors that ask for
   hosting. The drivers would not need to be in the main project
   repo, but would need to be in a repository "owned" by the project
   team. Project teams would not be considered responsible for the
   quality of the resulting drivers.  Contributors to the driver
   repos would be considered part of the electorate for team PTL.

7. A resolution proposing to allow driver-teams, without specifying
   any implementation details. [8]

   This may go along with option 2, 3, 4, or 5. It may also be used
   as the basis for an alternative proposal if we have missed an
   approach.

We also need to consider while making the situation better that we
not have a huge proliferation of these new teams. For example, some
resources given to teams are finite (CI resources, space at PTGs
and Summits, foundation staff support, cross-project team support).
We also don't want to encourage driver authors to move their code
out of projects that are willing to host them just because they
can.  Therefore, it is likely that even if we do allow driver teams
in some form (options 2, 3, 4, and 5), they will have fewer rights
than teams building abstraction layers that use the drivers.

Again, these options are presented to give a more complete picture
and not because we necessarily support all of them (obviously, some
of them are clearly in conflict). I'll post my personal opinions
in a follow up message to avoid editorializing here.

Doug

[0] http://governance.openstack.org/reference/new-projects-requirements.html - requirements for new projects
[1] https://review.openstack.org/363709 - Add networking-cisco back into the Big Tent
[2] https://review.openstack.org/403834 - Proprietary driver dev is unlevel
[3] https://review.openstack.org/403836 - Driver development can be level
[4] https://review.openstack.org/403838 - Stop requiring a level playing field
[5] https://review.openstack.org/403839 - Level playing fields, except drivers
[6] https://review.openstack.org/403829 - establish a new "driver team" concept
[7] https://review.openstack.org/403830 - add resolution requiring teams to accept driver contributions
[8] https://review.openstack.org/403826 - add a resolution allowing teams based on vendor-specific drivers