comments in-lined, below.
On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...
Thanks for the thoughtful response.
- Pluggable consensus has been in active discussion in the Architecture working group. Unfortunately participation in such cross dlt architectural conversations has dropped, at least under the aegis of the AWG. We have had conversations of how to reboot the WGs and you should join the conversation.
We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.
I would agree with Shawn, here. There could be a bit more alignment, across projects but we do have plug-able consensus. However, I will remind people that code doesn't write itself, and no one ever shipped an architecture diagram/paper into production. Hyperledger is, all being said, an open source community. I would really love to see people diving in and working out the "how" and then rolling up sleeves to help drive the implementation of their thinking.
- There has been no support to bring "consistent technical principles". Working Groups and other cross-dlt areas where such work should take place are languishing and there are many actively campaigning against WGs. However this again has nothing to do with whether we should approve Besu or not.
The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.
Agree, no one is campaigning against WGs, per se. The discussion of WGs is more about making WGs *more relevant* to the projects so that the project contributors and maintainers might pay them more attention and participate, meaningfully to the benefit of the projects and the broader community.
- HL is unique in its sheltering of multiple DLT solutions, there is no comparable consortium and we are inventing the integrative concepts around such co-opetition. I am also an advocate of a full offering (integrating documentation, deployment, operational support, simple and intuitive UIs, adherence to regulation demonstrable with security audits, monitoring and self-healing), having had some experience importing dlt solutions into highly regulated enterprises.
To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.
- The arrival of new projects into Hyperledger, especially something backed by large networks who are new to Hyperledger will stimulate work in all areas. When there is competition, people will be forced to improve their offerings to stay relevant.
But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.
- In short, I am against holding Besu to a different standard than the existing platforms in Hyperledger. Let us be consistent. Getting new blood and new ideas into HL will make a difference in existing dlts as well. The new entrants may revive interest in cross-dlt efforts like the working groups and SIGs.
Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)
Agreed. I've been struggling with this. I think that there's positive benefit to bringing the Hyperledger and Ethereum communities closer together in the hopes that kumbayah. Though, I don't necessarily think that there will ever be one DLT to rule them all, and in the darkness bind them. What I DO think that Hyperledger needs to sort out is how it positions and promotes its projects. Right now, there is a considerable amount of overlap/redundancy, and it can be difficult at best to try to articulate to the general public how the projects are differentiated from one another. Further, during any project's life-cycle there's a great deal of effort expended to raise its voice above the din, to get people to kick the tires and maybe get more interested/invested.
I'm fine if Hyperledger is to become the Apache-for-Enterprise-Blockchain-and-DLTs, but note that Apache marketing is about promoting Apache and the Apache Way, not Hadoop, Kafka, Maven, Tomcat, or OpenWhisk.
Brian and Jessica have a difficult job, just as any parents with multiple offspring. Each child is special yet loved and nurtured equally. When someone asks a parent which child they love more, the correct response is "all of them". So, what should be the Hyperledger response when asked by press and analysts which of its projects is better, the correct answer needs to be "judge for yourself, we support them all equally". Yet, in this ultra-competitive landscape there is a natural tendency for press and analysts to look for differentiation, conflict and adoption to inform their audiences (and drive clicks). How do we enable the projects to make their case if they are promoted as equals?
Where am I going with all of this? I think we need to collectively (with the Board and Marketing) address the question that Shawn posed: "What is Hyperledger?". If Hyperledger is indeed to be a "greenhouse" or "umbrella" organization where open source blockchain/dlt for enterprise is developed - taking its cue from Apache. Then, I think we need to come to terms with two things:
1) what we want to be the "Hyperledger Way", and
2) how projects are marketed
I think there's much to be learned from the success of Apache and Eclipse, both of which are home to hundreds of projects, some overlapping/competing, some collaborative integrate-able components that fit a given framework. It could be just about creating a "safe place to innovate", as I like to say. It could be about encouraging growth of community(s) around projects. It could be about defining a single compose-able framework for DLTs shepherded by a collection of WGs that do top-down architecture overseen by the TSC.
However, whatever we choose, we then need to sort out how (or whether) we market the projects via Hyperledger or, allow the projects to manage their own messaging.