[dpdk-moving] description of technical governance

[Michael Dolan]

Ah, now I understand better what you were suggesting - thanks for that
context.

Typically we like to see a TSC with ideally 9-15 developers on it, ideally
no more than 3-5 from any one company. I say developers specifically to
avoid implying it's good to send someone with no knowledge of the codebase
as a TSC rep. That's one pitfall of an artificially diverse TSC - some
projects end up having to have a difficult conversation to remove TSC
members that are not technically capable.

Some Projects legislate in the Charter that no more than X people on the
TSC from any one company. There are exceptions some Projects make for
various good reasons at the time of formation, but I generally think of
those ranges are healthy. You can't make companies contribute technical
code and engineer time, so you're all benefitting from those putting a lot
of investment forward but at the same time trying to balance control. Each
community is different but I try to guide people to the least common
denominator basics they want to see, not legislate too much based on what
the conditions are today - because those conditions can change quickly as
projects evolve and the future will potentially bring technical
alternatives.

-- Mike



---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan
mdolan at linuxfoundation.org
---

On Mon, Oct 31, 2016 at 12:43 PM, Matt Spencer <Matt.Spencer at arm.com> wrote:

> Hi Michael
>
>
> Thanks for the clarification.  My initial mail on the subject was with a
> view to making the TSC more diverse.  My first post had a breakdown of how
> the TSC would look if we took a pure meritocracy view of the world today.
> In this model, almost 50% of the vote in the TSC resides with one
> organisation, I was looking for ways to try and break what I saw being a
> 'virtual veto' within the  governance of this project.
>
>
> Also, when I look at other projects such as OVS, there are only 16 members
> of the TSC, with DPDK as it stands today there would be about 56.  I am not
> sure that a leadership committee can work effectively at this size, so I
> was trying to propose ways in which we could fairly distribute technical
> ownership between the stakeholders of the project whilst making the TSC
> more effective.
>
>
> What does the LF view as being a healthy, diverse technical leadership?
>
>
> Regards
>
>
> Matt
> ------------------------------
> *From:* Michael Dolan <mdolan at linuxfoundation.org>
> *Sent:* 31 October 2016 16:33:52
>
> *To:* Matt Spencer
> *Cc:* Vincent Jardin; Thomas Monjalon; moving at dpdk.org
> *Subject:* Re: [dpdk-moving] description of technical governance
>
> Hi Matt, happy to. If you look at the third paragraph in my email I do
> refer to setting up a TSC in order to encourage/force company diversity of
> contributors in a project. FD.io was setup with one initial project called
> VPP. In that case, it was 100% Cisco developers/engineers working on it.
> The TSC does not make any code decisions. The TSC becomes a place for
> discussing architecture, accepting new projects into FD.io or discussing
> future roadmap ideas, but the TSC does not make contributions - that
> happens in the projects/sub-projects through developers and engineers
> making contributions. So, yes, some projects do have the option for a top
> tier member to appoint a participant onto the TSC - but that's most often
> to encourage diversity of companies contributing to the project. If we had
> setup FD.io with 1 project VPP and 100% Cisco maintainers... that's pretty
> tough for anyone else to support. So we're artificially creating a more
> diverse structure so 1 company couldn't just make all the decisions and
> direct the future of the Project. Further, the TSC sets the rules for
> becoming a committer/maintainer.
>
> However, you should also take into account that while a top tier member in
> FD.io can appoint a representative to the TSC, our TSC's also include the
> PTLs from the main projects.  I stated this in my long email, but to put it
> bluntly here - in my view, putting top tier members on a TSC is tool to use
> when you want to improve the corporate diversity of contribution. This is
> usually most beneficial in Projects that start with 1 company's codebase.
>
> Where we don't have a top tier membership appointing seats on a TSC, our
> projects typically default to the top level project Maintainers or some
> representation of Maintainers (e.g. an annual election) so that
> cross-project decisions can be made.
>
> Whether DPDK has a diverse enough contributor community is not something I
> can opine on - it does appear there are many companies involved in using
> DPDK but I've not analyzed the code contributions and where they're coming
> from. I'll leave that to you all who probably know far better than I do.
>
> Does this help Matt?
>
> -- Mike
>
> ---
> Mike Dolan
> VP of Strategic Programs
> The Linux Foundation
> Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan
> mdolan at linuxfoundation.org
> ---
>
> On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer <Matt.Spencer at arm.com>
> wrote:
>
>> Hi Michael
>>
>>
>> Can you give me some clarification then.  I understand that we are not
>> 'buying a vote', but if I look at the model for FD.io for example (
>> https://fd.io/sites/cpstandard/files/pages/files/exhibit_a_
>> -_fd.io_project_by-laws.pdf) , the Platinum level membership gets you a
>> seat on the Board, plus in section 2.3.b '*designate one representative
>> to serve as a member of the TSC*'.  When the TSC is used to vote on
>> architectural issues/direction of the project this really does look like
>> 'buying a vote' to me?
>>
>>
>> I hope you can understand why I am a little confused by your comments now?
>>
>>
>> Regards
>>
>>
>> Matt
>> ------------------------------
>> *From:* Michael Dolan <mdolan at linuxfoundation.org>
>> *Sent:* 31 October 2016 16:07:03
>> *To:* Matt Spencer
>> *Cc:* Vincent Jardin; Thomas Monjalon; moving at dpdk.org
>>
>> *Subject:* Re: [dpdk-moving] description of technical governance
>>
>> Hi everyone, it's great to see the discussion and thoughts. I'll point
>> out a few nuances to how we run projects to help with expectations and
>> structural understanding.
>>
>> First, for technical governance, the project/sub-projects always make
>> technical decisions. There is no option to "buy a vote" - you "vote" with
>> contributions, technical merit and becoming a committer/maintainer over
>> time based on prior contribution and technical leadership.
>>
>> Some Projects do setup a TSC ("Technical Steering Committee") that
>> oversees the Project structure (e.g. sub-projects, modules, etc), the
>> technical community (e.g. elevating new Maintainers/Committers) and any
>> technical policies / rules (e.g. tabs vs spacing, release timelines and
>> milestones, etc). Some Projects do give funders a role on the TSC, but that
>> varies widely and we try to avoid it if a community already has a diverse
>> technical contribution community. It's generally most helpful when starting
>> a Project based entirely on 1 company's codebase and it gives others a say
>> to ensure it's neutral while new committers are ramping up/learning the
>> codebase.
>>
>> Second, we do host projects that do not raise any funds at all. They're
>> projects we'll host for LF members if there's a community interested in it.
>> However, please understand up front that those projects receives no
>> resources from the LF. E.g. we don't run an OVS infrastructure for CI. The
>> LF simply becomes the neutral home for key community assets like the
>> trademark and domain so 1 participant in the community doesn't control
>> everything. Please understand the LF is a non-profit and we receive funds
>> from various projects but those funds are for those projects and we can't
>> take funds from some other effort and apply them to DPDK - our auditors and
>> members of the other projects we took funds from would not be happy to say
>> the least.
>>
>> Third, when there is funding involved in a project, we typically setup a
>> Governing Board that owns responsibility for how to spend the funding. The
>> Governing Board does not make technical decisions or tell the technical
>> projects what to do. The Governing Board is simply for those contributing
>> funds to have a say in how those funds are spent. Often some projects will
>> also setup the Governing Board to work on any marketing or legal topics as
>> well. Ultimately the LF will not be making decisions on how Project funds
>> are spent, so we rely on the funders to make those decisions.
>>
>> Typically there's a single or multi-tier membership structure. If
>> multi-tier, the top tier usually gets an automatic seat on the Governing
>> Board and a lower tier usually has a representation model (e.g. 1 seat per
>> every X lower tier members). Typically the ratio is based on roughly what
>> the contribution of X is relative to the higher tier members. E.g. if
>> there's a top tier "Premier" at $50k/year and a lower tier "General" and it
>> has a blended average of $5k/year, then there would be 1 General Member
>> seat for ever 10 General Members to roughly equal what the Premier Members
>> are paying.
>>
>> Note that this investment at any level does not "buy" technical
>> decisions. Members who contribute funds do so to make sure there is
>> something they want available for the community (e.g. if build/CI
>> infrastructure is desired). What they get is a leveraged investment - e.g.
>> they're not paying to build the entire infrastructure themselves, but
>> sharing the cost with others. Typically a "hook" is to have a logo or
>> something available to show your company is a "DPDK Project Member" or
>> "Sponsor" and then to have an opportunity to be on the Governing Board.
>>
>> Without the funding, the community resources would not exist or would
>> have to be provided by someone in the community unilaterally. Node.js for
>> example receives a lot of contributions of various resources (e.g. CDN) for
>> free from members of their ecosystem - which means they can raise a much
>> lower amount in membership fees. And for some communities like OVS, they
>> really don't need any public community resources other than GitHub and a
>> webpage - and that's just fine for them.
>>
>> I apologize for the length, but hopefully this will be helpful in guiding
>> discussions about how LF Projects are structured and some of the rationale
>> behind it.
>>
>> Thanks,
>>
>> Mike
>>
>>
>> ---
>> Mike Dolan
>> VP of Strategic Programs
>> The Linux Foundation
>> Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan
>> mdolan at linuxfoundation.org
>> ---
>>
>> On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <Matt.Spencer at arm.com>
>> wrote:
>>
>>> Thanks for the responses.  I'm really looking forward to the debate
>>> later today!
>>>
>>>
>>> One point I would raise, and it is one that Thomas picked up on a bit.
>>> I don't think we can have a pure meritocracy /and/ expect some of the
>>> membership to pay to support the project management.  I am going to have a
>>> very hard time explaining to my exec why we should be spending $$$ on DPDK
>>> when there is no clear benefit to membership.
>>>
>>>
>>> Comparisons have ben made to the OVS project, which is fine, but OVS
>>> does not have any membership costs (as far as I can see) and LF host this
>>> project for free.
>>>
>>>
>>> I don't think we can have both of these positions hold true.  We either
>>> have
>>>
>>>  1 - a pure meritocracy - ie the governance does not change and I
>>> believe we are in the same position as we are today
>>>
>>>  2 - Something a bit more like FD.io, with paid membership and paid
>>> access to a board/TSC
>>>
>>>
>>> Regards
>>>
>>>
>>> Matt
>>> ------------------------------
>>> *From:* Vincent Jardin <vincent.jardin at 6wind.com>
>>> *Sent:* 28 October 2016 23:54:13
>>> *To:* Thomas Monjalon; moving at dpdk.org; Matt Spencer
>>> *Subject:* Re: [dpdk-moving] description of technical governance
>>>
>>>
>>>
>>> Le 28 octobre 2016 9:22:43 PM Thomas Monjalon <thomas.monjalon at 6wind.com>
>>> a
>>> écrit :
>>>
>>> > 2016-10-28 16:52, Matt Spencer:
>>> >> 1 - we adopt the model as is - one TSC member per committer
>>> >> As this stands today, that would give us 56 TSC members,
>>> >> with almost half of them from one company
>>> >>
>>> >> 2 - we adopt the model as is - one TSC member per committer -
>>> >> to a maximum of 20% membership of the TSC
>>> >> This would ensure that no one company can 'own' the TSC -
>>> >> 56 committers, so max TSC membership from one company would be 11
>>> >>
>>> >> 3 - Maximum one member of TSC per committing company,
>>> >> plus one TSC assignee per paid member
>>> >> This would keep the TSC to a manageable level, give companies
>>> >> an incentive to join, but not require membership to be on the TSC
>>> >>
>>> >> 4 - Something else?
>>> >>
>>> >> My current thoughts are with 3 because we should end up with a
>>> >> representative cross section of the stakeholders of the project,
>>> >> whilst still incentivising membership of the foundation.
>>> >
>>> > Thanks for sharing your view.
>>> >
>>> > I'm an Open Source guy and I might lack some politician skills.
>>> > So please excuse me if I take the freedom to talk really frankly :)
>>> >
>>> > First of all, this email thread was dedicated to the technical
>>> governance.
>>> > And Matt is introducing money in this topic by talking about
>>> incentives.
>>> > I think it is a very interesting point that we must discuss.
>>> > From the beginning, everybody were saying that we must keep technical
>>> > governance and legal structure separate.
>>> > However one question has still no good answer: what is the incentive
>>> > for contributing money in the structure?
>>> > Is money going to biase the desired meritocratic system?
>>> >
>>> > My second comment is about having one company controlling the technical
>>> > governance.
>>> > I won't enter into the number details, and it's true that Intel
>>> provides
>>> > at least 50% of the contributions nowadays. Intel is also the biggest
>>> > contributor to Linux. No surprise.
>>> > I understand that a voice from ARM is requiring to mitigate this fact.
>>> > I would prefer ARM related companies working to achieve the same
>>> > level of commitment as Intel. They are increasing their contribution
>>> pace
>>> > but may never really compete with a giant like Intel.
>>> > That's why I second Matt to say that we must give a chance to every
>>> > vendors to influence the technical decisions.
>>> > Introducing a membership threshold looks to be a good idea.
>>> >
>>> > Having said that, I must state that the DPDK reality is a lot more
>>> > complex than a competition between vendors.
>>> > We are proving that a consensus based model works very well without
>>> > the need of a TSC or a board.
>>> > We can create such organization, but please keep in mind that it should
>>> > not be really helpful in the day-to-day job.
>>>
>>> +2
>>>
>>>  From contributions, meritocracy is applied.
>>>
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>> confidential and may also be privileged. If you are not the intended
>>> recipient, please notify the sender immediately and do not disclose the
>>> contents to any other person, use it for any purpose, or store or copy the
>>> information in any medium. Thank you.
>>>
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dpdk.org/ml/archives/moving/attachments/20161031/64a34505/attachment-0001.html>