From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <mdolan@linuxfoundation.org> 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 <moving@dpdk.org>; Mon, 31 Oct 2016 17:52:23 +0100 (CET) Received: by mail-vk0-f44.google.com with SMTP id w194so42747203vkw.2 for <moving@dpdk.org>; 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: <AM5PR0801MB205178F05CF85D844D706D1295AE0@AM5PR0801MB2051.eurprd08.prod.outlook.com> References: <CAHFG_=UjcFHHWPwr-k64g7SgoSoT9vkEEuO6d0hzcXDiK8ouOA@mail.gmail.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> <AM5PR0801MB20515A4AA7B1B7CE2A9C9F0395AD0@AM5PR0801MB2051.eurprd08.prod.outlook.com> <2677739.KbWyRmNgFH@xps13> <1580d802a08.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> <AM5PR0801MB20517D17BFC3DDB2D9E1132A95AE0@AM5PR0801MB2051.eurprd08.prod.outlook.com> <CAFV=PSErbPpxdoWJmfWx0OPK3ebdhBfgS+KWhp=6+Ex_yMk_3w@mail.gmail.com> <AM5PR0801MB20512CB8A2B0C1DD3AB23CEB95AE0@AM5PR0801MB2051.eurprd08.prod.outlook.com> <CAFV=PSGLUQKE3HW2aGmzU1dtE1t1Tyj8iLrz24xi7c8tOumhzg@mail.gmail.com> <AM5PR0801MB205178F05CF85D844D706D1295AE0@AM5PR0801MB2051.eurprd08.prod.outlook.com> From: Michael Dolan <mdolan@linuxfoundation.org> Date: Mon, 31 Oct 2016 12:52:22 -0400 Message-ID: <CAFV=PSHgjXQ0FcsCukU=1oN=cKHWVk8nxHsXv+W=4oDViqeZsg@mail.gmail.com> To: Matt Spencer <Matt.Spencer@arm.com> Content-Type: multipart/alternative; boundary=001a1143f94c24e64d05402c0865 Cc: "moving@dpdk.org" <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 <moving.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/moving>, <mailto:moving-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/moving/> List-Post: <mailto:moving@dpdk.org> List-Help: <mailto:moving-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/moving>, <mailto:moving-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 31 Oct 2016 16:52:24 -0000 --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 <Matt.Spencer@arm.com> 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 <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 > > 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 <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 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 <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 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 <Matt.Spencer@arm.com> >> wrote: >> >>> Thanks for the responses. I'm really looking forward to the debate >>> later today! >>> >>> >>> One point I would raise, and it is one that Thomas picked up on a bit. >>> I don't think we can have a pure meritocracy /and/ expect some of the >>> membership to pay to support the project management. I am going to 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 <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.co= m> >>> 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 <div dir=3D"ltr">Ah, now I understand better what you were suggesting - tha= nks for that context.=C2=A0<div><br></div><div>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</div><div><br></div><div>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.<div><br></div><div>-- Mike<br><div><br></div= ><div>=C2=A0</div></div></div></div><div class=3D"gmail_extra"><br clear=3D= "all"><div><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature= "><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div di= r=3D"ltr"> <p><font size=3D"2">---<br>Mike Dolan<br>VP of Strategic Programs<br>The Li= nux Foundation<br>Office: +1.330.460.3250 =C2=A0=C2=A0Cell: +1.440.552.5322= =C2=A0Skype: michaelkdolan<br><a href=3D"mailto:mdolan@linuxfoundation.org= " target=3D"_blank">mdolan@linuxfoundation.org</a><br>---</font></p></div><= /div></div></div></div></div></div></div></div> <br><div class=3D"gmail_quote">On Mon, Oct 31, 2016 at 12:43 PM, Matt Spenc= er <span dir=3D"ltr"><<a href=3D"mailto:Matt.Spencer@arm.com" target=3D"= _blank">Matt.Spencer@arm.com</a>></span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div> <div id=3D"m_7617546286613196568divtagdefaultwrapper" style=3D"font-size:12= pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif"> <p>Hi Michael</p> <p><br> </p> <p>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.</p> <p><br> </p> <p>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.</p> <p><br> </p> <p>What does the LF view as being a healthy, diverse technical leadership?<= /p> <p><br> </p> <p>Regards</p> <p><br> </p> <p>Matt</p> </div> <hr style=3D"display:inline-block;width:98%"> <div id=3D"m_7617546286613196568divRplyFwdMsg" dir=3D"ltr"><font face=3D"Ca= libri, sans-serif" style=3D"font-size:11pt" color=3D"#000000"><b>From:</b> = Michael Dolan <<a href=3D"mailto:mdolan@linuxfoundation.org" target=3D"_= blank">mdolan@linuxfoundation.org</a>><br> <b>Sent:</b> 31 October 2016 16:33:52<div><div class=3D"h5"><br> <b>To:</b> Matt Spencer<br> <b>Cc:</b> Vincent Jardin; Thomas Monjalon; <a href=3D"mailto:moving@dpdk.o= rg" target=3D"_blank">moving@dpdk.org</a><br> <b>Subject:</b> Re: [dpdk-moving] description of technical governance</div>= </div></font> <div>=C2=A0</div> </div><div><div class=3D"h5"> <div> <div dir=3D"ltr">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 <div><br> </div> <div>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</div> <div><br> </div> <div>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</div> <div><br> </div> <div>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</div> <div><br> </div> <div>Does this help Matt?</div> <div><br> </div> <div>-- Mike</div> </div> <div class=3D"gmail_extra"><br clear=3D"all"> <div> <div class=3D"m_7617546286613196568gmail_signature" data-smartmail=3D"gmail= _signature"> <div dir=3D"ltr"> <div> <div dir=3D"ltr"> <div> <div dir=3D"ltr"> <div> <div dir=3D"ltr"> <p><font size=3D"2">---<br> Mike Dolan<br> VP of Strategic Programs<br> The Linux Foundation<br> Office: <a href=3D"tel:%2B1.330.460.3250" value=3D"+13304603250" target=3D"= _blank">+1.330.460.3250</a> =C2=A0=C2=A0Cell: <a href=3D"tel:%2B1.440.552.5= 322" value=3D"+14405525322" target=3D"_blank">+1.440.552.5322</a> =C2=A0Sky= pe: michaelkdolan<br> <a href=3D"mailto:mdolan@linuxfoundation.org" target=3D"_blank">mdolan@linu= xfoundation.org</a><br> ---</font></p> </div> </div> </div> </div> </div> </div> </div> </div> </div> <br> <div class=3D"gmail_quote">On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer <= span dir=3D"ltr"> <<a href=3D"mailto:Matt.Spencer@arm.com" target=3D"_blank">Matt.Spencer@= arm.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div> <div id=3D"m_7617546286613196568m_-56030151295504116divtagdefaultwrapper" s= tyle=3D"font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sa= ns-serif"> <p>Hi Michael</p> <p><br> </p> <p>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 (<a href=3D"https://fd.io/sites/cpstandard/files/pages/files/exhibit_a_-= _fd.io_project_by-laws.pdf" class=3D"m_7617546286613196568m_-56030151295504= 116OWAAutoLink" target=3D"_blank">https://fd.io/sites/cpstandar<wbr>d/files= /pages/files/exhibit_a_<wbr>-_fd.io_project_by-laws.pdf</a>)=C2=A0, the Platinum level membership gets you a seat on the Board, plus in sectio= n 2.3.b '<span><i>designate one representative to serve as a member of = the TSC</i>'.=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?</span></p> <p><span><br> </span></p> <p><span>I hope you can understand why I am a little confused by your comme= nts now?</span></p> <p><span><br> </span></p> <p><span>Regards</span></p> <p><span><br> </span></p> <p><span>Matt</span></p> </div> <hr style=3D"display:inline-block;width:98%"> <div id=3D"m_7617546286613196568m_-56030151295504116divRplyFwdMsg" dir=3D"l= tr"><font face=3D"Calibri, sans-serif" style=3D"font-size:11pt" color=3D"#0= 00000"><b>From:</b> Michael Dolan <<a href=3D"mailto:mdolan@linuxfoundat= ion.org" target=3D"_blank">mdolan@linuxfoundation.org</a>><br> <b>Sent:</b> 31 October 2016 16:07:03<br> <b>To:</b> Matt Spencer<br> <b>Cc:</b> Vincent Jardin; Thomas Monjalon; <a href=3D"mailto:moving@dpdk.o= rg" target=3D"_blank"> moving@dpdk.org</a> <div> <div class=3D"m_7617546286613196568h5"><br> <b>Subject:</b> Re: [dpdk-moving] description of technical governance</div> </div> </font> <div>=C2=A0</div> </div> <div> <div class=3D"m_7617546286613196568h5"> <div> <div dir=3D"ltr">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 <div><br> </div> <div>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</div> <div><br> </div> <div>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</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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> <div><br> </div> <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.</div> <div><br> </div> <div>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</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>Thanks,</div> <div><br> </div> <div>Mike</div> <div><br> </div> </div> <div class=3D"gmail_extra"><br clear=3D"all"> <div> <div class=3D"m_7617546286613196568m_-56030151295504116gmail_signature" dat= a-smartmail=3D"gmail_signature"> <div dir=3D"ltr"> <div> <div dir=3D"ltr"> <div> <div dir=3D"ltr"> <div> <div dir=3D"ltr"> <p><font size=3D"2">---<br> Mike Dolan<br> VP of Strategic Programs<br> The Linux Foundation<br> Office: <a href=3D"tel:%2B1.330.460.3250" value=3D"+13304603250" target=3D"= _blank">+1.330.460.3250</a> =C2=A0=C2=A0Cell: <a href=3D"tel:%2B1.440.552.5322" value=3D"+14405525322" target=3D"_blank">= +1.440.552.5322</a> =C2=A0Skype: michaelkdolan<br> <a href=3D"mailto:mdolan@linuxfoundation.org" target=3D"_blank">mdolan@linu= xfoundation.org</a><br> ---</font></p> </div> </div> </div> </div> </div> </div> </div> </div> </div> <br> <div class=3D"gmail_quote">On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <= span dir=3D"ltr"> <<a href=3D"mailto:Matt.Spencer@arm.com" target=3D"_blank">Matt.Spencer@= arm.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div> <div dir=3D"ltr"> <div id=3D"m_7617546286613196568m_-56030151295504116m_2706980808771478208x_= divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font-family:Cal= ibri,Arial,Helvetica,sans-serif"> <p>Thanks for the responses.=C2=A0 I'm really looking forward to the de= bate later today!</p> <p><br> </p> <p>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.</p> <p><br> </p> <p>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.</p> <p><br> </p> <p>I don't think we can have both of these positions hold true.=C2=A0 W= e either have</p> <p>=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</p> <p>=C2=A02 - Something a bit more like FD.io, with paid membership and paid= access to a board/TSC</p> <p><br> </p> <p>Regards</p> <p><br> </p> <p>Matt</p> </div> <hr style=3D"display:inline-block;width:98%"> <div id=3D"m_7617546286613196568m_-56030151295504116m_2706980808771478208x_= divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" color=3D"#000= 000" style=3D"font-size:11pt"><b>From:</b> Vincent Jardin <<a href=3D"ma= ilto:vincent.jardin@6wind.com" target=3D"_blank">vincent.jardin@6wind.com</= a>><br> <b>Sent:</b> 28 October 2016 23:54:13<br> <b>To:</b> Thomas Monjalon; <a href=3D"mailto:moving@dpdk.org" target=3D"_b= lank">moving@dpdk.org</a>; Matt Spencer<span><br> <b>Subject:</b> Re: [dpdk-moving] description of technical governance</span= ></font> <div>=C2=A0</div> </div> </div> <font size=3D"2"><span style=3D"font-size:10pt"> <div class=3D"m_7617546286613196568m_-56030151295504116m_270698080877147820= 8PlainText"><br> <div> <div class=3D"m_7617546286613196568m_-56030151295504116h5"><br> Le 28 octobre 2016 9:22:43 PM Thomas Monjalon <<a href=3D"mailto:thomas.= monjalon@6wind.com" target=3D"_blank">thomas.monjalon@6wind.com</a>> a <br> =C3=A9crit :<br> <br> > 2016-10-28 16:52, Matt Spencer:<br> >> 1 - we adopt the model as is - one TSC member per committer<br> >> As this stands today, that would give us 56 TSC members,<br> >> with almost half of them from one company<br> >><br> >> 2 - we adopt the model as is - one TSC member per committer -<br> >> to a maximum of 20% membership of the TSC<br> >> 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> >><br> >> 3 - Maximum one member of TSC per committing company,<br> >> plus one TSC assignee per paid member<br> >> This would keep the TSC to a manageable level, give companies<br> >> an incentive to join, but not require membership to be on the TSC<= br> >><br> >> 4 - Something else?<br> >><br> >> My current thoughts are with 3 because we should end up with a<br> >> representative cross section of the stakeholders of the project,<b= r> >> whilst still incentivising membership of the foundation.<br> ><br> > Thanks for sharing your view.<br> ><br> > I'm an Open Source guy and I might lack some politician skills.<br= > > So please excuse me if I take the freedom to talk really frankly :)<br= > ><br> > First of all, this email thread was dedicated to the technical governa= nce.<br> > And Matt is introducing money in this topic by talking about incentive= s.<br> > I think it is a very interesting point that we must discuss.<br> > From the beginning, everybody were saying that we must keep technical<= br> > governance and legal structure separate.<br> > However one question has still no good answer: what is the incentive<b= r> > for contributing money in the structure?<br> > Is money going to biase the desired meritocratic system?<br> ><br> > My second comment is about having one company controlling the technica= l<br> > governance.<br> > I won't enter into the number details, and it's true that Inte= l provides<br> > at least 50% of the contributions nowadays. Intel is also the biggest<= br> > contributor to Linux. No surprise.<br> > I understand that a voice from ARM is requiring to mitigate this fact.= <br> > I would prefer ARM related companies working to achieve the same<br> > level of commitment as Intel. They are increasing their contribution p= ace<br> > but may never really compete with a giant like Intel.<br> > That's why I second Matt to say that we must give a chance to ever= y<br> > vendors to influence the technical decisions.<br> > Introducing a membership threshold looks to be a good idea.<br> ><br> > Having said that, I must state that the DPDK reality is a lot more<br> > complex than a competition between vendors.<br> > We are proving that a consensus based model works very well without<br= > > the need of a TSC or a board.<br> > We can create such organization, but please keep in mind that it shoul= d<br> > not be really helpful in the day-to-day job.<br> <br> +2<br> <br> =C2=A0From contributions, meritocracy is applied.<br> <br> <br> </div> </div> </div> </span></font><span>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. </span></div> </blockquote> </div> <br> </div> </div> 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. </div> </div> </div> </blockquote> </div> <br> </div> </div> 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. </div></div></div> </blockquote></div><br></div> --001a1143f94c24e64d05402c0865--