[openstack-dev] [tc] persistently single-vendor projects

Davanum Srinivas davanum at gmail.com
Mon Aug 1 13:58:50 UTC 2016


Thierry, Ben, Doug,

How can we distinguish between. "Project is doing the right thing, but
others are not joining" vs "Project is actively trying to keep people
out"?

Thanks,
Dims

On Mon, Aug 1, 2016 at 9:32 AM, Ben Swartzlander <ben at swartzlander.org> wrote:
> On 08/01/2016 03:39 AM, Thierry Carrez wrote:
>>
>> Steven Dake (stdake) wrote:
>>>
>>> On 7/31/16, 11:29 AM, "Doug Hellmann" <doug at 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 ?).
>
>
> Thierry I think you underestimate the value organizations perceive they get
> from projects being in the tent. Even if a project is single vendor, the
> halo effect of OpenStack and the access to free resources (the infra cloud,
> and more importantly the world-class infra TEAM) more than make up for any
> downsides associated with following established processes.
>
> I strongly doubt any organization would choose to remove a project from
> OpenStack for the reasons you mention. If the community doesn't want these
> kinds of projects in the big tent then the community probably needs to push
> them out.
>
> -Ben Swartzlander
>
>
>> 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.
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims



More information about the OpenStack-dev mailing list