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