From my experience of the people elected, the TSC looks like a good TSC.
I think we should enlarge the TSC as a tactical manoeuvre (which may not work) to nudge Hyperledger towards a more project-diverse TSC.
The preponderance of IBM employees is a symptom of the dominance of Fabric in Hyperledger and the relative dominance of IBM in the Fabric project as other's have pointed out. One can only vote for those one knows and Fabric contributors are a highly connected subset of Hyperledger. The solution (he says blithely) is for other projects to become more relevant (to those inside and outside Hyperledger), attract more contributors, and then to apply more democracy. Which is to say I don't think medicating the imbalance of the TSC directly is probably the right way to go.
However it is not a given that the positive feedback above will happen on its own given the inertia associated with project adoption, public mindshare, etc. It is hard to know where the momentum is with Hyperledger in this respect but some small interventions now might pay dividends later.
It's worth questioning whether having greater project/company diversity on the TSC is even a Good Thing. It's not like IBM or Fabric people are a homogeneous block. However I would suggest:
- Diversity of ideas - I think the well rehearsed ideas about avoiding groupthink etc apply here. Different projects are exploring different parts of the space of distributed ledgers useful to have these ideas injected.
- Representation of projects - so long as Hyperledger is a multiple project umbrella it is useful to have representation on decision-making boards that affect projects. The TSC may not be a house of representatives but seems that function is there
- Politics - occasionally decisions come up that have more commercial/ideological significance (i.e. whether to accept a new project), this is where a balance of forces are important particularly amongst cooperating competitors
- Competence - it is difficult for people with no exposure to a project's code or design outside of surveying it in order to answer a question coming to the TSC to decide on finely balanced technical matters. Usually the right thing to do is for the TSC to defer to those with more context. But having people experienced with a greater range of projects means those people can help spread that context to other TSC members aided by an existing relationship with those other TSC members.
For my part I was planning to stick around the TSC meetings and list despite no longer being a member, the general prospect of which was noted by Mark and Arnaud on a previous call. However I would note that in the same way that getting elected to the TSC was a spur to apportion more of my time and effort to Hyperledger, losing the franchise does remove some of that impetus (although rather less since now I feel more involved) so even if TSC votes are rather consensual after discussions (as Arnaud noted) I would not discount the effect of the responsibility of being a bona fide TSC member as a human motivator to do more work.
Thinking about some of Todd's criticisms of the technical import of things discussed at the TSC. I would argue that things such as project lifecycle are relevant to the technical output of Hyperledger given software engineering is a team sport. I'd agree they are not deeply technical as defining a consensus interface or standardising on a choice of stream cipher might be. I too would like to see more deeply technical matters considered at the TSC, however I think the reason this is hard is the same as mentioned in the 'competence' bullet-point above. We generally need to be way more up inside each other's projects.
> There are well known techniques for this. We need to adopt them.
What are they?
> This is in addition to "who gets to participate in the election" which
should be "everyone that contributes technical artifacts to
Hyperledger"
How about a roll of credits stored as lines in a plain text file of the form `Date of contribution - nature of contribution` which could be stored in the repo and for which each commit adding a credit would need to be signed by a project maintainer or possibly existing contributor? This would put the definition of a contribution under the control of projects themselves.
Silas
