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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
