From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com [209.85.217.182]) by dpdk.org (Postfix) with ESMTP id EF6822BB5 for ; Mon, 31 Oct 2016 17:58:39 +0100 (CET) Received: by mail-ua0-f182.google.com with SMTP id b35so37126527uaa.3 for ; Mon, 31 Oct 2016 09:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JAGU8iLdmkRaceqP/AYiGxxPxeO/sI1wO2gBO4uawek=; b=DdG4cSZ7aOXBATc0JPT99bQgBuRPsZH8/Rw2+X4qjF+LyNOGJNdPwMAkBG4NHw3CRR 8e7q7jzkTEARnNFIlpPYdfojsEUviP9HsIiIn8qLpfvdxnHzMlbAykmI1h/g0P+ad3Jq IQckP+tYqMMgoVkwygVGqZKjDZ0Orm5LOzD8M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JAGU8iLdmkRaceqP/AYiGxxPxeO/sI1wO2gBO4uawek=; b=iwm8al0Nfog8oZPhvzxtDjsgTjXBq6Hif2WMk5n33D9WdjbBwUpwfFceckOC0aU3WA ItwaM3cci7WbUw0KKA5mW9by9sKpBQiy2sNByL1n4mIdhfNbwpOtBqxQw+/KiXi5x17n HNR+PLPaGlOPets4oJ1KWg3zXZVsbVVAsPsyWm30loA8Qa0JLsCa3LFTnycOmW2XJuBE xjAypQywf0ykbZvv6MoRn9Wr64HpnZVBIKCpXxf+vMFzK3q6OZZswe309lfWCG+37eMU Hv2s5D0oaN/VTs7P7WfFtL8wAdVObZ+vTBlJ4DyDw7yJZlR0RuCqyX8M+7k/iJFm5NzF zESA== X-Gm-Message-State: ABUngvd33Mx8MPE3y+JuuECnt1YrFvv51AuS23Dr82Efi9y1eaOJk9EDvfzPdf9oPXS1oYbH9EjzTsdxgEuybTWq X-Received: by 10.159.49.27 with SMTP id m27mr3250601uab.178.1477933119177; Mon, 31 Oct 2016 09:58:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.33 with HTTP; Mon, 31 Oct 2016 09:58:38 -0700 (PDT) In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA6760A4D3@IRSMSX108.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> <2677739.KbWyRmNgFH@xps13> <1580d802a08.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA6760A4D3@IRSMSX108.ger.corp.intel.com> From: Michael Dolan Date: Mon, 31 Oct 2016 12:58:38 -0400 Message-ID: To: "O'Driscoll, Tim" Content-Type: multipart/alternative; boundary=f403045ddf7492197805402c1e33 Cc: "moving@dpdk.org" Subject: Re: [dpdk-moving] description of technical governance X-BeenThere: moving@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK community structure changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:58:40 -0000 --f403045ddf7492197805402c1e33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That makes a lot of sense Tim. I didn't realize (or forgot along the way) that DPDK had this already. --- Mike Dolan VP of Strategic Programs The Linux Foundation Office: +1.330.460.3250 Cell: +1.440.552.5322 Skype: michaelkdolan mdolan@linuxfoundation.org --- On Mon, Oct 31, 2016 at 12:56 PM, O'Driscoll, Tim wrote: > We do have a Technical Board (effectively a TSC with a different name) fo= r > DPDK in place already (see http://dpdk.org/dev#board). We deliberately > populated this board based on the most significant contributors to the > project, and made sure that it was balanced so that no single company had= a > majority. Current composition is 2 members from Intel, 2 from 6WIND, 1 fr= om > Cavium, 1 from Red Hat and 1 from Microsoft. > > > > My proposal would be that we keep this board in place rather than create = a > new TSC. I do think we need to more clearly define the scope of the board > and how people are added to/removed from it, but I don=E2=80=99t see a re= ason to > change or replace it. > > > > Tim > > > > *From:* moving [mailto:moving-bounces@dpdk.org] *On Behalf Of *Michael > Dolan > *Sent:* Monday, October 31, 2016 4:52 PM > *To:* Matt Spencer > *Cc:* moving@dpdk.org > > *Subject:* Re: [dpdk-moving] description of technical governance > > > > 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, ideall= y > 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 codebas= e > 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 lo= t > of investment forward but at the same time trying to balance control. Eac= h > 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@linuxfoundation.org > --- > > > > On Mon, Oct 31, 2016 at 12:43 PM, Matt Spencer > 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 ho= w > 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 member= s > of the TSC, with DPDK as it stands today there would be about 56. I am n= ot > 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 > *Sent:* 31 October 2016 16:33:52 > > > *To:* Matt Spencer > *Cc:* Vincent Jardin; Thomas Monjalon; moving@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 o= f > contributors in a project. FD.io was setup with one initial project calle= d > 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 ha= d > setup FD.io with 1 project VPP and 100% Cisco maintainers... that's prett= y > 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 i= n > 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 u= se > 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 comin= g > 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@linuxfoundation.org > --- > > > > On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer > 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 > *Sent:* 31 October 2016 16:07:03 > *To:* Matt Spencer > *Cc:* Vincent Jardin; Thomas Monjalon; 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 ou= t > 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 th= at > varies widely and we try to avoid it if a community already has a diverse > technical contribution community. It's generally most helpful when starti= ng > a Project based entirely on 1 company's codebase and it gives others a sa= y > 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 i= t. > 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. Th= e > 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 a= nd > members of the other projects we took funds from would not be happy to sa= y > 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. Th= e > 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 wil= l > also setup the Governing Board to work on any marketing or legal topics a= s > 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 pe= r > 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 Member= s > 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 payi= ng > to build the entire infrastructure themselves, but sharing the cost with > others. Typically a "hook" is to have a logo or something available to sh= ow > 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 hav= e > to be provided by someone in the community unilaterally. Node.js for > example receives a lot of contributions of various resources (e.g. CDN) f= or > 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 rational= e > 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@linuxfoundation.org > --- > > > > On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer > 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 DPD= K > 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 acces= s > to a board/TSC > > > > Regards > > > > Matt > ------------------------------ > > *From:* Vincent Jardin > *Sent:* 28 October 2016 23:54:13 > *To:* Thomas Monjalon; moving@dpdk.org; Matt Spencer > *Subject:* Re: [dpdk-moving] description of technical governance > > > > > > > Le 28 octobre 2016 9:22:43 PM Thomas Monjalon > a > =C3=A9crit : > > > 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 provide= s > > 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 pa= ce > > 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 th= e > 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 th= e > 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 th= e > information in any medium. Thank you. > > > --f403045ddf7492197805402c1e33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That makes a lot of sense Tim. I didn't realize (or fo= rgot along the way) that DPDK had this already.=C2=A0

---
Mike Dolan
VP of Strategic Programs
The Li= nux Foundation
Office: +1.330.460.3250 =C2=A0=C2=A0Cell: +1.440.552.5322= =C2=A0Skype: michaelkdolan
mdolan@linuxfoundation.org
---

<= /div>

On Mon, Oct 31, 2016 at 12:56 PM, O'Dris= coll, Tim <tim.odriscoll@intel.com> wrote:

We do have a Technical Board (effecti= vely a TSC with a different name) for DPDK in place already (see http://dpdk.org/dev= #board). We deliberately populated this board based on the most signifi= cant contributors to the project, and made sure that it was balanced so tha= t no single company had a majority. Current composition is 2 members from Intel, 2 from 6WIND, 1 from Cavium, 1 from Red Hat and 1= from Microsoft.

=C2=A0

My proposal would be that we keep thi= s board in place rather than create a new TSC. I do think we need to more c= learly define the scope of the board and how people are added to/removed from it, but I don=E2=80=99t see a reason to change o= r replace it.



Tim

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Michael Dolan
Sent: Monday, October 31, 2016 4:52 PM
To: Matt Spencer <Matt.Spencer@arm.com>
Cc: moving@dpdk= .org


Subject: Re: [dpdk-moving] description of technical governance

=C2=A0

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

=C2=A0

Typically we like to see a TSC with ideally 9-15 dev= elopers on it, ideally no more than 3-5 from any one company. I say develop= ers specifically to avoid implying it's good to send someone with no kn= owledge 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 n= ot technically capable.=C2=A0

=C2=A0

Some Projects legislate in the Charter that no more = than X people on the TSC from any one company. There are exceptions some Pr= ojects make for various good reasons at the time of formation, but I genera= lly 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 forwar= d but at the same time trying to balance control. Each community is differe= nt but I try to guide people to the least common denominator basics they want to see, not legislate too much based o= n what the conditions are today - because those conditions can change quick= ly as projects evolve and the future will potentially bring technical alter= natives.

=C2=A0

-- Mike

=C2=A0

=C2=A0


---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250 =C2=A0=C2=A0Cell: +1.440.552.5322 =C2=A0Sky= pe: michaelkdolan
mdolan@linu= xfoundation.org
---

=C2=A0

On Mon, Oct 31, 2016 at 12:43 PM, Matt Spencer <<= a href=3D"mailto:Matt.Spencer@arm.com" target=3D"_blank">Matt.Spencer@arm.c= om> wrote:

H= i Michael

<= u>=C2=A0

T= hanks for the clarification.=C2=A0 My initial mail on the subject was with = a view to making the TSC more diverse.=C2=A0 My first post had a breakdown = of how the TSC would look if we took a pure meritocracy view of the world today.=C2=A0 In this model, almost 50% of the vote in th= e TSC resides with one organisation, I was looking for ways to try and brea= k what I saw being a 'virtual veto' within the =C2=A0governance of = this project.

<= u>=C2=A0

A= lso, when I look at other projects such as OVS, there are only 16 members o= f the TSC, with DPDK as it stands today there would be about 56.=C2=A0 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 dis= tribute technical ownership between the stakeholders of the project whilst = making the TSC more effective.

<= u>=C2=A0

W= hat does the LF view as being a healthy, diverse technical leadership?

<= u>=C2=A0

R= egards

<= u>=C2=A0

M= att

From: Michae= l Dolan <mdolan@linuxfoundation.org>
Sent: 31 October 2016 16:33:52


To: Matt Spencer
Cc: Vincent Jardin; Thomas Monjalon; moving@dpdk.org
Subject: Re: [dpdk-moving] description of technical governance

=C2=A0

Hi Matt, happy to. If you look at the third paragrap= h in my email I do refer to setting up a TSC in order to encourage/force co= mpany diversity of contributors in a project. FD.io was setup with one init= ial project called VPP. In that case, it was 100% Cisco developers/engineers working on it. The TSC does not mak= e any code decisions. The TSC becomes a place for discussing architecture, = accepting new projects into FD.io or discussing future roadmap ideas, but t= he TSC does not make contributions - that happens in the projects/sub-projects through developers and enginee= rs making contributions. So, yes, some projects do have the option for a to= p tier member to appoint a participant onto the TSC - but that's most o= ften 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 suppor= t. 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 beco= ming a committer/maintainer.=C2=A0

=C2=A0

However, you should also take into account that whil= e a top tier member in FD.io can appoint a representative to the TSC, our T= SC's also include the PTLs from the main projects.=C2=A0 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 wa= nt to improve the corporate diversity of contribution. This is usually most= beneficial in Projects that start with 1 company's codebase.=C2=A0<= /u>

=C2=A0

Where we don't have a top tier membership appoin= ting seats on a TSC, our projects typically default to the top level projec= t Maintainers or some representation of Maintainers (e.g. an annual electio= n) so that cross-project decisions can be made.=C2=A0

=C2=A0

Whether DPDK has a diverse enough contributor commun= ity is not something I can opine on - it does appear there are many compani= es 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.=C2=A0

=C2=A0

Does this help Matt?

=C2=A0

-- Mike


---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250= =C2=A0=C2=A0Cell: +1.440.552.5322 =C2= =A0Skype: michaelkdolan
mdolan@linu= xfoundation.org
---

=C2=A0

On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer <<= a href=3D"mailto:Matt.Spencer@arm.com" target=3D"_blank">Matt.Spencer@arm.c= om> wrote:

H= i Michael

<= u>=C2=A0

C= an you give me some clarification then.=C2=A0 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/cpstanda= rd/files/pages/files/exhibit_a_-_fd.io_project_by-laws.pdf)= =C2=A0, the Platinum level membership gets you a seat on the Board, plus in sectio= n 2.3.b 'designate one representative to serve as a member of the TS= C'.=C2=A0 When the TSC is used to vote on architectural issues/dire= ction of the project this really does look like 'buying a vote' to me?

<= u>=C2=A0

I= hope you can understand why I am a little confused by your comments now?

<= u>=C2=A0

R= egards

<= u>=C2=A0

M= att

From: Michae= l Dolan <mdolan@linuxfoundation.org>
Sent: 31 October 2016 16:07:03
To: Matt Spencer
Cc: Vincent Jardin; Thomas Monjalon; moving@dpdk.org


Subject: Re: [dpdk-moving] description of technical governance

=C2=A0

Hi everyone, it's great to see the discussion an= d thoughts. I'll point out a few nuances to how we run projects to help= with expectations and structural understanding.=C2=A0

=C2=A0

First, for technical governance, the project/sub-pro= jects always make technical decisions. There is no option to "buy a vo= te" - you "vote" with contributions, technical merit and bec= oming a committer/maintainer over time based on prior contribution and technical leadership.=C2=A0

=C2=A0

Some Projects do setup a TSC ("Technical Steeri= ng Committee") that oversees the Project structure (e.g. sub-projects,= modules, etc), the technical community (e.g. elevating new Maintainers/Com= mitters) and any technical policies / rules (e.g. tabs vs spacing, release timelines and milestones, etc). Some Projec= ts 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 commun= ity. 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 ramp= ing up/learning the codebase.=C2=A0

=C2=A0

Second, we do host projects that do not raise any fu= nds 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 t= hose 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 under= stand 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 au= ditors and members of the other projects we took funds from would not be ha= ppy to say the least.

=C2=A0

Third, when there is funding involved in a project, = we typically setup a Governing Board that owns responsibility for how to sp= end the funding. The Governing Board does not make technical decisions or t= ell the technical projects what to do. The Governing Board is simply for those contributing funds to have a s= ay in how those funds are spent. Often some projects will also setup the Go= verning 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 de= cisions.=C2=A0

=C2=A0

Typically there's a single or multi-tier members= hip structure. If multi-tier, the top tier usually gets an automatic seat o= n 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 rela= tive to the higher tier members. E.g. if there's a top tier "Premi= er" at $50k/year and a lower tier "General" and it has a ble= nded 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.

=C2=A0

Note that this investment at any level does not &quo= t;buy" technical decisions. Members who contribute funds do so to make= sure there is something they want available for the community (e.g. if bui= ld/CI infrastructure is desired). What they get is a leveraged investment - e.g. they're not paying to build the e= ntire infrastructure themselves, but sharing the cost with others. Typicall= y 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.=C2=A0=

=C2=A0

Without the funding, the community resources would n= ot exist or would have to be provided by someone in the community unilatera= lly. Node.js for example receives a lot of contributions of various resourc= es (e.g. CDN) for free from members of their ecosystem - which means they can raise a much lower amount in mem= bership fees. And for some communities like OVS, they really don't need= any public community resources other than GitHub and a webpage - and that&= #39;s just fine for them.

=C2=A0

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.

=C2=A0

Thanks,

=C2=A0

Mike

=C2=A0


---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250= =C2=A0=C2=A0Cell: +1.440.552.5322 =C2= =A0Skype: michaelkdolan
mdolan@linu= xfoundation.org
---

=C2=A0

On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <<= a href=3D"mailto:Matt.Spencer@arm.com" target=3D"_blank">Matt.Spencer@arm.c= om> wrote:

T= hanks for the responses.=C2=A0 I'm really looking forward to the debate= later today!

<= u>=C2=A0

O= ne point I would raise, and it is one that Thomas picked up on a bit.=C2=A0= I don't think we can have a pure meritocracy /and/ expect some of the = membership to pay to support the project management.=C2=A0 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.<= u>

<= u>=C2=A0

C= omparisons have ben made to the OVS project, which is fine, but OVS does no= t have any membership costs (as far as I can see) and LF host this project = for free.

<= u>=C2=A0

I= don't think we can have both of these positions hold true.=C2=A0 We ei= ther have

= =C2=A01 - a=C2=A0pure=C2=A0meritocracy - ie the governance does not change = and I believe we are in the same position as we are today

= =C2=A02 - Something a bit more like FD.io, with paid membership and paid ac= cess to a board/TSC

<= u>=C2=A0

R= egards

<= u>=C2=A0

M= att

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

=C2=A0

=C2=A0


Le 28 octobre 2016 9:22:43 PM Thomas Monjalon <thomas.monjalon@6wind.com> a
=C3=A9crit :

> 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 -<= br> >> 56 committers, so max TSC membership from one company would be 11<= br> >>
>> 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<= br> >>
>> 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 governa= nce.
> And Matt is introducing money in this topic by talking about incentive= s.
> I think it is a very interesting point that we must discuss.
> From the beginning, everybody were saying that we must keep technical<= br> > 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 technica= l
> governance.
> I won't enter into the number details, and it's true that Inte= l provides
> at least 50% of the contributions nowadays. Intel is also the biggest<= br> > 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 p= ace
> 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 ever= y
> 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 shoul= d
> not be really helpful in the day-to-day job.

+2

=C2=A0From 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 th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

=C2=A0

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

=C2=A0

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

=C2=A0


--f403045ddf7492197805402c1e33--