Re: Congratulations to the members of the 2019-2020 TSC!

Bob Summerwill <bob@...>

I wrote a blog post on diversity while I was standing for the TSC in 2018, which triggered some debate:

While I would agree that the high level of IBM affiliation on the 2019-2020 committee is less than ideal, I must take the opportunity to congratulate Tracy and Swetha both on standing for AND winning election to the TSC following years of 100% male candidates.

That is a big step in the right direction on diversity of representation in the TSC which should not be overlooked.   Bravo!

Bob Summerwill
Executive Director
Ethereum Classic Cooperative

On Fri., Sep. 6, 2019, 5:33 p.m. Brian Behlendorf, <bbehlendorf@...> wrote:
Hi Todd,

First, let me express congratulations to the newly elected TSC, particularly the new members who will bring fresh energy and perspectives to our conversations.  You are the heart of the technical credibility of this project, and I could not be happier to see it in such good hands.  (apologies for the delay, I've been traveling)

Todd: thank you for expression of concerns that no doubt are latent on other people's minds.  I am sure they are also on the minds of each of the TSC members, too.

We have been very careful at Hyperledger to separate out the sponsoring-member-consortium layer from the developer-driven product and technical layer.  The former is intended to run very much like any ordinary consortium would; the latter, like any well functioning open source project.  I may be projecting from my experience with Apache, and perhaps over-assuming that the following is obvious, but I always felt it's been clear that developers are expected to participate and contribute as individuals first, and as employees second.  For example:

* If a maintainer on a project, or a member of the TSC, changes employers, they do not lose their status; their "seat" is not conferred to someone else from the same employer, they keep it wherever they go. 

* If a developer is asked by their employer to submit code that the developer does not believe is the right thing to do, the developer should not submit that code.  In no case is "we were asked to do it this way" acceptable as a rationale for submitting or accepting a pull request or other technical decision, and they can ask us (HL staff) to delicately intervene if necessary.

* While we (Hyperledger staff) encourage companies to commit their developers to projects, and argue that they'll realize benefit from doing so, we constantly warn them that the public processes must rule the day; that project proposals, pull requests, even discussions will go whatever way the developer community decides it should, no matter how unfair or subject that may feel.  We also make it clear that a company's sponsoring membership in Hyperledger has no bearing on their technical contributions; and that conversely, non-member companies can realize the full benefit of using and contributing to Hyperledger projects.  We have several companies who contribute major amounts of code, and it's running code that usually dictates what happens (the do-ocracy).  Of course this swings both ways - it would be inappropriate for us to change the TSC election outcome because it didn't look the way we think it should.

Obviously, developers may feel pressure from their employers, and some will be able to push back but others won't feel so empowered.  The market for talent in this space is so hot, and the profile accrued to TSC members and project maintainers so high, that job security is likely not the overwhelming issue.  Others will act out of loyalty to their employers.  However, this community is capable of watching for, and calling out, behavior they feel might cross that line.  And we as HL staff have given feedback privately when we've seen that too.

By any metric, to date, IBM's technical contributions to Hyperledger have been substantial, and more than any other company.  They deserve credit for that.  Early on, that contribution level was so high that it led to public perception issues of "control", and a sense that technical decisions were being made on white boards and phone calls offline rather than online.  I won't speak for them, but it was made clear to us that IBM did not want that outcome - they brought Fabric to Hyperledger to get developer leverage, so that their headcount would be complemented by the efforts of many others.  And, they knew it was essential that Fabric not be a single-vendor product, but an industry movement.  So we worked with them on both the technical process issues, and the public perception issues, and I believe these are in the past.  They no longer are more than half the contributions into Fabric, as per Chris Ferris's numbers.  There are many other projects beyond Fabric in Hyperledger, and IBM has supported those, boosting Indy and Sawtooth and now even welcoming Besu.  Perhaps this is one reason the other electors felt comfortable voting for the IBM-employed candidates.

Now that every major public cloud provider offers a managed Fabric as a service, and those companies are now getting commercial traction, we expect those other companies to increase their investments into Fabric, entirely out of self-interest.  That will, no doubt, also increase the representation from those companies in the maintainer community in Fabric, into other Hyperledger projects, and in the next TSC election.

But all that said, there was talk about increasing the size of the TSC, to increase the prospect that more projects at Hyperledger will see one of their maintainers onboard, and to account for the growing developer community.  I think that would address both the perception of an issue here, and any actual attempt by a single vendor to exert "control" over their employees who become TSC members.  The new TSC can discuss this.  They could decide to ask the Governing Board to adjust the Hyperledger bylaws to increase the size of the TSC for the next election.  They could also ask the Governing Board to approve a one-time add of a set of new TSC members, so that this greater representation can happen in the current TSC term.  I think there are a lot of great reasons for either approach.

Again, I'm excited by the new TSC.  There's a lot of new hard work to do together!

Hope this helps,


On 9/6/19 3:04 PM, Todd Little wrote:
Hi TSC and Hyperledger in general,

While I don't doubt the results of the election, I do have to question whether this is the sort of outcome Hyperledger desires.  For projects to exit incubation they must exhibit diversity of contributions such that a project is not "controlled" by a single organization.  Why would the TSC find that TSC membership adheres to a lesser standard?  It is very clear that IBM now controls the TSC and is that the direction Hyperledger wants to take?


Brian Behlendorf
Executive Director, Hyperledger
Twitter: @brianbehlendorf

Join to automatically receive all group messages.