[openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers
doug at doughellmann.com
Mon Nov 28 18:33:56 UTC 2016
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  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 . I would very much like to find a way to say "yes, welcome
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) 
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) 
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) 
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) 
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) 
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) 
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. 
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
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.
 http://governance.openstack.org/reference/new-projects-requirements.html - requirements for new projects
 https://review.openstack.org/363709 - Add networking-cisco back into the Big Tent
 https://review.openstack.org/403834 - Proprietary driver dev is unlevel
 https://review.openstack.org/403836 - Driver development can be level
 https://review.openstack.org/403838 - Stop requiring a level playing field
 https://review.openstack.org/403839 - Level playing fields, except drivers
 https://review.openstack.org/403829 - establish a new "driver team" concept
 https://review.openstack.org/403830 - add resolution requiring teams to accept driver contributions
 https://review.openstack.org/403826 - add a resolution allowing teams based on vendor-specific drivers
More information about the OpenStack-dev