[openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

Doug Hellmann doug at doughellmann.com
Tue Nov 29 18:24:46 UTC 2016


Excerpts from Anita Kuno's message of 2016-11-29 12:37:21 -0500:
> On 2016-11-29 11:27 AM, Jeremy Stanley wrote:
> > I think we also need to look harder at the reasons for driver-only
> > developer teams seeking official status. If it's because they want
> > to be part of the community and help collaborate with the rest of
> > us, then as long as they can do that consistent with our overall
> > goals and ideals I think that's great and we should welcome them as
> > one of us. If the reason is because they feel it raises the profile
> > of their products within the OpenStack ecosystem or conveys an
> > implication of better OpenStack support on their platforms, then we
> > should work harder as a community to dispel that notion (even if it
> > means we need to actively sabotage the "tent" as a marketing
> > platform) and find other places for companies to advertise the level
> > of OpenStack support their customers should expect.
> 
> I think Jeremy raises a very important point here. What is the 
> motivation on the part of the driver-only teams?
> 
> I personally assumed far too much collaborative intent when I got 
> involved with supporting the path to third party testing for drivers. My 
> eyes have since been opened. While there are a few driver maintainers 
> that are motivated to be collaborative and help others (thank you so 
> much) they are far from the norm.
> 
> I've taken some time away from keyboard to navel gaze a bit and been 
> quite enjoying it. I've been able to think about some of the material 
> offered to us during the leadership training in June, particularly 
> thinking about groups that are successful in creating an environment of 
> collaboration. I found that one of the most important aspects of groups 
> that do create and maintain a collaborate atmosphere for all concerned 
> is the ability to ensure that all concerned are motivated to create a 
> collaborative environment. Businesses offered as case studies in the 
> literature provided by Zingermans, create a reciprocally beneficial 
> collaborative environment through rigorous filtering during interview 
> and selection processes as well as a commitment to help people move 
> along should it be evident that they are not motivated by collaborative 
> intent. OpenStack can't apply the process but it can align with the 
> spirit of the intent, should OpenStack continue to want to create a 
> collaborative environment for all concerned.
> 
> Some may feel excluded and that is their choice, as long as there is 
> always a door way in for those that make the choice of having their 
> actions motivated by collaboration for the benefit of all concerned.
> 
> Thank you,
> Anita.
> 

If we start by assuming that contributors may end up getting more
value from seeming to be a part of the community than the community
will get from their participation, and that we have to guard against
that because it somehow diminishes us, it seems like we would be
rejecting the notion of having an open community in the first place.

Not every useful contribution is going to come from someone with
the time to participate 100%, or even 50%, upstream.  Not every
useful contribution is going to be code changes to the core components
of a project.

I know that our experience with third-party CI for some vendors has
been poor in the past. I don't believe the answer is to tell all
vendors to go away.

As long as we clearly communicate to users how drivers are tested,
and who owns failures, collaborating with vendors who only have the
resources (or interest) to contribute a driver shouldn't be considered
a burden. If they want more influence over the direction of a
project, they need to participate at a level to make it possible for
them to have that influence. In the mean time, I see no harm in making
it possible for them to participate at the level of commitment they're
ready to make.

Doug



More information about the OpenStack-dev mailing list