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

Hayes, Graham graham.hayes at hpe.com
Tue Aug 2 15:54:55 UTC 2016


On 02/08/2016 16:48, Steven Dake (stdake) wrote:
> Responses inline:
>
> On 8/2/16, 8:13 AM, "Hayes, Graham" <graham.hayes at hpe.com> wrote:
>
>> On 02/08/2016 15:42, Flavio Percoco wrote:
>>> On 01/08/16 10:19 -0400, Sean Dague wrote:
>>>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
>>>>> 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"?
>>>>
>>>> I think at some level, it's not really that different. If we treat them
>>>> as different, everyone will always believe they did all the right
>>>> things, but got no results. 3 cycles should be plenty of time to drop
>>>> single entity contributions below 90%. That means prioritizing bugs /
>>>> patches from outside groups (to drop below 90% on code commits),
>>>> mentoring every outside member that provides feedback (to drop below
>>>> 90%
>>>> on reviews), shifting development resources towards mentoring / docs /
>>>> on ramp exercises for others in the community (to drop below 90% on
>>>> core
>>>> team).
>>>>
>>>> Digging out of a single vendor status is hard, and requires making that
>>>> your top priority. If teams aren't interested in putting that ahead of
>>>> development work, that's fine, but that doesn't make it a sustainable
>>>> OpenStack project.
>>>
>>>
>>> ++ to the above! I don't think they are that different either and we
>>> might not
>>> need to differentiate them after all.
>>>
>>> Flavio
>>>
>>
>> I do have one question - how are teams getting out of
>> "team:single-vendor" and towards "team:diverse-affiliation" ?
>>
>> We have tried to get more people involved with Designate using the ways
>> we know how - doing integrations with other projects, pushing designate
>> at conferences, helping DNS Server vendors to add drivers, adding
>> drivers for DNS Servers and service providers ourselves, adding
>> features - the lot.
>>
>> We have a lot of user interest (41% of users were interested in using
>> us), and are quite widely deployed for a non tc-approved-release
>> project (17% - 5% in production). We are actually the most deployed
>> non tc-approved-release project.
>>
>> We still have 81% of the reviews done by 2 companies, and 83% by 3
>> companies.
>
> By the objective criteria of team:single-vendor Designate isn't a single
> vendor project.  By the objective criteria of team:diverse-affiliation
> your not a diversely affiliated project either.  This is why I had
> suggested we need a third tag which accurately represents where Designate
> is in its community building journey.
>>
>> I know our project is not "cool", and DNS is probably one of the most
>> boring topics, but I honestly believe that it has a place in the
>> majority of OpenStack clouds - both public and private. We are a small
>> team of people dedicated to making Designate the best we can, but are
>> still one company deciding to drop OpenStack / DNS development from
>> joining the single-vendor party.
>
> Agree Designate is important to OpenStack.  But IMO it is not a single
> vendor project as defined by the criteria given the objective statistics
> you mentioned above.

My point is that we are close to being single vendor - it is a real
possibility over then next few months, if a big contributor was to
leave the project, which may happen.

The obvious solution to avoid this is to increase participation - which
is what we are struggling with.

>>
>> We are definitely interested in putting community development ahead of
>> development work - but what that actual work is seems to difficult to
>> nail down. I do feel sometimes that I am flailing in the dark trying to
>> improve this.
>
> Fantastic its a high-prioiirty goal.  Sad to hear your struggling but
> struggling is part of the activity.
>>
>> If projects could share how that got out of single-vendor or into
>> diverse-affiliation this could really help teams progress in the
>> community, and avoid being removed.
>
> You bring up a fantastic point here - and that is that teams need to share
> techniques for becoming multi-vendor and some day diversely affiliated.  I
> am a super busy atm, or I would volunteer to lead a cross-project effort
> with PTLs to coordinate community building from our shared knowledge pool
> of expert Open Source contributors in the wider OpenStack community.
>
> That said, I am passing the baton for Kolla PTL at the conclusion of
> Newton (assuming the leadership pipeline I've built for Kolla wants to run
> for Kolla PTL), and would be pleased to lead a cross project effort in
> Occata on moving from single-vendor to multi-vendor and beyond if there is
> enough PTL interest.  I take mentorship seriously and the various single
> vendor (and others) PTL's won't be disappointed in such an effort.
>
>>
>> Making grand statements about "work harder on community" without any
>> guidance about what we need to work on do not help the community.
>
> Agree - lets fix that.  Unfortunately it can't be fixed in an email thread
> - it requires a cross-project team based approach with atleast 6 months of
> activity.
>
> If PTLs can weigh in on this thread and commit to participation in such a
> cross-project subgroup, I'd be happy to lead it.

As would I.

> Regards
> -steve
>
>
>>
>> - Graham
>>
>>
>> __________________________________________________________________________
>> 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
>
>
> __________________________________________________________________________
> 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
>




More information about the OpenStack-dev mailing list