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,
Brian
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?
-tl
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf
