Hyperledger Besu Proposal is Live


Jon Geater
 

Thanks Vipin, that does bring some clear points to draw the discussion around.  However if you consider the parallel thread about architecture it’s quite possible to see these virtues as vices.

If we want to have pluggable consensus, widespread proper use of Ursa and all those other great things that adoption of the Hyperledger code bases promises then at some point we need to have architectural constraints and adherence throughout all the frameworks and projects.  Early on, the more overlapping co-opetitive projects we add the better: competition drives quality and features and ideas.  But as time goes on and numbers grow it can lead to fragmentation, redundant work, and lower overall progress.  Especially if (as is almost inevitable with multiple projects with different provenance) they have a different idea of where architectural layers should be drawn and where the functional responsibilities of major objects lie.  That’s the path to adapters, proxies and so on, which is in turn a path to potential problems.

I’ve worked at the leading edge of large technology ecosystems for a long time now and something that constantly comes up is that there is ‘good differentiation’, where different offerings provide stability and choice to consumers while competing on niche or value-add offers; and ‘bad differentiation’, where suppliers compromise consumer choice by insisting on being different in layers that should be standardised and enabling.  This is not just about standardizing APIs or protocols: it’s also all around the peripheral stuff: keeping documentation up to date; learning and deploying management systems and administrative functionality; differences in system design assumptions that lead to subtle operational problems; differences in cryptographic design assumptions that lead to subtle security problems; etc.  

I don’t want to seem negative, either towards new proposals in general, or Besu in particular. But to address your first bullet, when you have a mission and a stable of existing projects, ‘technical merit’ is not an absolute, objective, or independent measure.  It’s absolutely right that we discuss the technical fit and feature overlap of new projects with old, including the ‘gymnastic’ aspects, because it might be (as others have noted) that we _should_ accept the new thing but should then also guide older things in different directions so as not to ride too many horses in the same race.

We’re discussing TCF next week.  I won’t write much about that here because it’s such a huge (different) topic.  But imagine trying to write a proper threat analysis or system composition or whatever if everylayer of every one of those stacks had differently opinionated versions of the same concepts.  It would make a great Ph.D. thesis but it won’t catch on.

Again, not against Besu at all.  The mature, stable, battle-hardened aspects you mention are great strengths, we need those.  All I’m trying to say is that we can’t make these decisions in isolation and as Hyperledger we do need to judge proposals against consistent technical principles across all the projects and frameworks, otherwise we’re not a community and force multiplier, we’re just a giant repo.  Whatever the decisions made it wouldn’t be great to see that rationale and the external effects reflected.

Regards

Jon

Jon Geater
Chief Technology Officer, Jitsuin
+44 7500 786537


VIPIN BHARATHAN
 

Hi Jon,
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.
  • 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.
  • 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. 
  • The comparison of public and private consensus algorithms is interesting and I do agree with many of RGBs points. However for large networks, BFT solutions that support liveness and safety at scale (i.e. where there is a linear  or log not quadratic or higher order relation to N) should be adopted. But what does this have to do with Besu? The fact that it will offer a link between private and public dlts could lead to emergent effects, which none of us can predict at this point.
  • 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.
  • Ursa adoption in Ethereum is being worked on, Virgil has been leading this effort and hopefully Besu will join this effort.
  • 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. 
Best,
Vipin

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant
vip@...


From: tsc@... <tsc@...> on behalf of Jon Geater via Lists.Hyperledger.Org <jon.geater=jitsuin.com@...>
Sent: Sunday, August 25, 2019 10:56 AM
To: vipinsun@... <vipinsun@...>; Silas Davis <silas@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
 
Thanks Vipin, that does bring some clear points to draw the discussion around.  However if you consider the parallel thread about architecture it’s quite possible to see these virtues as vices.

If we want to have pluggable consensus, widespread proper use of Ursa and all those other great things that adoption of the Hyperledger code bases promises then at some point we need to have architectural constraints and adherence throughout all the frameworks and projects.  Early on, the more overlapping co-opetitive projects we add the better: competition drives quality and features and ideas.  But as time goes on and numbers grow it can lead to fragmentation, redundant work, and lower overall progress.  Especially if (as is almost inevitable with multiple projects with different provenance) they have a different idea of where architectural layers should be drawn and where the functional responsibilities of major objects lie.  That’s the path to adapters, proxies and so on, which is in turn a path to potential problems.

I’ve worked at the leading edge of large technology ecosystems for a long time now and something that constantly comes up is that there is ‘good differentiation’, where different offerings provide stability and choice to consumers while competing on niche or value-add offers; and ‘bad differentiation’, where suppliers compromise consumer choice by insisting on being different in layers that should be standardised and enabling.  This is not just about standardizing APIs or protocols: it’s also all around the peripheral stuff: keeping documentation up to date; learning and deploying management systems and administrative functionality; differences in system design assumptions that lead to subtle operational problems; differences in cryptographic design assumptions that lead to subtle security problems; etc.  

I don’t want to seem negative, either towards new proposals in general, or Besu in particular. But to address your first bullet, when you have a mission and a stable of existing projects, ‘technical merit’ is not an absolute, objective, or independent measure.  It’s absolutely right that we discuss the technical fit and feature overlap of new projects with old, including the ‘gymnastic’ aspects, because it might be (as others have noted) that we _should_ accept the new thing but should then also guide older things in different directions so as not to ride too many horses in the same race.

We’re discussing TCF next week.  I won’t write much about that here because it’s such a huge (different) topic.  But imagine trying to write a proper threat analysis or system composition or whatever if everylayer of every one of those stacks had differently opinionated versions of the same concepts.  It would make a great Ph.D. thesis but it won’t catch on.

Again, not against Besu at all.  The mature, stable, battle-hardened aspects you mention are great strengths, we need those.  All I’m trying to say is that we can’t make these decisions in isolation and as Hyperledger we do need to judge proposals against consistent technical principles across all the projects and frameworks, otherwise we’re not a community and force multiplier, we’re just a giant repo.  Whatever the decisions made it wouldn’t be great to see that rationale and the external effects reflected.

Regards

Jon

Jon Geater
Chief Technology Officer, Jitsuin
+44 7500 786537


Shawn Amundson
 

On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.
  • 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.
  • 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. :)

-Shawn


Virgil Griffith <virgil@...>
 

> Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)

Sounds reasonable.  Besu has some valuable things to contribute to the Hyperledger ecosystem, but probably the more salient is encouraging the larger sharing between the Ethereum and Hyperledger worlds even outside of Besu.  I see several natural points of contact between Hyperledger and Besu + the larger Ethereum ecosystem:

(1) I can commit to getting Ursa used in as many Ethereum-related projects as possible.  Right now that's not easy because there's no direct way to compile Rust to EVM.  But after Ethereum moves to WebAssembly, this will become possible.  But I will push for this.

(2) It's plausible that Ethereum could contribute to Hyperledger Explorer.  We currently have several opensource blockchain explorers, such as:

I'm not on these block explorer teams, but given the overlap it seems plausible there's some common components so there's less duplicated work in both camps.

(3) It's plausible that Besu and other Ethereum clients (geth, parity, etc) can start contributing to the Caliper tool for improving performance of Ethereum clients.  This also seems a natural point of collaboration.

-Virgil


On Tue, Aug 27, 2019 at 14:11:08, Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@dlt.nyc> wrote:
Hi Jon,
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.
  • 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.
  • 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. :)

-Shawn


Christopher Ferris <chris.ferris@...>
 

comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.


-Shawn


Mic Bowman
 

can i suggest that the working group comments be moved to the page where we are trying to capture all of these discussions? the role of wg's is really not relevant to the besu proposal discussion.


--mic


On Tue, Aug 27, 2019 at 6:14 AM Christopher Ferris <chris.ferris@...> wrote:
comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.


-Shawn


Christopher Ferris <chrisfer@...>
 

I linked to this thread... easier than cutting and pasting different comments.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 

----- Original message -----
From: "Mic Bowman" <cmickeyb@...>
Sent by: tsc@...
To: Christopher Ferris <chris.ferris@...>
Cc: Shawn Amundson <amundson@...>, VIPIN BHARATHAN <vip@...>, "vipinsun@..." <vipinsun@...>, Silas Davis <silas@...>, "jon.geater@..." <jon.geater@...>, "tsc@..." <tsc@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
Date: Tue, Aug 27, 2019 12:31 PM
 
can i suggest that the working group comments be moved to the page where we are trying to capture all of these discussions? the role of wg's is really not relevant to the besu proposal discussion.
 
 
--mic
 
 
On Tue, Aug 27, 2019 at 6:14 AM Christopher Ferris <chris.ferris@...> wrote:
comments in-lined, below.
 
On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.
 
 
 
-Shawn

 

 

 

 

 


Arnaud Le Hors
 

Hi all,

I find myself largely in agreement with the sentiment expressed by Shawn and Chris. I find it rather unfortunate that attempts to understand how Besu will fit in and what its addition means to be interpreted as a vote against it. I think it is the TSC's job to take a serious look at every proposal and understand what the implications are. These shouldn't necessarily be seen as a pushback as much as an interest in looking after the well being of Hyperledger.

It has been said that we are making new rules as we go and I think that's a fair point but I for one don't think that's really by choice nor a bad thing. Hyperledger is still a very young organization and it should be expected that it goes through some transformation as it grows. Our charter states that our missing is to "create an enterprise grade, open source distributed ledger framework and code base" [1]. So, as a matter of fact, we've literally been making new rules all along since we accepted developing in parallel more than one dlt. Why should anyone be then surprised we keep doing so?

Anyway, I trust that with time we will get our act together. I understand the board is looking into updating our charter, which seems to be a good start. What's important to me, in line with what Chris stated and what I put in my TSC nomination pitch, is that we do a better job at documenting how the different projects compare and relate to one another, so that people in the community out there no longer get utterly confused when they come to our website in search for where to start they journey.

Cheers.

[1] https://www.hyperledger.org/about/charter
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chris.ferris@...>
To:        Shawn Amundson <amundson@...>
Cc:        VIPIN BHARATHAN <vip@...>, "vipinsun@..." <vipinsun@...>, Silas Davis <silas@...>, "jon.geater@..." <jon.geater@...>, "tsc@..." <tsc@...>
Date:        08/27/2019 03:14 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
Sent by:        tsc@...




comments in-lined, below.


On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.


-Shawn




Jonathan Levi (HACERA)
 

Hi everybody,

While I am obviously in support of this proposal, being the first sponsor in the list after Consensys, I have had a LOT of conversations about this "move" and I hope tgat today Goes Well * (defined below).

Personally, I started to help, code and build one of the best Permissioned Blockchain framework (Fabric) AFTER working on Ethereum in 2015 and Bitcoin years before that. At first, I received a lot of criticism from some in the Ethereum community, while I kept on helping Ethereum, with advise, participating (and winning) in some impactful hackathons (Interoperability, Sharing, Confidentiality, Scaling) and help judge in many others. So I am glad that ConsenSys invested in a permissioned version (in addition to the amazing work that the Quorum team is constantly delivering).

Professionally, I would really like the TSC to think about "where do we go from here". 

I’m joining the disagreement with Vipin, I didn’t like the tone nor the accusations/blaming that people are not judging this proposal technically, or that people hold Besu to a different standard. I also don't think that this  is "diverse" as the project and code is provided by a single vendor (right now). Last, it is not clear at this point that this will get Hyperledger close to the EEA, as the EEA is set on supporting Quorum. With the specification effort (version 4 will be released during Ethereum DevCon 5), and they are welcoming other implementations, but to jump and declare "success" just by having one more project in Hyperledger, does not make us all friends. I am looking for a much more collaboration than competition here.

---- 

I raised the question of whether we would like all projects to fit well in Hyperledger and we have a lot of discussions around "who is going to do all this or that". Shawn and Chris addressed it, as indeed "the code won't write itself", and I agree with Arnaud, we are young and have to continue redefine and adapt.

I would like to quicky define what I mean by hoping that the vote today "Goes Well". I think we made a big mistake to not prevent the in-fighting in Hyperledger. Fabric was an investment of many many man years, and without breaching too many NDAs, it was worth many 100s of millions of dollars, especially in 2017.

How did we get there? TOGETHER.

In 2016 we had R3 who worked night and day so close to banking and the financial sector who kept on feeding us with super valuable feedback, Digital Asset - constantly provided us with requirements and I will never forget how much Intel (Mic B and others) set down with the Fabric team and literally worked out with the Fabric leading maintainers some major issues that we missed at the time with the genesis block with channels.

In 2018, we have lost a.lot of market momentum due to all these fights over Grid, over the pluggable consensus (I would have LOVED) to have PoET in Fabric, which I believe would have helped Intel a lot, given the fact that we already have 7 cloud providers who invested so much in having Fabric support. I think the fights and fragmentation is not helpful and a lot of innovation in 2018 is happening elsewhere.

Trying to remedy and bridge, HACERA and IBM have representatives (soon to be maintainers, more likely) of Hyperledger Transact, so that we can bridge the Fabric-Sawtooth gap when it comes to contracts and I would have loved it if Sabres (the WASM work) will be reusable outside Sawtooth, and HACERA can probably help with it this year.

-----

What am I asking? I want people to be very honest with their vote. If we don't want to work with Ethereum, Pantheon or Besu - just say so and let's move on.

But if we do, or are willing to try, then let's welcome their code and their team, and work out what we can do together. Again: TOGETHER ;-)

And Richard G. Brown - of course your participation in any of these discussions is highly welcome. It is a shame that we meet in other events, but please do chime in.

Thanks again everyone.

Jonathan Levi




On Tue, Aug 27, 2019, 10:00 AM Arnaud Le Hors <lehors@...> wrote:
Hi all,

I find myself largely in agreement with the sentiment expressed by Shawn and Chris. I find it rather unfortunate that attempts to understand how Besu will fit in and what its addition means to be interpreted as a vote against it. I think it is the TSC's job to take a serious look at every proposal and understand what the implications are. These shouldn't necessarily be seen as a pushback as much as an interest in looking after the well being of Hyperledger.

It has been said that we are making new rules as we go and I think that's a fair point but I for one don't think that's really by choice nor a bad thing. Hyperledger is still a very young organization and it should be expected that it goes through some transformation as it grows. Our charter states that our missing is to "create an enterprise grade, open source distributed ledger framework and code base" [1]. So, as a matter of fact, we've literally been making new rules all along since we accepted developing in parallel more than one dlt. Why should anyone be then surprised we keep doing so?

Anyway, I trust that with time we will get our act together. I understand the board is looking into updating our charter, which seems to be a good start. What's important to me, in line with what Chris stated and what I put in my TSC nomination pitch, is that we do a better job at documenting how the different projects compare and relate to one another, so that people in the community out there no longer get utterly confused when they come to our website in search for where to start they journey.

Cheers.

[1] https://www.hyperledger.org/about/charter
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chris.ferris@...>
To:        Shawn Amundson <amundson@...>
Cc:        VIPIN BHARATHAN <vip@...>, "vipinsun@..." <vipinsun@...>, Silas Davis <silas@...>, "jon.geater@..." <jon.geater@...>, "tsc@..." <tsc@...>
Date:        08/27/2019 03:14 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
Sent by:        tsc@...




comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.


-Shawn




Jonathan Levi
 

... "It is ashame that we meet [ONLY] in other events, no the Hyperledger ones anymore", I meant.

(Typing from and old and dusty mobile)

On Thu, Aug 29, 2019 at 7:26 AM, Jonathan Levi (HACERA)
<jonathan@...> wrote:
Hi everybody,

While I am obviously in support of this proposal, being the first sponsor in the list after Consensys, I have had a LOT of conversations about this "move" and I hope tgat today Goes Well * (defined below).

Personally, I started to help, code and build one of the best Permissioned Blockchain framework (Fabric) AFTER working on Ethereum in 2015 and Bitcoin years before that. At first, I received a lot of criticism from some in the Ethereum community, while I kept on helping Ethereum, with advise, participating (and winning) in some impactful hackathons (Interoperability, Sharing, Confidentiality, Scaling) and help judge in many others. So I am glad that ConsenSys invested in a permissioned version (in addition to the amazing work that the Quorum team is constantly delivering).

Professionally, I would really like the TSC to think about "where do we go from here". 

I’m joining the disagreement with Vipin, I didn’t like the tone nor the accusations/blaming that people are not judging this proposal technically, or that people hold Besu to a different standard. I also don't think that this  is "diverse" as the project and code is provided by a single vendor (right now). Last, it is not clear at this point that this will get Hyperledger close to the EEA, as the EEA is set on supporting Quorum. With the specification effort (version 4 will be released during Ethereum DevCon 5), and they are welcoming other implementations, but to jump and declare "success" just by having one more project in Hyperledger, does not make us all friends. I am looking for a much more collaboration than competition here.

---- 

I raised the question of whether we would like all projects to fit well in Hyperledger and we have a lot of discussions around "who is going to do all this or that". Shawn and Chris addressed it, as indeed "the code won't write itself", and I agree with Arnaud, we are young and have to continue redefine and adapt.

I would like to quicky define what I mean by hoping that the vote today "Goes Well". I think we made a big mistake to not prevent the in-fighting in Hyperledger. Fabric was an investment of many many man years, and without breaching too many NDAs, it was worth many 100s of millions of dollars, especially in 2017.

How did we get there? TOGETHER.

In 2016 we had R3 who worked night and day so close to banking and the financial sector who kept on feeding us with super valuable feedback, Digital Asset - constantly provided us with requirements and I will never forget how much Intel (Mic B and others) set down with the Fabric team and literally worked out with the Fabric leading maintainers some major issues that we missed at the time with the genesis block with channels.

In 2018, we have lost a.lot of market momentum due to all these fights over Grid, over the pluggable consensus (I would have LOVED) to have PoET in Fabric, which I believe would have helped Intel a lot, given the fact that we already have 7 cloud providers who invested so much in having Fabric support. I think the fights and fragmentation is not helpful and a lot of innovation in 2018 is happening elsewhere.

Trying to remedy and bridge, HACERA and IBM have representatives (soon to be maintainers, more likely) of Hyperledger Transact, so that we can bridge the Fabric-Sawtooth gap when it comes to contracts and I would have loved it if Sabres (the WASM work) will be reusable outside Sawtooth, and HACERA can probably help with it this year.

-----

What am I asking? I want people to be very honest with their vote. If we don't want to work with Ethereum, Pantheon or Besu - just say so and let's move on.

But if we do, or are willing to try, then let's welcome their code and their team, and work out what we can do together. Again: TOGETHER ;-)

And Richard G. Brown - of course your participation in any of these discussions is highly welcome. It is a shame that we meet in other events, but please do chime in.

Thanks again everyone.

Jonathan Levi




On Tue, Aug 27, 2019, 10:00 AM Arnaud Le Hors <lehors@...> wrote:
Hi all,

I find myself largely in agreement with the sentiment expressed by Shawn and Chris. I find it rather unfortunate that attempts to understand how Besu will fit in and what its addition means to be interpreted as a vote against it. I think it is the TSC's job to take a serious look at every proposal and understand what the implications are. These shouldn't necessarily be seen as a pushback as much as an interest in looking after the well being of Hyperledger.

It has been said that we are making new rules as we go and I think that's a fair point but I for one don't think that's really by choice nor a bad thing. Hyperledger is still a very young organization and it should be expected that it goes through some transformation as it grows. Our charter states that our missing is to "create an enterprise grade, open source distributed ledger framework and code base" [1]. So, as a matter of fact, we've literally been making new rules all along since we accepted developing in parallel more than one dlt. Why should anyone be then surprised we keep doing so?

Anyway, I trust that with time we will get our act together. I understand the board is looking into updating our charter, which seems to be a good start. What's important to me, in line with what Chris stated and what I put in my TSC nomination pitch, is that we do a better job at documenting how the different projects compare and relate to one another, so that people in the community out there no longer get utterly confused when they come to our website in search for where to start they journey.

Cheers.

[1] https://www.hyperledger.org/about/charter
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chris.ferris@...>
To:        Shawn Amundson <amundson@...>
Cc:        VIPIN BHARATHAN <vip@...>, "vipinsun@..." <vipinsun@...>, Silas Davis <silas@...>, "jon.geater@..." <jon.geater@...>, "tsc@..." <tsc@...>
Date:        08/27/2019 03:14 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
Sent by:        tsc@...




comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.


-Shawn




Richard G Brown (R3) <richard@...>
 

Jonathan, Silas, all,

 

Thanks for your thoughtful comments to my post.  Sorry for the (very) slow reply – I was on holiday.

 

I know the immediate forcing function (the Besu approval discussion) has passed but I do remain interested in the permissioned/permissionless integration discussion.  But perhaps the approach in my original email, where I tried to intuit legitimate use-cases from first principles, was the wrong approach – maybe we just need to observe what people actually do,  what happens and what works. I think it might have been Vipin who rightly called me out over this.   Anyway - I don’t want to beat a dead horse so I’ll step back from this for now in this forum whilst the hard work of bringing the new code base and identifying synergies with the other projects, etc., kicks off.

 

Cheers,

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

2 London Wall Place | Floor 12 | London | EC2Y 5AU

M: +44 7764 666821 | T: @gendal

richard@... . www.r3.com

 

From: Jonathan Levi <jonathan@...>
Reply to: "jonathan@..." <jonathan@...>
Date: Thursday, 29 August 2019 at 15:43
To: "jonathan@..." <jonathan@...>, Arnaud Le Hors <lehors@...>, Richard Brown <richard@...>, Christopher B Ferris <chrisfer@...>, Gari Singh <gari.r.singh@...>
Cc: Jonathan Levi <jonathan@...>, Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live

 

... "It is ashame that we meet [ONLY] in other events, no the Hyperledger ones anymore", I meant.

 

(Typing from and old and dusty mobile)

 

On Thu, Aug 29, 2019 at 7:26 AM, Jonathan Levi (HACERA)

<jonathan@...> wrote:

Hi everybody,

 

While I am obviously in support of this proposal, being the first sponsor in the list after Consensys, I have had a LOT of conversations about this "move" and I hope tgat today Goes Well * (defined below).

 

Personally, I started to help, code and build one of the best Permissioned Blockchain framework (Fabric) AFTER working on Ethereum in 2015 and Bitcoin years before that. At first, I received a lot of criticism from some in the Ethereum community, while I kept on helping Ethereum, with advise, participating (and winning) in some impactful hackathons (Interoperability, Sharing, Confidentiality, Scaling) and help judge in many others. So I am glad that ConsenSys invested in a permissioned version (in addition to the amazing work that the Quorum team is constantly delivering).

 

Professionally, I would really like the TSC to think about "where do we go from here". 

 

I’m joining the disagreement with Vipin, I didn’t like the tone nor the accusations/blaming that people are not judging this proposal technically, or that people hold Besu to a different standard. I also don't think that this  is "diverse" as the project and code is provided by a single vendor (right now). Last, it is not clear at this point that this will get Hyperledger close to the EEA, as the EEA is set on supporting Quorum. With the specification effort (version 4 will be released during Ethereum DevCon 5), and they are welcoming other implementations, but to jump and declare "success" just by having one more project in Hyperledger, does not make us all friends. I am looking for a much more collaboration than competition here.

 

---- 

 

I raised the question of whether we would like all projects to fit well in Hyperledger and we have a lot of discussions around "who is going to do all this or that". Shawn and Chris addressed it, as indeed "the code won't write itself", and I agree with Arnaud, we are young and have to continue redefine and adapt.

 

I would like to quicky define what I mean by hoping that the vote today "Goes Well". I think we made a big mistake to not prevent the in-fighting in Hyperledger. Fabric was an investment of many many man years, and without breaching too many NDAs, it was worth many 100s of millions of dollars, especially in 2017.

 

How did we get there? TOGETHER.

 

In 2016 we had R3 who worked night and day so close to banking and the financial sector who kept on feeding us with super valuable feedback, Digital Asset - constantly provided us with requirements and I will never forget how much Intel (Mic B and others) set down with the Fabric team and literally worked out with the Fabric leading maintainers some major issues that we missed at the time with the genesis block with channels.

 

In 2018, we have lost a.lot of market momentum due to all these fights over Grid, over the pluggable consensus (I would have LOVED) to have PoET in Fabric, which I believe would have helped Intel a lot, given the fact that we already have 7 cloud providers who invested so much in having Fabric support. I think the fights and fragmentation is not helpful and a lot of innovation in 2018 is happening elsewhere.

 

Trying to remedy and bridge, HACERA and IBM have representatives (soon to be maintainers, more likely) of Hyperledger Transact, so that we can bridge the Fabric-Sawtooth gap when it comes to contracts and I would have loved it if Sabres (the WASM work) will be reusable outside Sawtooth, and HACERA can probably help with it this year.

 

-----

 

What am I asking? I want people to be very honest with their vote. If we don't want to work with Ethereum, Pantheon or Besu - just say so and let's move on.

 

But if we do, or are willing to try, then let's welcome their code and their team, and work out what we can do together. Again: TOGETHER ;-)

 

And Richard G. Brown - of course your participation in any of these discussions is highly welcome. It is a shame that we meet in other events, but please do chime in.

 

Thanks again everyone.

 

Jonathan Levi

 

 

 

 

On Tue, Aug 27, 2019, 10:00 AM Arnaud Le Hors <lehors@...> wrote:

Hi all,

I find myself largely in agreement with the sentiment expressed by Shawn and Chris. I find it rather unfortunate that attempts to understand how Besu will fit in and what its addition means to be interpreted as a vote against it. I think it is the TSC's job to take a serious look at every proposal and understand what the implications are. These shouldn't necessarily be seen as a pushback as much as an interest in looking after the well being of Hyperledger.

It has been said that we are making new rules as we go and I think that's a fair point but I for one don't think that's really by choice nor a bad thing. Hyperledger is still a very young organization and it should be expected that it goes through some transformation as it grows. Our charter states that our missing is to "create an enterprise grade, open source distributed ledger framework and code base" [1]. So, as a matter of fact, we've literally been making new rules all along since we accepted developing in parallel more than one dlt. Why should anyone be then surprised we keep doing so?

Anyway, I trust that with time we will get our act together. I understand the board is looking into updating our charter, which seems to be a good start. What's important to me, in line with what Chris stated and what I put in my TSC nomination pitch, is that we do a better job at documenting how the different projects compare and relate to one another, so that people in the community out there no longer get utterly confused when they come to our website in search for where to start they journey.

Cheers.

[1] https://www.hyperledger.org/about/charter
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chris.ferris@...>
To:        Shawn Amundson <amundson@...>
Cc:        VIPIN BHARATHAN <vip@...>, "vipinsun@..." <vipinsun@...>, Silas Davis <silas@...>, "jon.geater@..." <jon.geater@...>, "tsc@..." <tsc@...>
Date:        08/27/2019 03:14 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
Sent by:        tsc@...





comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.


-Shawn



Mohan Venkataraman
 

Quite excited to see Besu live. We would be quite interested in following the progress and actively participating in its evolution.

Mohan Venkataraman 
Chainyard



On Fri, Sep 6, 2019, 8:55 AM Richard G Brown (R3) via Lists.Hyperledger.Org <richard=r3.com@...> wrote:

Jonathan, Silas, all,

 

Thanks for your thoughtful comments to my post.  Sorry for the (very) slow reply – I was on holiday.

 

I know the immediate forcing function (the Besu approval discussion) has passed but I do remain interested in the permissioned/permissionless integration discussion.  But perhaps the approach in my original email, where I tried to intuit legitimate use-cases from first principles, was the wrong approach – maybe we just need to observe what people actually do,  what happens and what works. I think it might have been Vipin who rightly called me out over this.   Anyway - I don’t want to beat a dead horse so I’ll step back from this for now in this forum whilst the hard work of bringing the new code base and identifying synergies with the other projects, etc., kicks off.

 

Cheers,

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

2 London Wall Place | Floor 12 | London | EC2Y 5AU

M: +44 7764 666821 | T: @gendal

richard@... . www.r3.com

 

From: Jonathan Levi <jonathan@...>
Reply to: "jonathan@..." <jonathan@...>
Date: Thursday, 29 August 2019 at 15:43
To: "jonathan@..." <jonathan@...>, Arnaud Le Hors <lehors@...>, Richard Brown <richard@...>, Christopher B Ferris <chrisfer@...>, Gari Singh <gari.r.singh@...>
Cc: Jonathan Levi <jonathan@...>, Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live

 

... "It is ashame that we meet [ONLY] in other events, no the Hyperledger ones anymore", I meant.

 

(Typing from and old and dusty mobile)

 

On Thu, Aug 29, 2019 at 7:26 AM, Jonathan Levi (HACERA)

<jonathan@...> wrote:

Hi everybody,

 

While I am obviously in support of this proposal, being the first sponsor in the list after Consensys, I have had a LOT of conversations about this "move" and I hope tgat today Goes Well * (defined below).

 

Personally, I started to help, code and build one of the best Permissioned Blockchain framework (Fabric) AFTER working on Ethereum in 2015 and Bitcoin years before that. At first, I received a lot of criticism from some in the Ethereum community, while I kept on helping Ethereum, with advise, participating (and winning) in some impactful hackathons (Interoperability, Sharing, Confidentiality, Scaling) and help judge in many others. So I am glad that ConsenSys invested in a permissioned version (in addition to the amazing work that the Quorum team is constantly delivering).

 

Professionally, I would really like the TSC to think about "where do we go from here". 

 

I’m joining the disagreement with Vipin, I didn’t like the tone nor the accusations/blaming that people are not judging this proposal technically, or that people hold Besu to a different standard. I also don't think that this  is "diverse" as the project and code is provided by a single vendor (right now). Last, it is not clear at this point that this will get Hyperledger close to the EEA, as the EEA is set on supporting Quorum. With the specification effort (version 4 will be released during Ethereum DevCon 5), and they are welcoming other implementations, but to jump and declare "success" just by having one more project in Hyperledger, does not make us all friends. I am looking for a much more collaboration than competition here.

 

---- 

 

I raised the question of whether we would like all projects to fit well in Hyperledger and we have a lot of discussions around "who is going to do all this or that". Shawn and Chris addressed it, as indeed "the code won't write itself", and I agree with Arnaud, we are young and have to continue redefine and adapt.

 

I would like to quicky define what I mean by hoping that the vote today "Goes Well". I think we made a big mistake to not prevent the in-fighting in Hyperledger. Fabric was an investment of many many man years, and without breaching too many NDAs, it was worth many 100s of millions of dollars, especially in 2017.

 

How did we get there? TOGETHER.

 

In 2016 we had R3 who worked night and day so close to banking and the financial sector who kept on feeding us with super valuable feedback, Digital Asset - constantly provided us with requirements and I will never forget how much Intel (Mic B and others) set down with the Fabric team and literally worked out with the Fabric leading maintainers some major issues that we missed at the time with the genesis block with channels.

 

In 2018, we have lost a.lot of market momentum due to all these fights over Grid, over the pluggable consensus (I would have LOVED) to have PoET in Fabric, which I believe would have helped Intel a lot, given the fact that we already have 7 cloud providers who invested so much in having Fabric support. I think the fights and fragmentation is not helpful and a lot of innovation in 2018 is happening elsewhere.

 

Trying to remedy and bridge, HACERA and IBM have representatives (soon to be maintainers, more likely) of Hyperledger Transact, so that we can bridge the Fabric-Sawtooth gap when it comes to contracts and I would have loved it if Sabres (the WASM work) will be reusable outside Sawtooth, and HACERA can probably help with it this year.

 

-----

 

What am I asking? I want people to be very honest with their vote. If we don't want to work with Ethereum, Pantheon or Besu - just say so and let's move on.

 

But if we do, or are willing to try, then let's welcome their code and their team, and work out what we can do together. Again: TOGETHER ;-)

 

And Richard G. Brown - of course your participation in any of these discussions is highly welcome. It is a shame that we meet in other events, but please do chime in.

 

Thanks again everyone.

 

Jonathan Levi

 

 

 

 

On Tue, Aug 27, 2019, 10:00 AM Arnaud Le Hors <lehors@...> wrote:

Hi all,

I find myself largely in agreement with the sentiment expressed by Shawn and Chris. I find it rather unfortunate that attempts to understand how Besu will fit in and what its addition means to be interpreted as a vote against it. I think it is the TSC's job to take a serious look at every proposal and understand what the implications are. These shouldn't necessarily be seen as a pushback as much as an interest in looking after the well being of Hyperledger.

It has been said that we are making new rules as we go and I think that's a fair point but I for one don't think that's really by choice nor a bad thing. Hyperledger is still a very young organization and it should be expected that it goes through some transformation as it grows. Our charter states that our missing is to "create an enterprise grade, open source distributed ledger framework and code base" [1]. So, as a matter of fact, we've literally been making new rules all along since we accepted developing in parallel more than one dlt. Why should anyone be then surprised we keep doing so?

Anyway, I trust that with time we will get our act together. I understand the board is looking into updating our charter, which seems to be a good start. What's important to me, in line with what Chris stated and what I put in my TSC nomination pitch, is that we do a better job at documenting how the different projects compare and relate to one another, so that people in the community out there no longer get utterly confused when they come to our website in search for where to start they journey.

Cheers.

[1] https://www.hyperledger.org/about/charter
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chris.ferris@...>
To:        Shawn Amundson <amundson@...>
Cc:        VIPIN BHARATHAN <vip@...>, "vipinsun@..." <vipinsun@...>, Silas Davis <silas@...>, "jon.geater@..." <jon.geater@...>, "tsc@..." <tsc@...>
Date:        08/27/2019 03:14 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
Sent by:        tsc@...





comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.


-Shawn



Vipin Bharathan
 

Hello Mr. RGB,
Hope you had a nice vacation.
Agree that we need to dig into the permissioned/permissionless integration subject.
Jonathan L may be the most knowledgeable here since his Unbounded Network houses both permissioned and permissionless  dlts and he is a sponsor of the Besu project. 
Maybe we could start with challenges/obstacles in Unbounded around the boundary of permissioned and permissionless.
Knowing Jonathan he is bound(sic) to say none😇😇  .... 
Best,
Vipin

On Fri, Sep 6, 2019 at 8:55 AM Richard G Brown (R3) via Lists.Hyperledger.Org <richard=r3.com@...> wrote:

Jonathan, Silas, all,

 

Thanks for your thoughtful comments to my post.  Sorry for the (very) slow reply – I was on holiday.

 

I know the immediate forcing function (the Besu approval discussion) has passed but I do remain interested in the permissioned/permissionless integration discussion.  But perhaps the approach in my original email, where I tried to intuit legitimate use-cases from first principles, was the wrong approach – maybe we just need to observe what people actually do,  what happens and what works. I think it might have been Vipin who rightly called me out over this.   Anyway - I don’t want to beat a dead horse so I’ll step back from this for now in this forum whilst the hard work of bringing the new code base and identifying synergies with the other projects, etc., kicks off.

 

Cheers,

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

2 London Wall Place | Floor 12 | London | EC2Y 5AU

M: +44 7764 666821 | T: @gendal

richard@... . www.r3.com

 

From: Jonathan Levi <jonathan@...>
Reply to: "jonathan@..." <jonathan@...>
Date: Thursday, 29 August 2019 at 15:43
To: "jonathan@..." <jonathan@...>, Arnaud Le Hors <lehors@...>, Richard Brown <richard@...>, Christopher B Ferris <chrisfer@...>, Gari Singh <gari.r.singh@...>
Cc: Jonathan Levi <jonathan@...>, Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live

 

... "It is ashame that we meet [ONLY] in other events, no the Hyperledger ones anymore", I meant.

 

(Typing from and old and dusty mobile)

 

On Thu, Aug 29, 2019 at 7:26 AM, Jonathan Levi (HACERA)

<jonathan@...> wrote:

Hi everybody,

 

While I am obviously in support of this proposal, being the first sponsor in the list after Consensys, I have had a LOT of conversations about this "move" and I hope tgat today Goes Well * (defined below).

 

Personally, I started to help, code and build one of the best Permissioned Blockchain framework (Fabric) AFTER working on Ethereum in 2015 and Bitcoin years before that. At first, I received a lot of criticism from some in the Ethereum community, while I kept on helping Ethereum, with advise, participating (and winning) in some impactful hackathons (Interoperability, Sharing, Confidentiality, Scaling) and help judge in many others. So I am glad that ConsenSys invested in a permissioned version (in addition to the amazing work that the Quorum team is constantly delivering).

 

Professionally, I would really like the TSC to think about "where do we go from here". 

 

I’m joining the disagreement with Vipin, I didn’t like the tone nor the accusations/blaming that people are not judging this proposal technically, or that people hold Besu to a different standard. I also don't think that this  is "diverse" as the project and code is provided by a single vendor (right now). Last, it is not clear at this point that this will get Hyperledger close to the EEA, as the EEA is set on supporting Quorum. With the specification effort (version 4 will be released during Ethereum DevCon 5), and they are welcoming other implementations, but to jump and declare "success" just by having one more project in Hyperledger, does not make us all friends. I am looking for a much more collaboration than competition here.

 

---- 

 

I raised the question of whether we would like all projects to fit well in Hyperledger and we have a lot of discussions around "who is going to do all this or that". Shawn and Chris addressed it, as indeed "the code won't write itself", and I agree with Arnaud, we are young and have to continue redefine and adapt.

 

I would like to quicky define what I mean by hoping that the vote today "Goes Well". I think we made a big mistake to not prevent the in-fighting in Hyperledger. Fabric was an investment of many many man years, and without breaching too many NDAs, it was worth many 100s of millions of dollars, especially in 2017.

 

How did we get there? TOGETHER.

 

In 2016 we had R3 who worked night and day so close to banking and the financial sector who kept on feeding us with super valuable feedback, Digital Asset - constantly provided us with requirements and I will never forget how much Intel (Mic B and others) set down with the Fabric team and literally worked out with the Fabric leading maintainers some major issues that we missed at the time with the genesis block with channels.

 

In 2018, we have lost a.lot of market momentum due to all these fights over Grid, over the pluggable consensus (I would have LOVED) to have PoET in Fabric, which I believe would have helped Intel a lot, given the fact that we already have 7 cloud providers who invested so much in having Fabric support. I think the fights and fragmentation is not helpful and a lot of innovation in 2018 is happening elsewhere.

 

Trying to remedy and bridge, HACERA and IBM have representatives (soon to be maintainers, more likely) of Hyperledger Transact, so that we can bridge the Fabric-Sawtooth gap when it comes to contracts and I would have loved it if Sabres (the WASM work) will be reusable outside Sawtooth, and HACERA can probably help with it this year.

 

-----

 

What am I asking? I want people to be very honest with their vote. If we don't want to work with Ethereum, Pantheon or Besu - just say so and let's move on.

 

But if we do, or are willing to try, then let's welcome their code and their team, and work out what we can do together. Again: TOGETHER ;-)

 

And Richard G. Brown - of course your participation in any of these discussions is highly welcome. It is a shame that we meet in other events, but please do chime in.

 

Thanks again everyone.

 

Jonathan Levi

 

 

 

 

On Tue, Aug 27, 2019, 10:00 AM Arnaud Le Hors <lehors@...> wrote:

Hi all,

I find myself largely in agreement with the sentiment expressed by Shawn and Chris. I find it rather unfortunate that attempts to understand how Besu will fit in and what its addition means to be interpreted as a vote against it. I think it is the TSC's job to take a serious look at every proposal and understand what the implications are. These shouldn't necessarily be seen as a pushback as much as an interest in looking after the well being of Hyperledger.

It has been said that we are making new rules as we go and I think that's a fair point but I for one don't think that's really by choice nor a bad thing. Hyperledger is still a very young organization and it should be expected that it goes through some transformation as it grows. Our charter states that our missing is to "create an enterprise grade, open source distributed ledger framework and code base" [1]. So, as a matter of fact, we've literally been making new rules all along since we accepted developing in parallel more than one dlt. Why should anyone be then surprised we keep doing so?

Anyway, I trust that with time we will get our act together. I understand the board is looking into updating our charter, which seems to be a good start. What's important to me, in line with what Chris stated and what I put in my TSC nomination pitch, is that we do a better job at documenting how the different projects compare and relate to one another, so that people in the community out there no longer get utterly confused when they come to our website in search for where to start they journey.

Cheers.

[1] https://www.hyperledger.org/about/charter
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chris.ferris@...>
To:        Shawn Amundson <amundson@...>
Cc:        VIPIN BHARATHAN <vip@...>, "vipinsun@..." <vipinsun@...>, Silas Davis <silas@...>, "jon.geater@..." <jon.geater@...>, "tsc@..." <tsc@...>
Date:        08/27/2019 03:14 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
Sent by:        tsc@...





comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
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.


-Shawn