From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10041.outbound.protection.outlook.com [40.107.1.41]) by dpdk.org (Postfix) with ESMTP id 7335F2A5F for ; Mon, 31 Oct 2016 17:43:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=El0zQyyJhqGN1dWjH0EyhrRsmA7cx9lcEoCdNGU71oM=; b=O5k7NyvjDdOu1vHW8ziGgFgyr/BiNyDzK8S7nPcH7fxL8DzUt3IWGOPRJsyxwzzdwz/W1JJOC5pIfWRE2TpK8ypGM2LXZ2V1afRSUYBYe9XoTkusnJrZ8tOl9n/EMwjotjp4dzAMWs1QfkhObn9imijYpcnBbufSGPiBe7t6ouI= Received: from AM5PR0801MB2051.eurprd08.prod.outlook.com (10.168.158.141) by AM5PR0801MB2052.eurprd08.prod.outlook.com (10.168.158.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Mon, 31 Oct 2016 16:43:38 +0000 Received: from AM5PR0801MB2051.eurprd08.prod.outlook.com ([10.168.158.141]) by AM5PR0801MB2051.eurprd08.prod.outlook.com ([10.168.158.141]) with mapi id 15.01.0669.024; Mon, 31 Oct 2016 16:43:38 +0000 From: Matt Spencer To: Michael Dolan Thread-Topic: [dpdk-moving] description of technical governance Thread-Index: AQHSLsgejSOr3VBxk0mkwdhTbAlIkaC6h/qAgAMRp4CAAHQFjoAANhSAgAA7HYCABDamP4AADpWAgAACAhGAAAV8AIAAAS7j Date: Mon, 31 Oct 2016 16:43:38 +0000 Message-ID: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> <2677739.KbWyRmNgFH@xps13> <1580d802a08.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Matt.Spencer@arm.com; x-originating-ip: [25.160.228.132] x-ms-office365-filtering-correlation-id: 094ff57e-9e1c-4881-a4c9-08d401ad107a x-microsoft-exchange-diagnostics: 1; AM5PR0801MB2052; 7:WP1DcVPNOZ18UW7+T2LpAmyeOdFEAcZ3xduHvJG2HZBJdTUPN4Bmna5yeZPx0n70hm5RKEfURyIAcbret1u/nH2PZH22xl4ybgoL3SJv/BD58VlSBZ8OmVeqJbPxkFSyDRJvNHP82YD3ySufsUJIMGC4YFnjZ2RHF2SiGdgnEzjI3QbVs4aLxSSaANdabA38+qzFcq2Mvh4iY38mm96RFcJUoFKGcge0zzzx3e2iDkGvNMsJ47zmn3QE+kcKt6p/IXGJM30AQAiM96b1VyCotpEeazo0PCMBhS9cWx58ZPSoO2y5FEEMEhpA4DWIwy84AxjeiRIsRJOTLDI5ZLE7Hee7A+wuZ9PRFBHl0+4bZw0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(180628864354917)(100405760836317)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:AM5PR0801MB2052; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0801MB2052; x-forefront-prvs: 01128BA907 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(54014002)(377454003)(53754006)(377424004)(199003)(51914003)(189002)(24454002)(40434004)(7696004)(97736004)(33656002)(66066001)(110136003)(19625215002)(81156014)(7846002)(19627405001)(2906002)(8676002)(5890100001)(93886004)(81166006)(19617315012)(7736002)(4326007)(5660300001)(19580395003)(105586002)(106116001)(8936002)(9686002)(77096005)(68736007)(4001150100001)(3280700002)(87936001)(15975445007)(76576001)(19580405001)(3660700001)(122556002)(2950100002)(189998001)(6916009)(86362001)(11100500001)(5002640100001)(10400500002)(102836003)(3846002)(16236675004)(6116002)(74316002)(586003)(50986999)(92566002)(7906003)(2900100001)(106356001)(101416001)(54356999)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0801MB2052; H:AM5PR0801MB2051.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0801MB205178F05CF85D844D706D1295AE0AM5PR0801MB2051_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2016 16:43:38.1153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB2052 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:43:39 -0000 --_000_AM5PR0801MB205178F05CF85D844D706D1295AE0AM5PR0801MB2051_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael Thanks for the clarification. My initial mail on the subject was with a vi= ew to making the TSC more diverse. My first post had a breakdown of how th= e 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 organisatio= n, 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 w= as trying to propose ways in which we could fairly distribute technical own= ership between the stakeholders of the project whilst making the TSC more e= ffective. 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 refe= r to setting up a TSC in order to encourage/force company diversity of cont= ributors 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 TS= C does not make any code decisions. The TSC becomes a place for discussing = architecture, accepting new projects into FD.io or discussing future roadma= p ideas, but the TSC does not make contributions - that happens in the proj= ects/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 s= upport. So we're artificially creating a more diverse structure so 1 compan= y 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 P= TLs 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 pr= ojects typically default to the top level project Maintainers or some repre= sentation of Maintainers (e.g. an annual election) so that cross-project de= cisions 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 DP= DK but I've not analyzed the code contributions and where they're coming fr= om. 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 'buy= ing a vote', but if I look at the model for FD.io for example (https://fd.i= o/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 sect= ion 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 proje= ct 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 out = a few nuances to how we run projects to help with expectations and structur= al understanding. First, for technical governance, the project/sub-projects always make techn= ical decisions. There is no option to "buy a vote" - you "vote" with contri= butions, technical merit and becoming a committer/maintainer over time base= d 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 com= munity (e.g. elevating new Maintainers/Committers) and any technical polici= es / rules (e.g. tabs vs spacing, release timelines and milestones, etc). S= ome 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 contribut= ion community. It's generally most helpful when starting a Project based en= tirely on 1 company's codebase and it gives others a say to ensure it's neu= tral while new committers are ramping up/learning the codebase. Second, we do host projects that do not raise any funds at all. They're pro= jects we'll host for LF members if there's a community interested in it. Ho= wever, 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 d= omain so 1 participant in the community doesn't control everything. Please = understand the LF is a non-profit and we receive funds from various project= s 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 Go= verning Board that owns responsibility for how to spend the funding. The Go= verning Board does not make technical decisions or tell the technical proje= cts 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 s= etup 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 spe= nt, so we rely on the funders to make those decisions. Typically there's a single or multi-tier membership structure. If multi-tie= r, 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 low= er tier members). Typically the ratio is based on roughly what the contribu= tion of X is relative to the higher tier members. E.g. if there's a top tie= r "Premier" at $50k/year and a lower tier "General" and it has a blended av= erage of $5k/year, then there would be 1 General Member seat for ever 10 Ge= neral 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 wan= t 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. Ty= pically a "hook" is to have a logo or something available to show your comp= any 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 exampl= e 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 a= mount in membership fees. And for some communities like OVS, they really do= n't need any public community resources other than GitHub and a webpage - a= nd that's just fine for them. I apologize for the length, but hopefully this will be helpful in guiding d= iscussions about how LF Projects are structured and some of the rationale b= ehind 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 t= oday! One point I would raise, and it is one that Thomas picked up on a bit. I d= on't think we can have a pure meritocracy /and/ expect some of the membersh= ip to pay to support the project management. I am going to have a very har= d time explaining to my exec why we should be spending $$$ on DPDK when the= re is no clear benefit to membership. Comparisons have ben made to the OVS project, which is fine, but OVS does n= ot 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 hav= e 1 - a pure meritocracy - ie the governance does not change and I believe w= e 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 =E9crit : > 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 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. 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. --_000_AM5PR0801MB205178F05CF85D844D706D1295AE0AM5PR0801MB2051_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Michael


Thanks for the clarification.  My initial mail on the subject was w= ith a view to making the TSC more diverse.  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.  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  governance = 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.  = 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 <mdo= lan@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
 
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 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. S= o 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. 

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 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, o= ur projects typically default to the top level project Maintainers or some = representation of Maintainers (e.g. an annual election) so that cross-proje= ct decisions can be made. 

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 comi= ng 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  Sky= 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.  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 sectio= n 2.3.b 'designate one representative to serve as a member of the = TSC'.  When the TSC is used to vote on architectural issues/direct= ion 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: M= ichael 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
 
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 expectat= ions and structural understanding. 

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. 

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 mos= t 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.&nb= sp;

Second, we do host projects that do not raise any funds at all. They'r= e 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 reso= urces 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 take = funds from some other effort and apply them to DPDK - our auditors and memb= ers 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. <= /div>

Typically there's a single or multi-tier membership structure. If mult= i-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 th= e higher tier members. E.g. if there's a top tier "Premier" at $5= 0k/year and a lower tier "General" and it has a blended average o= f $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 infrastructure th= emselves, 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 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 community r= esources 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   Cell: +1.440.552.5322  Skype: 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.  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.&n= bsp; 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 ha= ve 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.  We ei= ther have

 1 - a pure meritocracy - ie the governance does not chan= ge 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@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
 


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

> 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<= 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 Intel provid= es
> 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 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 shoul= d
> 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 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. --_000_AM5PR0801MB205178F05CF85D844D706D1295AE0AM5PR0801MB2051_--