[dpdk-moving] [Topics]

[dpdk-moving] [Topics]

[Francois Ozog]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

Hi,

Tim mentioned we need to revise budget, actually I see a few set of topics
 adress:
- legal: bylaws, CLA, TCO
- governance: board, TSC...
- finance: budget, membership

I'll post a few things on [legal] later today.

Cordially,

François-Frédéric

PS: just saw the mailing list anouncement, so I bcc'ed the people I know
just in case...



-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

[-- Attachment #2: Type: text/html, Size: 2118 bytes --]

Re: [dpdk-moving] [Topics]

[O'Driscoll, Tim]

> From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Francois Ozog
> Sent: Tuesday, October 25, 2016 9:59 AM
> To: moving@dpdk.org
> Subject: [dpdk-moving] [Topics]
>
> Hi,
>
> Tim mentioned we need to revise budget, actually I see a few set of topics  adress:
> - legal: bylaws, CLA, TCO
> - governance: board, TSC...
> - finance: budget, membership
>
> I'll post a few things on [legal] later today.
>
> Cordially,
>
> François-Frédéric
>
> PS: just saw the mailing list anouncement, so I bcc'ed the people I know just in case...

That's a good list. I was thinking the same thing and had similar items in mind. If you can start some discussion on the legal issues, that would be great.

One thing I think we need to consider is what the benefits of membership would be. We didn't really cover this in our discussions earlier in the year. We're all agreed that technical contributions and decisions should be independent of membership, but it seems reasonable that companies who contribute should get something in return for their contribution to the project. Possibilities might include: board seats, having a say in how the project budget is spent, the ability to host equipment in a DPDK CI/test lab etc. This spans the "governance: board" and "membership" items above. I can look into this a bit further and post some further thoughts on this.

We also have a gap in terms of documenting technical governance. Even ignoring the move to LF, Matt in particular was looking for more clarity on this. Thomas: would you be willing to create and post a proposal on this?


Tim

Re: [dpdk-moving] description of technical governance

[Thomas Monjalon]

2016-10-25 11:27, O'Driscoll, Tim:
> We also have a gap in terms of documenting technical governance.
> Even ignoring the move to LF, Matt in particular was looking for
> more clarity on this.
> Thomas: would you be willing to create and post a proposal on this?

The technical governance is consensus-based.
The board was built in case a consensus is not found.

There are several projects with their own git trees.
DPDK and the web site are two of them.

The DPDK project is organized around some git subtrees
and the mainline gathers every contributions accepted in the subtrees.
The component maintainers are quality responsibles for the code and
the git history. They coordinate how improvements and fixes are done.
The git tree committers are responsibles of the pace, giving time for
reviews and tests while releasing in time. They also do the last checks
or call for help when there is no progress on a patch.

Is it the kind of information you are looking for?
I think the technical governance must be described on the web site
in the "development" page.
It is already partly described but it may requires more details and updates.

Re: [dpdk-moving] [Topics]

[Dave Neary]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

Hello FF,

First, let's share what we have already.

Also, if he is not yet here, we should invite Mike Dolan and Laura
Kempke to join this list.

I have attached the last draft I saw of the LF budget proposal, plus
various other artifacts that were presented and discussed last time around.

Budget proposal:
https://docs.google.com/a/linuxfoundation.org/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit?usp=sharing

>From Laura Kempke:
> A few things to note:
> 
> 1/ Column B includes basic expenses. (I assumes you want to keep the summits in San Francisco and China and took a guess at their budgets. The numbers don't include sponsorship or registration revenue.)
> 
> 2/ Column C has thoughts on additional items you could consider. Most of those services can be scaled up or down, and of course you can go with some and leave others. My objective in including them is to let you know they're available if you need them.
> 
> 3/ The legal expenses are placeholders.
> 
> 4/ I assumed $300K in revenue.
> 
> Would it be helpful to discuss this early next week?

Attached: slides that Mike Dolan presented on the value of the LF in
December 2015. Old, but potentially relevant.

Thanks,
Dave.


On 10/25/2016 10:58 AM, Francois Ozog wrote:
> Hi,
> 
> Tim mentioned we need to revise budget, actually I see a few set of
> topics  adress:
> - legal: bylaws, CLA, TCO
> - governance: board, TSC...
> - finance: budget, membership
> 
> I'll post a few things on [legal] later today.
> 
> Cordially,
> 
> François-Frédéric
> 
> PS: just saw the mailing list anouncement, so I bcc'ed the people I know
> just in case...
> 
> 
> 
> -- 
> Linaro <http://www.linaro.org/>	
> François-Frédéric Ozog | /Director Linaro Networking Group/
> T: +33.67221.6485 <tel:%2B33.67221.6485>
> francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog
> 
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[-- Attachment #2: LF Overview for DPDK Community - 16 December 2015.pdf --]
[-- Type: application/pdf, Size: 1092634 bytes --]

Re: [dpdk-moving] description of technical governance

[O'Driscoll, Tim]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, October 25, 2016 3:00 PM
> To: moving@dpdk.org
> Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>
> Subject: Re: [dpdk-moving] description of technical governance
> 
> 2016-10-25 11:27, O'Driscoll, Tim:
> > We also have a gap in terms of documenting technical governance.
> > Even ignoring the move to LF, Matt in particular was looking for
> > more clarity on this.
> > Thomas: would you be willing to create and post a proposal on this?
> 
> The technical governance is consensus-based.
> The board was built in case a consensus is not found.
> 
> There are several projects with their own git trees.
> DPDK and the web site are two of them.
> 
> The DPDK project is organized around some git subtrees
> and the mainline gathers every contributions accepted in the subtrees.
> The component maintainers are quality responsibles for the code and
> the git history. They coordinate how improvements and fixes are done.
> The git tree committers are responsibles of the pace, giving time for
> reviews and tests while releasing in time. They also do the last checks
> or call for help when there is no progress on a patch.
> 
> Is it the kind of information you are looking for?
> I think the technical governance must be described on the web site
> in the "development" page.
> It is already partly described but it may requires more details and
> updates.

Yes, it's the additional detail that I was asking about. If you look at what we have at the moment (http://dpdk.org/dev), it's quite brief. Other projects typically have more detail, for example:
- FD.io Technical Community Charter: https://fd.io/governance/technical-community-charter
- OvS technical governance including committer responsibilities and process for adding and removing committers: http://openvswitch.github.io/contributors/
- ODL TSC Charter: https://www.opendaylight.org/tsc-charter

We don't necessarily need as much detail as they have, but I think we do need a bit more than we have at the moment. From a brief discussion with Mike Dolan during our previous engagement with the LF earlier in the year, the LF would simply be looking for DPDK technical governance to be properly documented, and for it to be meritocratic (e.g. committers chosen based on history of contributions rather than the company they work for).

Matt also had some thoughts during our discussion in Dublin on things he'd like to see added to the technical governance. Perhaps he can comment further on what he'd like to see.

In terms of where this is documented, I don't think that matters, and adding some additional detail to the existing Development page seems like a good solution to me.

Re: [dpdk-moving] [Topics]

[Dave Neary]

Hi again,

On 10/25/2016 10:58 AM, Francois Ozog wrote:
> Tim mentioned we need to revise budget, actually I see a few set of
> topics  adress:
> - legal: bylaws, CLA, TCO

I would like to ask for what OVS had to agree to - I suspect that it is
very lightweight, there are probably not even specific by-laws - I would
not be surprised to find that it was a corporate contributors agreement
only.

I don't know what you mean by a TCO, but I do not believe we should add
a CLA (beyond what I mention below).

> - governance: board, TSC...

I do think we should create a budget oversight group, but a board and
TSC sounds a lot like the default set-up for an LF project which is
bootstrapping - that's not the case for DPDK, we have a technical
governance framework in place already, I do not see the need to set up a
TSC.

> - finance: budget, membership

It will be good to discuss whether we want to have a membership
agreement or whether we would be happy with a generic organizational
copyright and patent license (explicitly agreeing to license
contributions under the BSD license + patent grant) with a DCO for
contributions, tied to the signed-off-by on patches (which we have
already, unless I am mistaken).

Thanks,
Dave.

> I'll post a few things on [legal] later today.
> 
> Cordially,
> 
> François-Frédéric
> 
> PS: just saw the mailing list anouncement, so I bcc'ed the people I know
> just in case...
> 
> 
> 
> -- 
> Linaro <http://www.linaro.org/>	
> François-Frédéric Ozog | /Director Linaro Networking Group/
> T: +33.67221.6485 <tel:%2B33.67221.6485>
> francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog
> 
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

Re: [dpdk-moving] [Topics]

[Francois Ozog]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

Hi Dave, I though DCO but typed TCO.... Too much marketing ;-)

On 26 October 2016 at 14:47, Dave Neary <dneary@redhat.com> wrote:

> Hi again,
>
> On 10/25/2016 10:58 AM, Francois Ozog wrote:
> > Tim mentioned we need to revise budget, actually I see a few set of
> > topics  adress:
> > - legal: bylaws, CLA, TCO
>
> I would like to ask for what OVS had to agree to - I suspect that it is
> very lightweight, there are probably not even specific by-laws - I would
> not be surprised to find that it was a corporate contributors agreement
> only.
>
> I don't know what you mean by a TCO, but I do not believe we should add
> a CLA (beyond what I mention below).
>
> > - governance: board, TSC...
>
> I do think we should create a budget oversight group, but a board and
> TSC sounds a lot like the default set-up for an LF project which is
> bootstrapping - that's not the case for DPDK, we have a technical
> governance framework in place already, I do not see the need to set up a
> TSC.
>
> > - finance: budget, membership
>
> It will be good to discuss whether we want to have a membership
> agreement or whether we would be happy with a generic organizational
> copyright and patent license (explicitly agreeing to license
> contributions under the BSD license + patent grant) with a DCO for
> contributions, tied to the signed-off-by on patches (which we have
> already, unless I am mistaken).
>
> Thanks,
> Dave.
>
> > I'll post a few things on [legal] later today.
> >
> > Cordially,
> >
> > François-Frédéric
> >
> > PS: just saw the mailing list anouncement, so I bcc'ed the people I know
> > just in case...
> >
> >
> >
> > --
> > Linaro <http://www.linaro.org/>
> > François-Frédéric Ozog | /Director Linaro Networking Group/
> > T: +33.67221.6485 <tel:%2B33.67221.6485>
> > francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype:
> ffozog
> >
> >
>
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
>



-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

[-- Attachment #2: Type: text/html, Size: 4721 bytes --]

Re: [dpdk-moving] description of technical governance

[O'Driscoll, Tim]

> -----Original Message-----
> From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of O'Driscoll,
> Tim
> Sent: Wednesday, October 26, 2016 11:22 AM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>; moving@dpdk.org
> Subject: Re: [dpdk-moving] description of technical governance
> 
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Tuesday, October 25, 2016 3:00 PM
> > To: moving@dpdk.org
> > Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>
> > Subject: Re: [dpdk-moving] description of technical governance
> >
> > 2016-10-25 11:27, O'Driscoll, Tim:
> > > We also have a gap in terms of documenting technical governance.
> > > Even ignoring the move to LF, Matt in particular was looking for
> > > more clarity on this.
> > > Thomas: would you be willing to create and post a proposal on this?
> >
> > The technical governance is consensus-based.
> > The board was built in case a consensus is not found.
> >
> > There are several projects with their own git trees.
> > DPDK and the web site are two of them.
> >
> > The DPDK project is organized around some git subtrees
> > and the mainline gathers every contributions accepted in the subtrees.
> > The component maintainers are quality responsibles for the code and
> > the git history. They coordinate how improvements and fixes are done.
> > The git tree committers are responsibles of the pace, giving time for
> > reviews and tests while releasing in time. They also do the last
> checks
> > or call for help when there is no progress on a patch.
> >
> > Is it the kind of information you are looking for?
> > I think the technical governance must be described on the web site
> > in the "development" page.
> > It is already partly described but it may requires more details and
> > updates.
> 
> Yes, it's the additional detail that I was asking about. If you look at
> what we have at the moment (http://dpdk.org/dev), it's quite brief.
> Other projects typically have more detail, for example:
> - FD.io Technical Community Charter: https://fd.io/governance/technical-
> community-charter
> - OvS technical governance including committer responsibilities and
> process for adding and removing committers:
> http://openvswitch.github.io/contributors/
> - ODL TSC Charter: https://www.opendaylight.org/tsc-charter
> 
> We don't necessarily need as much detail as they have, but I think we do
> need a bit more than we have at the moment. From a brief discussion with
> Mike Dolan during our previous engagement with the LF earlier in the
> year, the LF would simply be looking for DPDK technical governance to be
> properly documented, and for it to be meritocratic (e.g. committers
> chosen based on history of contributions rather than the company they
> work for).
> 
> Matt also had some thoughts during our discussion in Dublin on things
> he'd like to see added to the technical governance. Perhaps he can
> comment further on what he'd like to see.
> 
> In terms of where this is documented, I don't think that matters, and
> adding some additional detail to the existing Development page seems
> like a good solution to me.

I haven't seen anybody else comment on aspects of the technical governance that should be clarified, so here are a few comments/questions from me that might help to prompt some discussion.

We have a few different types of maintainers: 1) those responsible for reviewing changes in individual libraries who are identified in the MAINTAINERS file; 2) sub-tree maintainers who submit pull requests to the main tree; 3) stable release maintainer; 4) main tree maintainer; 5) maintainers for other projects hosted on dpdk.org (pktgen, spp etc.). We should document the responsibilities of each of these, and the process for adding and removing them.

At the moment, the MAINTAINERS file doesn't identify the sub-tree maintainers or the stable release maintainer. I think they should be included.

At the moment, other projects hosted on dpdk.org (pktgen, spp etc.) don't have a MAINTAINERS file. I think this should be mandatory for all sub-projects within DPDK.

Should every repo have more than one person with commit rights so that we're not dependent on a single person? They would obviously have to coordinate on who does what, which could involve sharing the workload or operating on an active/backup basis.

We should document how members of the Tech Board get added/removed. We should also clarify the scope. Is the scope of the Tech Board just DPDK itself (http://dpdk.org/browse/dpdk/tree/), or does it also cover the other projects hosted on dpdk.org (http://dpdk.org/browse/)? If it's just DPDK, then who provides the technical oversight for the other projects? My preference would be for the existing board to cover all sub-projects.

We should document the process for adding a new sub-project like pktgen or SPP. At the moment I think it's proposed on the dev mailing list and added if there's a consensus. Should it be mandatory that new project proposals are reviewed and approved by the Tech Board, to make sure there's consistency and nothing gets missed in a flood of email?

Re: [dpdk-moving] description of technical governance

[Matt Spencer]

[-- Attachment #1.1: Type: text/plain, Size: 7603 bytes --]

Hi Guys


I have a few thoughts on the TSC membership as is outlined by the OVS model that we appear to be wanting to adopt.  The information I have here is taken from a snapshot of the MAINTAINERS file in the latest release of DPDK, and does not take into account what Tim mentions below.


Attached is a spreadsheet that shows how the TSC would look if we were to adopt the OVS model today, and I believe it highlights why a variation of the model be adopted.  As it stands today, it would be heavily biassed towards one company to the point that one organisation would have a virtual veto within the TSC.  I also believe that there would be too many members of the TSC which would hinder it from being an effective governing body for DPDK.


I would the therefor like to put forward a few additional models for suggestion:


1 - we adopt the model as is - one TSC member per committer

       o 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

       o 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

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


My 2c, let me know what you think.


Regards


Matt

________________________________
From: moving <moving-bounces@dpdk.org> on behalf of O'Driscoll, Tim <tim.odriscoll@intel.com>
Sent: 28 October 2016 10:13:51
To: O'Driscoll, Tim; Thomas Monjalon; moving@dpdk.org
Subject: Re: [dpdk-moving] description of technical governance


> -----Original Message-----
> From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of O'Driscoll,
> Tim
> Sent: Wednesday, October 26, 2016 11:22 AM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>; moving@dpdk.org
> Subject: Re: [dpdk-moving] description of technical governance
>
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Tuesday, October 25, 2016 3:00 PM
> > To: moving@dpdk.org
> > Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>
> > Subject: Re: [dpdk-moving] description of technical governance
> >
> > 2016-10-25 11:27, O'Driscoll, Tim:
> > > We also have a gap in terms of documenting technical governance.
> > > Even ignoring the move to LF, Matt in particular was looking for
> > > more clarity on this.
> > > Thomas: would you be willing to create and post a proposal on this?
> >
> > The technical governance is consensus-based.
> > The board was built in case a consensus is not found.
> >
> > There are several projects with their own git trees.
> > DPDK and the web site are two of them.
> >
> > The DPDK project is organized around some git subtrees
> > and the mainline gathers every contributions accepted in the subtrees.
> > The component maintainers are quality responsibles for the code and
> > the git history. They coordinate how improvements and fixes are done.
> > The git tree committers are responsibles of the pace, giving time for
> > reviews and tests while releasing in time. They also do the last
> checks
> > or call for help when there is no progress on a patch.
> >
> > Is it the kind of information you are looking for?
> > I think the technical governance must be described on the web site
> > in the "development" page.
> > It is already partly described but it may requires more details and
> > updates.
>
> Yes, it's the additional detail that I was asking about. If you look at
> what we have at the moment (http://dpdk.org/dev), it's quite brief.
> Other projects typically have more detail, for example:
> - FD.io Technical Community Charter: https://fd.io/governance/technical-
> community-charter
> - OvS technical governance including committer responsibilities and
> process for adding and removing committers:
> http://openvswitch.github.io/contributors/
> - ODL TSC Charter: https://www.opendaylight.org/tsc-charter
>
> We don't necessarily need as much detail as they have, but I think we do
> need a bit more than we have at the moment. From a brief discussion with
> Mike Dolan during our previous engagement with the LF earlier in the
> year, the LF would simply be looking for DPDK technical governance to be
> properly documented, and for it to be meritocratic (e.g. committers
> chosen based on history of contributions rather than the company they
> work for).
>
> Matt also had some thoughts during our discussion in Dublin on things
> he'd like to see added to the technical governance. Perhaps he can
> comment further on what he'd like to see.
>
> In terms of where this is documented, I don't think that matters, and
> adding some additional detail to the existing Development page seems
> like a good solution to me.

I haven't seen anybody else comment on aspects of the technical governance that should be clarified, so here are a few comments/questions from me that might help to prompt some discussion.

We have a few different types of maintainers: 1) those responsible for reviewing changes in individual libraries who are identified in the MAINTAINERS file; 2) sub-tree maintainers who submit pull requests to the main tree; 3) stable release maintainer; 4) main tree maintainer; 5) maintainers for other projects hosted on dpdk.org (pktgen, spp etc.). We should document the responsibilities of each of these, and the process for adding and removing them.

At the moment, the MAINTAINERS file doesn't identify the sub-tree maintainers or the stable release maintainer. I think they should be included.

At the moment, other projects hosted on dpdk.org (pktgen, spp etc.) don't have a MAINTAINERS file. I think this should be mandatory for all sub-projects within DPDK.

Should every repo have more than one person with commit rights so that we're not dependent on a single person? They would obviously have to coordinate on who does what, which could involve sharing the workload or operating on an active/backup basis.

We should document how members of the Tech Board get added/removed. We should also clarify the scope. Is the scope of the Tech Board just DPDK itself (http://dpdk.org/browse/dpdk/tree/), or does it also cover the other projects hosted on dpdk.org (http://dpdk.org/browse/)? If it's just DPDK, then who provides the technical oversight for the other projects? My preference would be for the existing board to cover all sub-projects.

We should document the process for adding a new sub-project like pktgen or SPP. At the moment I think it's proposed on the dev mailing list and added if there's a consensus. Should it be mandatory that new project proposals are reviewed and approved by the Tech Board, to make sure there's consistency and nothing gets missed in a flood of email?

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.

[-- Attachment #1.2: Type: text/html, Size: 9890 bytes --]

[-- Attachment #2: TSC Members by company.xlsx --]
[-- Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, Size: 54665 bytes --]

Re: [dpdk-moving] description of technical governance

[Thomas Monjalon]

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.

Re: [dpdk-moving] description of technical governance

[Vincent Jardin]

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

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

Re: [dpdk-moving] description of technical governance

[Matt Spencer]

[-- Attachment #1: Type: text/plain, Size: 4319 bytes --]

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 have a very hard time explaining to my exec why we should be spending $$$ on DPDK 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 this 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.com> a
écrit :

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

[-- Attachment #2: Type: text/html, Size: 5882 bytes --]

Re: [dpdk-moving] description of technical governance

[Michael Dolan]

[-- Attachment #1: Type: text/plain, Size: 9109 bytes --]

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" 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), 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 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 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. The
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 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
members of the other projects we took funds from would not be happy to say
the least.

Third, when there is funding involved in a project, we typically setup a
Governing Board that owns responsibility for how to spend the funding. The
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 funds are spent. Often some projects will
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 funds
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 per
every X lower tier members). Typically the ratio is based on roughly what
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 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
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 for
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 guiding
discussions about how LF Projects are structured and some of the rationale
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 have a
> very hard time explaining to my exec why we should be spending $$$ on DPDK
> 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 this
> 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.com>
> a
> écrit :
>
> > 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
> 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.
>

[-- Attachment #2: Type: text/html, Size: 11285 bytes --]

Re: [dpdk-moving] description of technical governance

[Matt Spencer]

[-- Attachment #1: Type: text/plain, Size: 10197 bytes --]

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


Regards


Matt

________________________________
From: Michael Dolan <mdolan@linuxfoundation.org>
Sent: 31 October 2016 16:07:03
To: Matt Spencer
Cc: Vincent Jardin; Thomas Monjalon; moving@dpdk.org
Subject: Re: [dpdk-moving] description of technical governance

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" 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), 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 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 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. The 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 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 members of the other projects we took funds from would not be happy to say the least.

Third, when there is funding involved in a project, we typically setup a Governing Board that owns responsibility for how to spend the funding. The 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 funds are spent. Often some projects will 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 funds 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 per every X lower tier members). Typically the ratio is based on roughly what 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 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 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 for 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 guiding discussions about how LF Projects are structured and some of the rationale 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<mailto:mdolan@linuxfoundation.org>
---

On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <Matt.Spencer@arm.com<mailto: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 have a very hard time explaining to my exec why we should be spending $$$ on DPDK 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 this 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<mailto:vincent.jardin@6wind.com>>
Sent: 28 October 2016 23:54:13
To: Thomas Monjalon; moving@dpdk.org<mailto: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<mailto:thomas.monjalon@6wind.com>> a
écrit :

> 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 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 the information in any medium. Thank you.

[-- Attachment #2: Type: text/html, Size: 13500 bytes --]

Re: [dpdk-moving] description of technical governance

[Michael Dolan]

[-- Attachment #1: Type: text/plain, Size: 13109 bytes --]

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 of
contributors in a project. FD.io was setup with one initial project called
VPP. In that case, it was 100% Cisco developers/engineers working on it.
The 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 had
setup FD.io with 1 project VPP and 100% Cisco maintainers... that's pretty
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 in
FD.io can appoint a representative to the TSC, our TSC's also include the
PTLs from the main projects.  I stated this in my long email, but to put it
bluntly here - in my view, putting top tier members on a TSC is tool to use
when you want to improve the corporate diversity of contribution. This is
usually most beneficial in Projects that start with 1 company's codebase.

Where we don't have a top tier membership appointing seats on a TSC, 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 coming
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 now?
>
>
> Regards
>
>
> Matt
> ------------------------------
> *From:* Michael Dolan <mdolan@linuxfoundation.org>
> *Sent:* 31 October 2016 16:07:03
> *To:* Matt Spencer
> *Cc:* Vincent Jardin; Thomas Monjalon; moving@dpdk.org
>
> *Subject:* Re: [dpdk-moving] description of technical governance
>
> 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" 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), 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 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 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. The
> 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 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
> members of the other projects we took funds from would not be happy to say
> the least.
>
> Third, when there is funding involved in a project, we typically setup a
> Governing Board that owns responsibility for how to spend the funding. The
> 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 funds are spent. Often some projects will
> 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 funds
> 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 per
> every X lower tier members). Typically the ratio is based on roughly what
> 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 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
> 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 for
> 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 guiding
> discussions about how LF Projects are structured and some of the rationale
> 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 have a
>> very hard time explaining to my exec why we should be spending $$$ on DPDK
>> 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 this
>> 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.com>
>> a
>> écrit :
>>
>> > 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
>> 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 the
> information in any medium. Thank you.
>

[-- Attachment #2: Type: text/html, Size: 17011 bytes --]

Re: [dpdk-moving] description of technical governance

[Matt Spencer]

[-- Attachment #1: Type: text/plain, Size: 14286 bytes --]

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 how 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 members of the TSC, with DPDK as it stands today there would be about 56.  I am not sure that a leadership committee can work effectively at this size, so I 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 of contributors in a project. FD.io was setup with one initial project called VPP. In that case, it was 100% Cisco developers/engineers working on it. The 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 had setup FD.io with 1 project VPP and 100% Cisco maintainers... that's pretty 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 in FD.io can appoint a representative to the TSC, our TSC's also include the PTLs from the main projects.  I stated this in my long email, but to put it bluntly here - in my view, putting top tier members on a TSC is tool to use when you want to improve the corporate diversity of contribution. This is usually most beneficial in Projects that start with 1 company's codebase.

Where we don't have a top tier membership appointing seats on a TSC, 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 coming 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<mailto:mdolan@linuxfoundation.org>
---

On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer <Matt.Spencer@arm.com<mailto: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 now?


Regards


Matt

________________________________
From: Michael Dolan <mdolan@linuxfoundation.org<mailto:mdolan@linuxfoundation.org>>
Sent: 31 October 2016 16:07:03
To: Matt Spencer
Cc: Vincent Jardin; Thomas Monjalon; moving@dpdk.org<mailto: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" 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), 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 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 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. The 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 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 members of the other projects we took funds from would not be happy to say the least.

Third, when there is funding involved in a project, we typically setup a Governing Board that owns responsibility for how to spend the funding. The 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 funds are spent. Often some projects will 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 funds 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 per every X lower tier members). Typically the ratio is based on roughly what 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 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 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 for 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 guiding discussions about how LF Projects are structured and some of the rationale behind it.

Thanks,

Mike



---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250<tel:%2B1.330.460.3250>   Cell: +1.440.552.5322<tel:%2B1.440.552.5322>  Skype: michaelkdolan
mdolan@linuxfoundation.org<mailto:mdolan@linuxfoundation.org>
---

On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <Matt.Spencer@arm.com<mailto: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 have a very hard time explaining to my exec why we should be spending $$$ on DPDK 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 this 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<mailto:vincent.jardin@6wind.com>>
Sent: 28 October 2016 23:54:13
To: Thomas Monjalon; moving@dpdk.org<mailto: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<mailto:thomas.monjalon@6wind.com>> a
écrit :

> 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 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 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 the information in any medium. Thank you.

[-- Attachment #2: Type: text/html, Size: 19307 bytes --]

Re: [dpdk-moving] description of technical governance

[Michael Dolan]

[-- Attachment #1: Type: text/plain, Size: 16547 bytes --]

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 how
> 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 members
> of the TSC, with DPDK as it stands today there would be about 56.  I am not
> sure that a leadership committee can work effectively at this size, so I
> 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 of
> contributors in a project. FD.io was setup with one initial project called
> VPP. In that case, it was 100% Cisco developers/engineers working on it.
> The 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 had
> setup FD.io with 1 project VPP and 100% Cisco maintainers... that's pretty
> 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 in
> FD.io can appoint a representative to the TSC, our TSC's also include the
> PTLs from the main projects.  I stated this in my long email, but to put it
> bluntly here - in my view, putting top tier members on a TSC is tool to use
> when you want to improve the corporate diversity of contribution. This is
> usually most beneficial in Projects that start with 1 company's codebase.
>
> Where we don't have a top tier membership appointing seats on a TSC, 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 coming
> 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 now?
>>
>>
>> Regards
>>
>>
>> Matt
>> ------------------------------
>> *From:* Michael Dolan <mdolan@linuxfoundation.org>
>> *Sent:* 31 October 2016 16:07:03
>> *To:* Matt Spencer
>> *Cc:* Vincent Jardin; Thomas Monjalon; moving@dpdk.org
>>
>> *Subject:* Re: [dpdk-moving] description of technical governance
>>
>> 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" 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), 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 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 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. The
>> 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 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
>> members of the other projects we took funds from would not be happy to say
>> the least.
>>
>> Third, when there is funding involved in a project, we typically setup a
>> Governing Board that owns responsibility for how to spend the funding. The
>> 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 funds are spent. Often some projects will
>> 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 funds
>> 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 per
>> every X lower tier members). Typically the ratio is based on roughly what
>> 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 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 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 for
>> 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 guiding
>> discussions about how LF Projects are structured and some of the rationale
>> 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 have a
>>> very hard time explaining to my exec why we should be spending $$$ on DPDK
>>> 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 this
>>> 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.com>
>>> a
>>> écrit :
>>>
>>> > 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
>>> 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 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 the
> information in any medium. Thank you.
>

[-- Attachment #2: Type: text/html, Size: 21926 bytes --]

Re: [dpdk-moving] description of technical governance

[O'Driscoll, Tim]

[-- Attachment #1: Type: text/plain, Size: 16897 bytes --]

We do have a Technical Board (effectively a TSC with a different name) for DPDK in place already (see http://dpdk.org/dev#board). We deliberately populated this board based on the most significant contributors to the project, and made sure that it was balanced so that no single company had a majority. Current composition is 2 members from Intel, 2 from 6WIND, 1 from Cavium, 1 from Red Hat and 1 from Microsoft.

My proposal would be that we keep this board in place rather than create a new TSC. I do think we need to more clearly define the scope of the board and how people are added to/removed from it, but I don’t see a reason to change or replace it.


Tim

From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Michael Dolan
Sent: Monday, October 31, 2016 4:52 PM
To: Matt Spencer <Matt.Spencer@arm.com>
Cc: moving@dpdk.org
Subject: Re: [dpdk-moving] description of technical governance

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<mailto:mdolan@linuxfoundation.org>
---

On Mon, Oct 31, 2016 at 12:43 PM, Matt Spencer <Matt.Spencer@arm.com<mailto: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 how 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 members of the TSC, with DPDK as it stands today there would be about 56.  I am not sure that a leadership committee can work effectively at this size, so I 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<mailto:mdolan@linuxfoundation.org>>
Sent: 31 October 2016 16:33:52

To: Matt Spencer
Cc: Vincent Jardin; Thomas Monjalon; moving@dpdk.org<mailto: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 of contributors in a project. FD.io was setup with one initial project called VPP. In that case, it was 100% Cisco developers/engineers working on it. The 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 had setup FD.io with 1 project VPP and 100% Cisco maintainers... that's pretty 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 in FD.io can appoint a representative to the TSC, our TSC's also include the PTLs from the main projects.  I stated this in my long email, but to put it bluntly here - in my view, putting top tier members on a TSC is tool to use when you want to improve the corporate diversity of contribution. This is usually most beneficial in Projects that start with 1 company's codebase.

Where we don't have a top tier membership appointing seats on a TSC, 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 coming 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<tel:%2B1.330.460.3250>   Cell: +1.440.552.5322<tel:%2B1.440.552.5322>  Skype: michaelkdolan
mdolan@linuxfoundation.org<mailto:mdolan@linuxfoundation.org>
---

On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer <Matt.Spencer@arm.com<mailto: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 now?



Regards



Matt

________________________________
From: Michael Dolan <mdolan@linuxfoundation.org<mailto:mdolan@linuxfoundation.org>>
Sent: 31 October 2016 16:07:03
To: Matt Spencer
Cc: Vincent Jardin; Thomas Monjalon; moving@dpdk.org<mailto: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" 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), 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 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 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. The 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 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 members of the other projects we took funds from would not be happy to say the least.

Third, when there is funding involved in a project, we typically setup a Governing Board that owns responsibility for how to spend the funding. The 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 funds are spent. Often some projects will 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 funds 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 per every X lower tier members). Typically the ratio is based on roughly what 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 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 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 for 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 guiding discussions about how LF Projects are structured and some of the rationale behind it.

Thanks,

Mike



---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250<tel:%2B1.330.460.3250>   Cell: +1.440.552.5322<tel:%2B1.440.552.5322>  Skype: michaelkdolan
mdolan@linuxfoundation.org<mailto:mdolan@linuxfoundation.org>
---

On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <Matt.Spencer@arm.com<mailto: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 have a very hard time explaining to my exec why we should be spending $$$ on DPDK 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 this 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<mailto:vincent.jardin@6wind.com>>
Sent: 28 October 2016 23:54:13
To: Thomas Monjalon; moving@dpdk.org<mailto: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<mailto:thomas.monjalon@6wind.com>> a
écrit :

> 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 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 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 the information in any medium. Thank you.


[-- Attachment #2: Type: text/html, Size: 31254 bytes --]

Re: [dpdk-moving] description of technical governance

[Michael Dolan]

[-- Attachment #1: Type: text/plain, Size: 17855 bytes --]

That makes a lot of sense Tim. I didn't realize (or forgot along the way)
that DPDK had this already.

---
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:56 PM, O'Driscoll, Tim <tim.odriscoll@intel.com>
wrote:

> We do have a Technical Board (effectively a TSC with a different name) for
> DPDK in place already (see http://dpdk.org/dev#board). We deliberately
> populated this board based on the most significant contributors to the
> project, and made sure that it was balanced so that no single company had a
> majority. Current composition is 2 members from Intel, 2 from 6WIND, 1 from
> Cavium, 1 from Red Hat and 1 from Microsoft.
>
>
>
> My proposal would be that we keep this board in place rather than create a
> new TSC. I do think we need to more clearly define the scope of the board
> and how people are added to/removed from it, but I don’t see a reason to
> change or replace it.
>
>
>
> Tim
>
>
>
> *From:* moving [mailto:moving-bounces@dpdk.org] *On Behalf Of *Michael
> Dolan
> *Sent:* Monday, October 31, 2016 4:52 PM
> *To:* Matt Spencer <Matt.Spencer@arm.com>
> *Cc:* moving@dpdk.org
>
> *Subject:* Re: [dpdk-moving] description of technical governance
>
>
>
> 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 how
> 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 members
> of the TSC, with DPDK as it stands today there would be about 56.  I am not
> sure that a leadership committee can work effectively at this size, so I
> 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 of
> contributors in a project. FD.io was setup with one initial project called
> VPP. In that case, it was 100% Cisco developers/engineers working on it.
> The 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 had
> setup FD.io with 1 project VPP and 100% Cisco maintainers... that's pretty
> 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 in
> FD.io can appoint a representative to the TSC, our TSC's also include the
> PTLs from the main projects.  I stated this in my long email, but to put it
> bluntly here - in my view, putting top tier members on a TSC is tool to use
> when you want to improve the corporate diversity of contribution. This is
> usually most beneficial in Projects that start with 1 company's codebase.
>
>
>
> Where we don't have a top tier membership appointing seats on a TSC, 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 coming
> 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 now?
>
>
>
> Regards
>
>
>
> Matt
> ------------------------------
>
> *From:* Michael Dolan <mdolan@linuxfoundation.org>
> *Sent:* 31 October 2016 16:07:03
> *To:* Matt Spencer
> *Cc:* Vincent Jardin; Thomas Monjalon; moving@dpdk.org
>
>
> *Subject:* Re: [dpdk-moving] description of technical governance
>
>
>
> 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" 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), 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 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 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. The
> 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 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
> members of the other projects we took funds from would not be happy to say
> the least.
>
>
>
> Third, when there is funding involved in a project, we typically setup a
> Governing Board that owns responsibility for how to spend the funding. The
> 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 funds are spent. Often some projects will
> 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 funds
> 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 per
> every X lower tier members). Typically the ratio is based on roughly what
> 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 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
> 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 for
> 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 guiding
> discussions about how LF Projects are structured and some of the rationale
> 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 have a
> very hard time explaining to my exec why we should be spending $$$ on DPDK
> 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 this
> 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.com>
> a
> écrit :
>
> > 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
> 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 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 the
> information in any medium. Thank you.
>
>
>

[-- Attachment #2: Type: text/html, Size: 31159 bytes --]

Re: [dpdk-moving] description of technical governance

[Jan Blunck]

On Mo, 2016-10-31 at 16:56 +0000, O'Driscoll, Tim wrote:
> We do have a Technical Board (effectively a TSC with a different
> name) for DPDK in place already (see http://dpdk.org/dev#board). We
> deliberately populated this board based on the most significant
> contributors to the project, and made sure that it was balanced so
> that no single company had a majority. Current composition is 2
> members from Intel, 2 from 6WIND, 1 from Cavium, 1 from Red Hat and 1
> from Microsoft.
>  
> My proposal would be that we keep this board in place rather than
> create a new TSC. I do think we need to more clearly define the scope
> of the board and how people are added to/removed from it, but I don’t
> see a reason to change or replace it.
> 

+1

Right now I do not see enough reason to replace the technical board. On
the other hand I do understand Matts point that for anyone not
attending DPDK Userspace Summit 2015 it is hard to understand how the
board was chosen. Therefore I believe it is necessary to define and
document a transparent process to mandate the technical board.

I don't think that mixing the governance of the financial and technical
aspects of the project is the right thing to do though. Especially the
technical architecture should not be defined by committee (technical
board) but through collaboration in-the-open (on the development
mailing list). This is a transparent process with low entrance
boundaries that is proven to work also for other projects than DPDK.

Thanks,
Jan

Re: [dpdk-moving] description of technical governance

[Vincent JARDIN]

Le 31/10/2016 à 19:31, Jan Blunck a écrit :
> This is a transparent process with low entrance
> boundaries that is proven to work also for other projects than DPDK.
+1

Re: [dpdk-moving] description of technical governance

[Jaswinder Singh]

[-- Attachment #1: Type: text/plain, Size: 10624 bytes --]

Hello All,

DPDK started with a Intel architecture specific project and is now aspiring for a *truly open architecture*
Large part of it still remains specific or optimized for IA or similar architectures.

In terms of Technical Governance-Model, following is what we think can benefit DPDK to be a *true open architecture*
NXP prefers the budget based model to support Project management and Test lab.

There could be 2 co-existential bodies –


a.   Technical Board -

a.   Consists of Assignee engineers from Paid-members; Non-paid members on merit basis (could be maintainers too).

b.   Ensure technical conflicts resolution.

c.    A elected Maintainer to be the lead for Technical Board (TB lead)


b.   Governance Board -

a.   Consist of Paid members like any other body like Realtime in LF.

b.   Approves/Maintains the Roadmap

c.    Manages the Budget to execute on the Roadmap.

d.   TB lead to be part of the Governance Board.

e.   Also there can be some invitee members, who may not have voting-rights in case of Conflicts but would like to pay/part of steering committee.


We believe a single step of moving to LF (with established governance model) will be better than doing it in multiple steps.

Thanks & Regards,
Jaswinder Singh
NXP, Digital Networking Group.



From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Michael Dolan
Sent: Monday, October 31, 2016 9:37 PM
To: Matt Spencer <Matt.Spencer@arm.com<mailto:Matt.Spencer@arm.com>>
Cc: moving@dpdk.org<mailto: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" 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), 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 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 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. The 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 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 members of the other projects we took funds from would not be happy to say the least.

Third, when there is funding involved in a project, we typically setup a Governing Board that owns responsibility for how to spend the funding. The 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 funds are spent. Often some projects will 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 funds 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 per every X lower tier members). Typically the ratio is based on roughly what 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 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 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 for 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 guiding discussions about how LF Projects are structured and some of the rationale 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<mailto:mdolan@linuxfoundation.org>
---

On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <Matt.Spencer@arm.com<mailto: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 have a very hard time explaining to my exec why we should be spending $$$ on DPDK 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 this 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<mailto:vincent.jardin@6wind.com>>
Sent: 28 October 2016 23:54:13
To: Thomas Monjalon; moving@dpdk.org<mailto: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<mailto:thomas.monjalon@6wind.com>> a
écrit :

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


[-- Attachment #2: Type: text/html, Size: 38442 bytes --]

Re: [dpdk-moving] description of technical governance

[O'Driscoll, Tim]

[-- Attachment #1: Type: text/plain, Size: 11142 bytes --]

Thanks Jaswinder. I was thinking along the same lines as this. I have a draft of a project charter for DPDK that covers some of these items. It’s almost ready and I plan to send it out later this morning. That should prompt further discussion on some of the topics that you’ve raised below.


Tim

From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Jaswinder Singh
Sent: Tuesday, November 8, 2016 8:12 AM
To: moving@dpdk.org
Subject: Re: [dpdk-moving] description of technical governance

Hello All,

DPDK started with a Intel architecture specific project and is now aspiring for a *truly open architecture*
Large part of it still remains specific or optimized for IA or similar architectures.

In terms of Technical Governance-Model, following is what we think can benefit DPDK to be a *true open architecture*
NXP prefers the budget based model to support Project management and Test lab.

There could be 2 co-existential bodies –


a.    Technical Board -

a.    Consists of Assignee engineers from Paid-members; Non-paid members on merit basis (could be maintainers too).

b.    Ensure technical conflicts resolution.

c.    A elected Maintainer to be the lead for Technical Board (TB lead)


b.    Governance Board -

a.    Consist of Paid members like any other body like Realtime in LF.

b.    Approves/Maintains the Roadmap

c.    Manages the Budget to execute on the Roadmap.

d.   TB lead to be part of the Governance Board.

e.    Also there can be some invitee members, who may not have voting-rights in case of Conflicts but would like to pay/part of steering committee.


We believe a single step of moving to LF (with established governance model) will be better than doing it in multiple steps.

Thanks & Regards,
Jaswinder Singh
NXP, Digital Networking Group.



From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Michael Dolan
Sent: Monday, October 31, 2016 9:37 PM
To: Matt Spencer <Matt.Spencer@arm.com<mailto:Matt.Spencer@arm.com>>
Cc: moving@dpdk.org<mailto: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" 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), 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 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 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. The 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 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 members of the other projects we took funds from would not be happy to say the least.

Third, when there is funding involved in a project, we typically setup a Governing Board that owns responsibility for how to spend the funding. The 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 funds are spent. Often some projects will 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 funds 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 per every X lower tier members). Typically the ratio is based on roughly what 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 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 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 for 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 guiding discussions about how LF Projects are structured and some of the rationale 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<mailto:mdolan@linuxfoundation.org>
---

On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <Matt.Spencer@arm.com<mailto: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 have a very hard time explaining to my exec why we should be spending $$$ on DPDK 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 this 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<mailto:vincent.jardin@6wind.com>>
Sent: 28 October 2016 23:54:13
To: Thomas Monjalon; moving@dpdk.org<mailto: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<mailto:thomas.monjalon@6wind.com>> a
écrit :

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


[-- Attachment #2: Type: text/html, Size: 28636 bytes --]

Re: [dpdk-moving] description of technical governance

[Thomas Monjalon]

Thanks to John McNamara, the contribution guide is now updated to give
more details about how sub-trees and maintainers work:
	http://dpdk.org/doc/guides/contributing/patches.html#maintainers-and-sub-trees
We could add a link here:
	http://dpdk.org/dev

We also need to define where the charter will be published.
I suggest a dedicated web page linked in the "About" page.

I think we need also to refresh the home page.


2016-10-26 10:21, O'Driscoll, Tim:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-10-25 11:27, O'Driscoll, Tim:
> > > We also have a gap in terms of documenting technical governance.
> > > Even ignoring the move to LF, Matt in particular was looking for
> > > more clarity on this.
> > > Thomas: would you be willing to create and post a proposal on this?
> > 
> > The technical governance is consensus-based.
> > The board was built in case a consensus is not found.
> > 
> > There are several projects with their own git trees.
> > DPDK and the web site are two of them.
> > 
> > The DPDK project is organized around some git subtrees
> > and the mainline gathers every contributions accepted in the subtrees.
> > The component maintainers are quality responsibles for the code and
> > the git history. They coordinate how improvements and fixes are done.
> > The git tree committers are responsibles of the pace, giving time for
> > reviews and tests while releasing in time. They also do the last checks
> > or call for help when there is no progress on a patch.
> > 
> > Is it the kind of information you are looking for?
> > I think the technical governance must be described on the web site
> > in the "development" page.
> > It is already partly described but it may requires more details and
> > updates.
> 
> Yes, it's the additional detail that I was asking about. If you look at what we have at the moment (http://dpdk.org/dev), it's quite brief. Other projects typically have more detail, for example:
> - FD.io Technical Community Charter: https://fd.io/governance/technical-community-charter
> - OvS technical governance including committer responsibilities and process for adding and removing committers: http://openvswitch.github.io/contributors/
> - ODL TSC Charter: https://www.opendaylight.org/tsc-charter
> 
> We don't necessarily need as much detail as they have, but I think we do need a bit more than we have at the moment. From a brief discussion with Mike Dolan during our previous engagement with the LF earlier in the year, the LF would simply be looking for DPDK technical governance to be properly documented, and for it to be meritocratic (e.g. committers chosen based on history of contributions rather than the company they work for).
> 
> Matt also had some thoughts during our discussion in Dublin on things he'd like to see added to the technical governance. Perhaps he can comment further on what he'd like to see.
> 
> In terms of where this is documented, I don't think that matters, and adding some additional detail to the existing Development page seems like a good solution to me.