Robert Collins wrote:
[...]
From an upstream perspective, I see us as being in the business of providing
open collaboration playing fields in order to build projects to reach the
OpenStack Mission. We collectively provide resources (infra, horizontal
teams, events...) in order to enable that open collaboration.
An important characteristic of these open collaboration grounds is that they
need to be a level playing field, where no specific organization is being
given an unfair advantage.
Would it change your meaning if I added 'by OpenStack community /
infrastructure' there? If not, then it seems to me that e.g.
Rackspace, Dreamhost, and the other organisations that have deployed
scaled clouds have a pretty big advantage. If it does change your
meaning, then what really do you mean?
Where would you add that ? Also I don't think organizations which have
deployed scaled clouds have an *unfair* advantage. Nothing in our
governance structure actively prevents another organization from doing
the same ?
I expect the teams that we bless as "official" project teams to operate in
that fair manner. Otherwise we end up blessing
what is essentially a trojan horse for a given organization, open-washing
their project in the process. Such a project can totally exist as an
unofficial project (and even be developed on OpenStack infrastructure) but I
don't think it should be given free space in our Design Summits or benefit
from "OpenStack community" branding.
We already have a mechanism - the undiverse tag - for calling out
projects that don't have diversity in their core. That seems to
overlap a lot here?
Yes, it is likely that official project teams that present such a unfair
playing field would stay "team:single-vendor" forever as a consequence.
This proposal is about not recognizing such teams as official in the
first place. The single-vendor tag is, IMHO, meant to encourage project
teams with a fair playing field to increase their diversity. It is not
meant to officially support projects that present unfair playing fields.
So if, in a given project team, developers from one specific organization
benefit from access to specific knowledge or hardware (think 3rd-party
testing blackboxes that decide if a patch goes in, or access to proprietary
hardware or software that the open source code primarily interfaces with),
then this project team should probably be rejected under the "open
community" rule. Projects with a lot of drivers (like Cinder) provide an
interesting grey area, but as long as all drivers are in and there is a
fully functional (and popular) open source implementation, I think no
specific organization would be considered as unfairly benefiting compared to
others.
So I read this paragraph as Its ok if many organisations have unfair
advantages, but its not ok if there is only one organisation with an
unfair advantage?
Consider a project with one open implementation and one organisation
funded proprietary driver. This would be a problem. But I don't
understand why it would be.
Project team requirements are just guidelines, which are interpreted by
humans. In the end, the TC members vote and use human judgment rather
than blind 'rules'. I just want (1) to state that a level playing field
is an essential part of what we call "open collaboration", and (2) to
have TC members *consider* whether the project presents a fair playing
field or not, as part of how they judge future project teams.
There is a grey area that requires human judgment here. In your example
above, if the open implementation was unusable open core bait to lure
people into using the one and only proprietary driver, it would be a
problem. If the open implementation was fully functional and nothing
prevented adding additional proprietary drivers, there would be no problem.
--
Thierry Carrez (ttx)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
