From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by dpdk.org (Postfix) with ESMTP id BCC7A68D9 for ; Mon, 31 Oct 2016 17:52:23 +0100 (CET) Received: by mail-vk0-f44.google.com with SMTP id w194so42747203vkw.2 for ; Mon, 31 Oct 2016 09:52:23 -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=fJEoXoBrMBLYSGcBWFCn4Wo2V2hqo5baBc7rlE8LcUA=; b=Vfv9MEnrN/TsSxhA3DipDxSYBVWQDQn2KJ1jHa1tM3puYfBG70OEJCfflqTZoRK04F Tvt1Wz/kdyU+bwGEGITqCjCBK4f73vqthqKk9gLasrBMK63+28MsDhTMbMA1QA/GsD41 TaOWb3CJGyNaGaY37OjRbF6vWoBdGhRSbgnis= 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=fJEoXoBrMBLYSGcBWFCn4Wo2V2hqo5baBc7rlE8LcUA=; b=HU/D1sHQUsO89/U9LlkMNzFuADy0dUqgtihPSZSAQ8IbWB04rOdwyQFUJl9RhcpuNC 6pG21I5sr8HLF9gIHLbjE54fM6jzxi07SdagxL7DxCnvcJHBTU4ryNM5tv+/30qkHzIi adVrpmsDMDd1nWyE6xp1ZbVIntY1v9Qiho75ErALfVWV06X3uQl/zQobHMpMWVUVIXRF lG6bVaFWgGrgh16RcMuSHz5AElHxraGklpeNXSQsQaCOKF+jT++dNQsvWDM6wN9qgm/p 4PZaq+Bbh2PQP+w33/q30oozZKfnXdjWcQHLa8nkoTDyhTVLNoPzqDYgMYToxgQbgVRC 846Q== X-Gm-Message-State: ABUngve1RIIlna/SThyaSroEyh8TMgRHr0FWramzOsAMzv1BeEXWpA+3BzMfPGB1Vzhv3J6OuIcIlxLSKol1D6i2 X-Received: by 10.31.161.65 with SMTP id k62mr24607417vke.12.1477932742918; Mon, 31 Oct 2016 09:52:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.33 with HTTP; Mon, 31 Oct 2016 09:52:22 -0700 (PDT) In-Reply-To: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> <2677739.KbWyRmNgFH@xps13> <1580d802a08.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> From: Michael Dolan Date: Mon, 31 Oct 2016 12:52:22 -0400 Message-ID: To: Matt Spencer Content-Type: multipart/alternative; boundary=001a1143f94c24e64d05402c0865 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:52:24 -0000 Archived-At: List-Archive: --001a1143f94c24e64d05402c0865 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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@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 no= w? >> >> >> 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 >> 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" wit= h >> 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 t= hat >> varies widely and we try to avoid it if a community already has a divers= e >> technical contribution community. It's generally most helpful when start= ing >> a Project based entirely on 1 company's codebase and it gives others a s= ay >> 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. T= he >> 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 fund= s >> 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 s= ay >> 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. T= he >> Governing Board does not make technical decisions or tell the technical >> projects what to do. The Governing Board is simply for those contributin= g >> funds to have a say in how those funds are spent. Often some projects wi= ll >> 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 fund= s >> 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 p= er >> every X lower tier members). Typically the ratio is based on roughly wha= t >> 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 Membe= rs >> 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 fo= r >> 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 guidin= g >> discussions about how LF Projects are structured and some of the rationa= le >> 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 hav= e a >>> very hard time explaining to my exec why we should be spending $$$ on D= PDK >>> 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 th= is >>> 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 >>> *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 technic= al >>> > 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 shou= ld >>> > 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 t= he >> 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. > --001a1143f94c24e64d05402c0865 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, now I understand better what you were suggesting - tha= nks for that context.=C2=A0

Typically we like to see a T= SC with ideally 9-15 developers on it, ideally no more than 3-5 from any on= e 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 on= e pitfall of an artificially diverse TSC - some projects end up having to h= ave a difficult conversation to remove TSC members that are not technically= capable.=C2=A0

Some Projects legislate in the Cha= rter 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 forma= tion, but I generally think of those ranges are healthy. You can't make= companies contribute technical code and engineer time, so you're all b= enefitting from those putting a lot of investment forward but at the same t= ime trying to balance control. Each community is different but I try to gui= de people to the least common denominator basics they want to see, not legi= slate too much based on what the conditions are today - because those condi= tions can change quickly as projects evolve and the future will potentially= bring technical alternatives.

-- Mike

=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:43 PM, Matt Spenc= er <Matt.Spencer@arm.com> wrote:

Hi Michael


Thanks for the clarification.=C2=A0 My initial mail on the subject was w= ith a view to making the TSC more diverse.=C2=A0 My first post had a breakd= own of how the TSC would look if we took a pure meritocracy view of the wor= ld today.=C2=A0 In this model, almost 50% of the vote in the TSC resides with one organisation, I was looking for ways to t= ry and break what I saw being a 'virtual veto' within the =C2=A0gov= ernance of this project.


Also, when I look at other projects such as OVS, there are only 16 membe= rs of 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 distribute technical ownership between the stakehold= ers of the project whilst making the TSC more effective.


What does the LF view as being a healthy, diverse technical leadership?<= /p>


Regards


Matt

From: = Michael 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 paragraph in m= y 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 pr= oject called VPP. In that case, it was 100% Cisco developers/engineers working on it. The TSC does not make a= ny code decisions. The TSC becomes a place for discussing architecture, acc= epting 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 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

However, you should also take into account that while a top tier membe= r in FD.io can appoint a representative to the TSC, our TSC's also incl= ude 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 want to improve = the corporate diversity of contribution. This is usually most beneficial in= Projects that start with 1 company's codebase.=C2=A0

Where we don't have a top tier membership appointing seats on a TS= C, our projects typically default to the top level project Maintainers or s= ome representation of Maintainers (e.g. an annual election) so that cross-p= roject decisions can be made.=C2=A0

Whether DPDK has a diverse enough contributor community is not somethi= ng I can opine on - it does appear there are many companies involved in usi= ng 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

Does this help Matt?

-- Mike

---
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
---


On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer <= span dir=3D"ltr"> <Matt.Spencer@= arm.com> wrote:

Hi Michael


Can 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 examp= le (https://fd.io/sites/cpstandard/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 TSC'.=C2=A0 When the TSC is used to vote on architectural issue= s/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 comme= nts now?


Regards


Matt

From: Michael 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 and thou= ghts. I'll point out a few nuances to how we run projects to help with = expectations and structural understanding.=C2=A0

First, for technical governance, the project/sub-projects always make = technical decisions. There is no option to "buy a vote" - you &qu= ot;vote" with contributions, technical merit and becoming a committer/= maintainer over time based on prior contribution and technical leadership.=C2=A0

Some Projects do setup a TSC ("Technical Steering Committee"= ) that oversees the Project structure (e.g. sub-projects, modules, etc), th= e technical community (e.g. elevating new Maintainers/Committers) and any t= echnical policies / rules (e.g. tabs vs spacing, release timelines and milestones, etc). Some Projects do give funders a ro= le 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 en= sure it's neutral while new committers are ramping up/learning the code= base.=C2=A0

Second, we do host projects that do not raise any funds at all. They&#= 39;re projects we'll host for LF members if there's a community int= erested in it. However, please understand up front that those projects rece= ives no resources from the LF. E.g. we don't run an OVS infrastructure for CI. The LF simply becomes the neutral home f= or key community assets like the trademark and domain so 1 participant in t= he 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 t= ake 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. T= he 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 fu= nds are spent. Often some projects will also setup the Governing Board to w= ork 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.=C2=A0<= /div>

Typically there's a single or multi-tier membership structure. If = multi-tier, the top tier usually gets an automatic seat on the Governing Bo= ard and a lower tier usually has a representation model (e.g. 1 seat per ev= ery X lower tier members). Typically the ratio is based on roughly what the contribution of X is relative to th= e higher tier members. E.g. if there's a top tier "Premier" a= t $50k/year and a lower tier "General" and it has a blended avera= ge 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" techni= cal decisions. Members who contribute funds do so to make sure there is som= ething they want available for the community (e.g. if build/CI infrastructu= re is desired). What they get is a leveraged investment - e.g. they're not paying to build the entire infrastructur= e 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.=C2=A0

Without the funding, the community resources would not exist or would = have to be provided by someone in the community unilaterally. Node.js for e= xample 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 f= or some communities like OVS, they really don't need any public communi= ty 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 guid= ing discussions about how LF Projects are structured and some of the ration= ale behind it.

Thanks,

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
---


On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <= span dir=3D"ltr"> <Matt.Spencer@= arm.com> wrote:

Thanks for the responses.=C2=A0 I'm really looking forward to the de= bate later today!


One 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 o= f 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 me= mbership.


Comparisons have ben made to the OVS project, which is fine, but OVS doe= s not have any membership costs (as far as I can see) and LF host this proj= ect for free.


I don't think we can have both of these positions hold true.=C2=A0 W= e either have

=C2=A01 - a=C2=A0pure=C2=A0meritocracy - ie the governance does not chan= ge 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= access to a board/TSC


Regards


Matt

From: Vincent 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


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 at= tachments are confidential and may also be privileged. If you are not the i= ntended 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. Th= ank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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 confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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.

--001a1143f94c24e64d05402c0865--