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 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 > *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 > 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 > *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 > 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 > *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 > 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 > *Sent:* 28 October 2016 23:54:13 > *To:* Thomas Monjalon; moving@dpdk.org; Matt Spencer > *Subject:* Re: [dpdk-moving] description of technical governance > > > > > > > Le 28 octobre 2016 9:22:43 PM Thomas Monjalon > a > é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. > > >