Steven Dake (stdake) wrote: > On 7/31/16, 11:29 AM, "Doug Hellmann" <d...@doughellmann.com> wrote: >> [...] >> To be clear, I'm suggesting that projects with team:single-vendor be >> given enough time to lose that tag. That does not require them to grow >> diverse enough to get team:diverse-affiliation. > > That makes sense and doesn't send the wrong message. I wasn't trying to > suggest that either; was just pointing out Kevin's numbers are more in > line with diverse-affiliation than single vendor. My personal thoughts > are single vendor projects are ok in OpenStack if they are undertaking > community-building activities to increase their diversity of contributors.
Basically my position on this is: OpenStack is about providing open collaboration spaces so that multiple organizations and individuals can collaborate (on a level playing ground) to solve a set of issues. It's difficult to have a requirement of a project having a diversity of affiliation before it can join, because of the chicken-and-egg issue between visibility and affiliation-diversity. So we totally accept single-vendor projects as official OpenStack projects. But if a project is persistently single-vendor after some time and nobody seems interested to join it, the technical value of that project being "in" OpenStack rather than a separate project in the OpenStack ecosystem of projects is limited. It's limited for OpenStack (why provide resources to support a project that is obviously only beneficial to one organization ?), and it's limited to the organization itself (why go through the OpenStack-specific open processes when you could shortcut it with internal tools and meetings ? why accept the oversight of the Technical Committee ?). So the idea is to find a way for projects who realize that they won't attract a significant share of external contributions to move to an externally-governed project. I'm not sure we can use a strict deadline -- some projects might still be single-vendor after a year but without structurally resisting contributions. But being able to trigger a review after some time, to assess if we have reasons to think it will improve in the future (or not), sounds like a good idea. -- 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