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&#39;s good to=
 send someone with no knowledge of the codebase as a TSC rep. That&#39;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&#39;t make=
 companies contribute technical code and engineer time, so you&#39;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">&lt;<a href=3D"mailto:Matt.Spencer@arm.com" target=3D"=
_blank">Matt.Spencer@arm.com</a>&gt;</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 &#39;virtual veto&#39; 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 &lt;<a href=3D"mailto:mdolan@linuxfoundation.org" target=3D"_=
blank">mdolan@linuxfoundation.org</a>&gt;<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&#39;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&#39;s pretty tough for anyone else to suppor=
t. So we&#39;re artificially creating a more diverse structure so 1 company=
 couldn&#39;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&#39;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&#39;s codebase.=C2=A0</div>
<div><br>
</div>
<div>Where we don&#39;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&#39;ve not analyzed the code contributions and where they&#39=
;re coming from. I&#39;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">
&lt;<a href=3D"mailto:Matt.Spencer@arm.com" target=3D"_blank">Matt.Spencer@=
arm.com</a>&gt;</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 &#39;buying a vote&#39;, 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 &#39;<span><i>designate one representative to serve as a member of =
the TSC</i>&#39;.=C2=A0 When the TSC is used to vote on architectural issue=
s/direction of the project this really does look
 like &#39;buying a vote&#39; 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 &lt;<a href=3D"mailto:mdolan@linuxfoundat=
ion.org" target=3D"_blank">mdolan@linuxfoundation.org</a>&gt;<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&#39;s great to see the discussion and thou=
ghts. I&#39;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 &quot;buy a vote&quot; - you &qu=
ot;vote&quot; 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 (&quot;Technical Steering Committee&quot;=
) 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&#39;s generally=
 most helpful when starting a Project
 based entirely on 1 company&#39;s codebase and it gives others a say to en=
sure it&#39;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&#39;ll host for LF members if there&#39;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&#39;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&#39;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&#39;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&#39;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&#39;s a top tier &quot;Premier&quot; a=
t $50k/year and a lower tier &quot;General&quot; 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 &quot;buy&quot; 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&#39;re not paying to build the entire infrastructur=
e themselves, but sharing the cost with others. Typically a &quot;hook&quot=
; is to have a logo or something available to show your company is a &quot;=
DPDK Project Member&quot; or &quot;Sponsor&quot; 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&#39;t need any public communi=
ty resources other than GitHub and a webpage - and that&#39;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">
&lt;<a href=3D"mailto:Matt.Spencer@arm.com" target=3D"_blank">Matt.Spencer@=
arm.com</a>&gt;</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&#39;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&#39;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&#39;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 &lt;<a href=3D"ma=
ilto:vincent.jardin@6wind.com" target=3D"_blank">vincent.jardin@6wind.com</=
a>&gt;<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 &lt;<a href=3D"mailto:thomas.=
monjalon@6wind.com" target=3D"_blank">thomas.monjalon@6wind.com</a>&gt; a
<br>
=C3=A9crit :<br>
<br>
&gt; 2016-10-28 16:52, Matt Spencer:<br>
&gt;&gt; 1 - we adopt the model as is - one TSC member per committer<br>
&gt;&gt; As this stands today, that would give us 56 TSC members,<br>
&gt;&gt; with almost half of them from one company<br>
&gt;&gt;<br>
&gt;&gt; 2 - we adopt the model as is - one TSC member per committer -<br>
&gt;&gt; to a maximum of 20% membership of the TSC<br>
&gt;&gt; This would ensure that no one company can &#39;own&#39; the TSC -<=
br>
&gt;&gt; 56 committers, so max TSC membership from one company would be 11<=
br>
&gt;&gt;<br>
&gt;&gt; 3 - Maximum one member of TSC per committing company,<br>
&gt;&gt; plus one TSC assignee per paid member<br>
&gt;&gt; This would keep the TSC to a manageable level, give companies<br>
&gt;&gt; an incentive to join, but not require membership to be on the TSC<=
br>
&gt;&gt;<br>
&gt;&gt; 4 - Something else?<br>
&gt;&gt;<br>
&gt;&gt; My current thoughts are with 3 because we should end up with a<br>
&gt;&gt; representative cross section of the stakeholders of the project,<b=
r>
&gt;&gt; whilst still incentivising membership of the foundation.<br>
&gt;<br>
&gt; Thanks for sharing your view.<br>
&gt;<br>
&gt; I&#39;m an Open Source guy and I might lack some politician skills.<br=
>
&gt; So please excuse me if I take the freedom to talk really frankly :)<br=
>
&gt;<br>
&gt; First of all, this email thread was dedicated to the technical governa=
nce.<br>
&gt; And Matt is introducing money in this topic by talking about incentive=
s.<br>
&gt; I think it is a very interesting point that we must discuss.<br>
&gt; From the beginning, everybody were saying that we must keep technical<=
br>
&gt; governance and legal structure separate.<br>
&gt; However one question has still no good answer: what is the incentive<b=
r>
&gt; for contributing money in the structure?<br>
&gt; Is money going to biase the desired meritocratic system?<br>
&gt;<br>
&gt; My second comment is about having one company controlling the technica=
l<br>
&gt; governance.<br>
&gt; I won&#39;t enter into the number details, and it&#39;s true that Inte=
l provides<br>
&gt; at least 50% of the contributions nowadays. Intel is also the biggest<=
br>
&gt; contributor to Linux. No surprise.<br>
&gt; I understand that a voice from ARM is requiring to mitigate this fact.=
<br>
&gt; I would prefer ARM related companies working to achieve the same<br>
&gt; level of commitment as Intel. They are increasing their contribution p=
ace<br>
&gt; but may never really compete with a giant like Intel.<br>
&gt; That&#39;s why I second Matt to say that we must give a chance to ever=
y<br>
&gt; vendors to influence the technical decisions.<br>
&gt; Introducing a membership threshold looks to be a good idea.<br>
&gt;<br>
&gt; Having said that, I must state that the DPDK reality is a lot more<br>
&gt; complex than a competition between vendors.<br>
&gt; We are proving that a consensus based model works very well without<br=
>
&gt; the need of a TSC or a board.<br>
&gt; We can create such organization, but please keep in mind that it shoul=
d<br>
&gt; 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--