1. toc@lists.hyperledger.org
  2. Messages
   Date   
minutes for 2019-08-22 TSC meeting are up

Dave Huseby <dhuseby@...>
 

https://wiki.hyperledger.org/display/HYP/2019+08+22+TSC+Minutes

With that, I believe we are all caught up on the minutes.

Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
TSC meeting minutes backlog: 2019-07-25 minutes are out

Dave Huseby <dhuseby@...>
 

https://wiki.hyperledger.org/display/HYP/2019+07+25+TSC+Minutes

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Re: TSC 2019-2020 Nominee slate

Ry Jones
 

You're all welcome!

I want to point out that one more nominee reached out and asked to be removed from the list.
Ry

On Tue, Aug 27, 2019 at 9:36 AM Christopher Ferris <chrisfer@...> wrote:
Agreed - thanks, Ry!
 
I would also note that it is indeed an impressive list. I am really pleased that there is so much interest!
 
I also think that this makes clear that we should, indeed, expand the TSC.
 
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: "Jonathan Levi (HACERA)" <jonathan@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] TSC 2019-2020 Nominee slate
Date: Tue, Aug 27, 2019 12:10 PM
 
Many thanks for blazingly quick turnaround time here Ry !
 
Jonathan
 



--
Ry Jones
Community Architect, Hyperledger
Re: Hyperledger Besu Proposal is Live

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
Re: Hyperledger Besu Proposal is Live

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

 

 

 

 

 
Re: TSC 2019-2020 Nominee slate

Christopher Ferris <chrisfer@...>
 

Agreed - thanks, Ry!
 
I would also note that it is indeed an impressive list. I am really pleased that there is so much interest!
 
I also think that this makes clear that we should, indeed, expand the TSC.
 
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: "Jonathan Levi (HACERA)" <jonathan@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] TSC 2019-2020 Nominee slate
Date: Tue, Aug 27, 2019 12:10 PM
 
Many thanks for blazingly quick turnaround time here Ry !
 
Jonathan
 
Re: Hyperledger Besu Proposal is Live

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
Re: TSC 2019-2020 Nominee slate

Jonathan Levi (HACERA)
 

Many thanks for blazingly quick turnaround time here Ry !

Jonathan
TSC 2019-2020 Nominee slate

Ry Jones
 

More people have been nominated. Please read the biographies carefully.
https://wiki.hyperledger.org/display/HYP/2019+Nomination+Statements

Three nominees asked to be removed; they were nominated by someone else.
Ry
--
Ry Jones
Community Architect, Hyperledger
Re: Hyperledger Besu Proposal is Live

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
Re: Hyperledger Besu Proposal is Live

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
Upcoming Event: Hyperledger Aries Quarterly Update Due #tsc-project-update - Thu, 08/29/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Aries Quarterly Update Due #tsc-project-update

When: Thursday, 29 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Aries update to the TSC is due. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.
Upcoming Event: Hyperledger Explorer Quarterly Update Due #tsc-project-update - Thu, 08/29/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Explorer Quarterly Update Due #tsc-project-update

When: Thursday, 29 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Explorer update to the TSC was due 26 August, 2019, and it will be presented to the TSC on 29 August, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.
Upcoming Event: Hyperledger Composer Quarterly Update Due #tsc-project-update - Thu, 08/29/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Composer Quarterly Update Due #tsc-project-update

When: Thursday, 29 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Composer update to the TSC was due 26 August, 2019, and it will be presented to the TSC on 29 August, 2019. Please review prior to the meeting and bring your questions.
Re: Hyperledger Besu Proposal is Live

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
2019 Q3 Hyperledger Transact Quarterly Update Is Available

Mark Ford <mfford@...>
 

Team,

The 2019 Q3 Hyperledger Transact quarterly update is now available for review.


Thanks,
-Mark
Re: Restart / 2 Day Delay for TSC Election

VIPIN BHARATHAN
 

Vote early and vote often!

Get Outlook for iOS
From: tsc@... <tsc@...> on behalf of Brian Behlendorf via Lists.Hyperledger.Org <bbehlendorf=linuxfoundation.org@...>
Sent: Monday, August 26, 2019 3:31:59 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: [Hyperledger TSC] Restart / 2 Day Delay for TSC Election
 
It was brought to our attention that the TSC election deadlines had an
off-by-one error: nominations open until August 26th, but voting was
scheduled to start the same day, so it meant we opened voting before
being able to accomodate two inbound nominations we know of, and
possibly others.

So, nominations for the election are still open until today, end of day,
US Pacific time.

To correct the error, new ballots will be sent on Wednesday morning and
voting will be restarted.  If you voted before, please vote again.  The
deadline for votes, and the rest of the process, has also been delayed
by 2 days, plus some similar additional buffer time during the TSC Chair
election.  The new TSC will be named September 4th, the new Chair Sep 13th.

Thank you,

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf

Restart / 2 Day Delay for TSC Election

Brian Behlendorf
 

It was brought to our attention that the TSC election deadlines had an off-by-one error: nominations open until August 26th, but voting was scheduled to start the same day, so it meant we opened voting before being able to accomodate two inbound nominations we know of, and possibly others.

So, nominations for the election are still open until today, end of day, US Pacific time.

To correct the error, new ballots will be sent on Wednesday morning and voting will be restarted.  If you voted before, please vote again.  The deadline for votes, and the rest of the process, has also been delayed by 2 days, plus some similar additional buffer time during the TSC Chair election.  The new TSC will be named September 4th, the new Chair Sep 13th.

Thank you,

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf
Re: New TSC candidates

Shawn Amundson
 

Thanks Dan, very kind. I agree that Andi, Gari, and Tracy would be excellent TSC representatives.

In addition, here is a shout out for all the other code-contributing maintainers as well: please vote for maintainers! It is important that the projects have deep technical representation on the TSC, and the best way to do that is to vote for maintainers. Several of the maintainers on the list are fairly quiet and not well-known, but have substantial personal investment in building Hyperledger's codebase. All the maintainers on the list are great to work with. Vote for them!

Thanks,

-Shawn


On Mon, Aug 26, 2019 at 11:10 AM Middleton, Dan <dan.middleton@...> wrote:

I would like to highlight a few of the candidates who have not previously been on the TSC, but whom I would be happy to see on the TSC based on my direct knowledge of their extensive contributions.

 

Andrea Gunderson is one of the most prolific contributors in Hyperledger. Her development work on the web assembly engine, Sabre, stands out for both its technical sophistication and relevance to cross project interests. What you will not know from her bio and pitch is that she is very detail and delivery oriented. I’m confident that if elected to the TSC, Ms. Gunderson will arrive informed and prepared to increase the velocity of the TSC.

 

Gari Singh should be familiar to most involved with Fabric. Like Ms. Gunderson, Mr. Singh is a long time maintainer and prolific developer. As Fabric embodies different architectural priorities than the other frameworks, I do not believe that Mr. Singh’s technical opinions will always align with my own, but I do anticipate that the TSC will be better for his participation.

 

Tracy Kuhrt should be familiar to all of the project communities. Not only has she made direct contributions, but as one of the original community architects, Ms. Kuhrt has been exposed to the full breadth of Hyperledger. In fact, I believe that she has a unique breadth and depth of contribution to Hyperledger that the TSC should not be without. 

 

Shawn Amundson has worked across several projects and may be familiar to different portions of our Hyperledger Community. I view him as the initiator of the cross-project effort now called Transact (among substantial contributions to several other projects). He is an ardent proponent of open source principles and championed the adoption of the Rust project’s RFC process which has been independently adopted by several of our projects. 

 
The 2019-2020 election is underway

Ry Jones
 

If you did not get a ballot, and you think you should have, please reach out to me directly.

If you did get a ballot - please vote!
1281 - 1300 of 3892