From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0058.outbound.protection.outlook.com [104.47.0.58]) by dpdk.org (Postfix) with ESMTP id BFB4A5921 for ; Mon, 31 Oct 2016 17:18:15 +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=cQty3sAXa1PQc5HUZPnqeF3cZ90rAo2qIRXfF9Z9Si0=; b=SIwHm/wm+XtRq4z7MydnNEXpEjUNkC1zglMLk0sQPHtv9iCDBkDCGlBFy1f7anjcMxwcE/AhZNhzOJwSxlZ+7JNpT5cXs8M3suFYr3xRlj/6ZLq6T65fatEjQJlcIbBvZgat7OGUjbBH6Ggmh3h7JUnlv5wOca/6wo1+y8aqyI0= 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:18:14 +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:18:14 +0000 From: Matt Spencer To: Michael Dolan Thread-Topic: [dpdk-moving] description of technical governance Thread-Index: AQHSLsgejSOr3VBxk0mkwdhTbAlIkaC6h/qAgAMRp4CAAHQFjoAANhSAgAA7HYCABDamP4AADpWAgAACAhE= Date: Mon, 31 Oct 2016 16:18:14 +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: daf5820f-4e3c-4596-81ce-08d401a9845d x-microsoft-exchange-diagnostics: 1; AM5PR0801MB2052; 7:lxNT5BOB1iQRZVG5im/4QKfo/sMLSYYVcXv1yCtHp6yiwlEALFbCrpU9crDm5zCuaX3avi7GZU+yEWdiWuu9CsNxUUKhd0JIOQWNi1e8MW9NjvlZOrvqkWahVVSX9s9yyjtg30diF84pMaLZn2A+rYxNtHsbi2O7fKNe9baFJVf5j+ycOoqDzFvxXcDKQ6qgnX6DVzMLQwjhrkIrEAG3kjIwre97KbINidfbxh1XduJLgWXXS9q8Oj4GlduzuqrOGERpD56YpjoDL/xdJi/dk3p/4m/tSoxH08Rllfn6pQayXi7NCUTBG6GtM+lO+8Ucw3vcDMtNaUBA1ETLlt60OvkLNRFZ716oDwJ4dRglWSA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(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)(24454002)(40434004)(53754006)(54014002)(377454003)(189002)(51914003)(377424004)(199003)(86362001)(11100500001)(10400500002)(5002640100001)(102836003)(101416001)(54356999)(76176999)(92566002)(7906003)(74316002)(586003)(3846002)(16236675004)(6116002)(50986999)(2900100001)(106356001)(4001150100001)(81156014)(7846002)(8676002)(19627405001)(2906002)(4326007)(7736002)(5890100001)(93886004)(81166006)(19617315012)(66066001)(33656002)(7696004)(97736004)(19625215002)(110136003)(3280700002)(122556002)(6916009)(2950100002)(189998001)(3660700001)(87936001)(15975445007)(76576001)(19580405001)(8936002)(106116001)(105586002)(5660300001)(19580395003)(9686002)(77096005)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0801MB2052; H:AM5PR0801MB2051.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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_AM5PR0801MB20512CB8A2B0C1DD3AB23CEB95AE0AM5PR0801MB2051_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2016 16:18:14.7013 (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:18:16 -0000 --_000_AM5PR0801MB20512CB8A2B0C1DD3AB23CEB95AE0AM5PR0801MB2051_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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. --_000_AM5PR0801MB20512CB8A2B0C1DD3AB23CEB95AE0AM5PR0801MB2051_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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/fi= les/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: Michael Dolan <mdo= lan@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  Sky= pe: 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 attachments are confidential and may also be privileged. If you ar= e not the intended recipient, please notify the sender immediately and do n= ot disclose the contents to any other person, use it for any purpose, or store or copy the information in any me= dium. 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_AM5PR0801MB20512CB8A2B0C1DD3AB23CEB95AE0AM5PR0801MB2051_--