Open Stack

Doug Hellmann wrote:
> [...]
> 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.

My preference goes to this option.

I think it's important to continue to say that all OpenStack projects
are expected to be developed as a fair and open collaboration. This is
the reason why we are here. However, some teams work on implementing
drivers for those projects, using established plug-in points to enable
external software, proprietary solutions or hardware to work with
OpenStack. Those drivers are an integral part of the success of our
openly-developed projects, but by their very nature we can't enforce the
same level playing field over proprietary driver development. As a
community, we need those drivers for the success of our mission.

This option basically says that we welcome those driver teams as a part
of our community, while recognizing that they are a different animal. In
this specific and narrow case (second-order objects that implement a
pluggable extension point defined by an OpenStack project) we accept a
different set of team requirements (removing the level playing field
principle). Tracking those teams and their requirements separately
ensures that this deviation is not affecting the message for the main
projects.

An alternative would be the "soft white" option, but I think that if
those teams have different requirements and very limited scope, it's
simpler to list them separately rather than put them all in the same
file. It avoids diluting the "open collaboration" message we send to the
main projects.

I would also be fine with the the "soft black" option (which is
basically repeating the current situation).

Regards,

-- 
Thierry Carrez (ttx)