DPDK community structure changes
 help / color / mirror / Atom feed
From: "O'Driscoll, Tim" <tim.odriscoll@intel.com>
To: Jaswinder Singh <jaswinder.singh@nxp.com>,
	"moving@dpdk.org" <moving@dpdk.org>
Subject: Re: [dpdk-moving] description of technical governance
Date: Tue, 8 Nov 2016 09:37:16 +0000	[thread overview]
Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA6760E459@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <AM3PR04MB30627CFE330E56576E72C07FDA60@AM3PR04MB306.eurprd04.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 11142 bytes --]

Thanks Jaswinder. I was thinking along the same lines as this. I have a draft of a project charter for DPDK that covers some of these items. It’s almost ready and I plan to send it out later this morning. That should prompt further discussion on some of the topics that you’ve raised below.


From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Jaswinder Singh
Sent: Tuesday, November 8, 2016 8:12 AM
To: moving@dpdk.org
Subject: Re: [dpdk-moving] description of technical governance

Hello All,

DPDK started with a Intel architecture specific project and is now aspiring for a *truly open architecture*
Large part of it still remains specific or optimized for IA or similar architectures.

In terms of Technical Governance-Model, following is what we think can benefit DPDK to be a *true open architecture*
NXP prefers the budget based model to support Project management and Test lab.

There could be 2 co-existential bodies –

a.    Technical Board -

a.    Consists of Assignee engineers from Paid-members; Non-paid members on merit basis (could be maintainers too).

b.    Ensure technical conflicts resolution.

c.    A elected Maintainer to be the lead for Technical Board (TB lead)

b.    Governance Board -

a.    Consist of Paid members like any other body like Realtime in LF.

b.    Approves/Maintains the Roadmap

c.    Manages the Budget to execute on the Roadmap.

d.   TB lead to be part of the Governance Board.

e.    Also there can be some invitee members, who may not have voting-rights in case of Conflicts but would like to pay/part of steering committee.

We believe a single step of moving to LF (with established governance model) will be better than doing it in multiple steps.

Thanks & Regards,
Jaswinder Singh
NXP, Digital Networking Group.

From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Michael Dolan
Sent: Monday, October 31, 2016 9:37 PM
To: Matt Spencer <Matt.Spencer@arm.com<mailto:Matt.Spencer@arm.com>>
Cc: moving@dpdk.org<mailto:moving@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.



Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan

On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <Matt.Spencer@arm.com<mailto:Matt.Spencer@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



From: Vincent Jardin <vincent.jardin@6wind.com<mailto:vincent.jardin@6wind.com>>
Sent: 28 October 2016 23:54:13
To: Thomas Monjalon; moving@dpdk.org<mailto:moving@dpdk.org>; Matt Spencer
Subject: Re: [dpdk-moving] description of technical governance

Le 28 octobre 2016 9:22:43 PM Thomas Monjalon <thomas.monjalon@6wind.com<mailto:thomas.monjalon@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.


 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.

[-- Attachment #2: Type: text/html, Size: 28636 bytes --]

  reply	other threads:[~2016-11-08  9:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25  8:58 [dpdk-moving] [Topics] Francois Ozog
2016-10-25 11:27 ` O'Driscoll, Tim
2016-10-25 14:00   ` [dpdk-moving] description of technical governance Thomas Monjalon
2016-10-26 10:21     ` O'Driscoll, Tim
2016-10-28  9:13       ` O'Driscoll, Tim
2016-10-28 16:52         ` Matt Spencer
2016-10-28 19:22           ` Thomas Monjalon
2016-10-28 22:54             ` Vincent Jardin
2016-10-31 15:20               ` Matt Spencer
2016-10-31 16:07                 ` Michael Dolan
2016-10-31 16:18                   ` Matt Spencer
2016-10-31 16:33                     ` Michael Dolan
2016-10-31 16:43                       ` Matt Spencer
2016-10-31 16:52                         ` Michael Dolan
2016-10-31 16:56                           ` O'Driscoll, Tim
2016-10-31 16:58                             ` Michael Dolan
2016-10-31 18:31                             ` Jan Blunck
2016-10-31 19:41                               ` Vincent JARDIN
     [not found]                   ` <DB5PR04MB1605482F1C67F9B797EB9AE289A60@DB5PR04MB1605.eurprd04.prod.outlook.com>
2016-11-08  8:11                     ` Jaswinder Singh
2016-11-08  9:37                       ` O'Driscoll, Tim [this message]
2016-12-20 14:41       ` Thomas Monjalon
2016-10-25 14:55 ` [dpdk-moving] [Topics] Dave Neary
2016-10-26 12:47 ` Dave Neary
2016-10-26 15:00   ` Francois Ozog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26FA93C7ED1EAA44AB77D62FBE1D27BA6760E459@IRSMSX108.ger.corp.intel.com \
    --to=tim.odriscoll@intel.com \
    --cc=jaswinder.singh@nxp.com \
    --cc=moving@dpdk.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).