[dpdk-moving] description of technical governance

[Michael Dolan]

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 at linuxfoundation.org
---

On Mon, Oct 31, 2016 at 12:56 PM, O'Driscoll, Tim <tim.odriscoll at 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 at dpdk.org] *On Behalf Of *Michael
> Dolan
> *Sent:* Monday, October 31, 2016 4:52 PM
> *To:* Matt Spencer <Matt.Spencer at arm.com>
> *Cc:* moving at 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 at linuxfoundation.org
> ---
>
>
>
> On Mon, Oct 31, 2016 at 12:43 PM, Matt Spencer <Matt.Spencer at 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 at linuxfoundation.org>
> *Sent:* 31 October 2016 16:33:52
>
>
> *To:* Matt Spencer
> *Cc:* Vincent Jardin; Thomas Monjalon; moving at 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 at linuxfoundation.org
> ---
>
>
>
> On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer <Matt.Spencer at 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 at linuxfoundation.org>
> *Sent:* 31 October 2016 16:07:03
> *To:* Matt Spencer
> *Cc:* Vincent Jardin; Thomas Monjalon; moving at 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 at linuxfoundation.org
> ---
>
>
>
> On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <Matt.Spencer at 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 at 6wind.com>
> *Sent:* 28 October 2016 23:54:13
> *To:* Thomas Monjalon; moving at dpdk.org; Matt Spencer
> *Subject:* Re: [dpdk-moving] description of technical governance
>
>
>
>
>
>
> Le 28 octobre 2016 9:22:43 PM Thomas Monjalon <thomas.monjalon at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dpdk.org/ml/archives/moving/attachments/20161031/f8ca4b48/attachment-0001.html>