Date   

Re: Upcoming Event: Hyperledger Aries Quarterly Update Due #tsc-project-update - Thu, 08/29/2019 #tsc-project-update #cal-reminder

Lynn Bendixsen <lynn@...>
 

Sam Curren has posted the Aries Q3 Update for review:


On Tue, Aug 27, 2019 at 1:00 AM tsc@... Calendar <tsc@...> wrote:

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.


The 2019-2020 TSC election is underway again

Ry Jones
 

You cannot use your old ballot urls - you should get new ones today.

Please read the nomination statements and vote!



--
Ry Jones
Community Architect, Hyperledger


Re: Deprecation of Composer

Middleton, Dan <dan.middleton@...>
 

Hi Simon, Dan, and Caroline,

We will put this up for ratification at this week's TSC meeting.
I do think this is a healthy sign of a mature open source organization - that we are actively managing the portfolio of projects and in this case that the community itself is taking that active role.

Thanks,

Dan Middleton
Principal Engineer
Intel <https://www.intel.com/content/www/us/en/diversity/diversity-at-intel.html>


On 8/28/19, 7:44 AM, "tsc@... on behalf of Simon Stone" <tsc@... on behalf of sstone1@...> wrote:

Hello,

It's been a whole year since the IBM team contributing to Composer moved to focus on Fabric. Dan Selman, the other maintainer, has been focusing on smart legal contracts under the Accord project.

In that time, very little activity has occurred in Composer, with the exception of us publishing several bug fix releases for users we know of who are still using Composer in production (these users are all in the process of migrating their solutions to Fabric). Also in this time, no other contributors have stepped forward to take over development of the Composer project.

We have been following the output of the Project Lifecycle Task Force, and we would like to propose to the TSC that the Composer project is moved into deprecated status. As mentioned above, we are continuing to support certain users, and we are also happy to continue to merge and publish fixes from other contributors if they arise.

We understand that after we move into deprecated status, there will be a period of 6 months before Composer is moved into EOL. We have no problems with this, but nearer the time we may want to discuss options around continuing to support certain users.

Please let me know if I misunderstood anything, or if you need us to do anything else on top of this note.

Many thanks,
Simon StoneUnless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Deprecation of Composer

Simon Stone <sstone1@...>
 

Hello,

It's been a whole year since the IBM team contributing to Composer moved to focus on Fabric. Dan Selman, the other maintainer, has been focusing on smart legal contracts under the Accord project.

In that time, very little activity has occurred in Composer, with the exception of us publishing several bug fix releases for users we know of who are still using Composer in production (these users are all in the process of migrating their solutions to Fabric). Also in this time, no other contributors have stepped forward to take over development of the Composer project.

We have been following the output of the Project Lifecycle Task Force, and we would like to propose to the TSC that the Composer project is moved into deprecated status. As mentioned above, we are continuing to support certain users, and we are also happy to continue to merge and publish fixes from other contributors if they arise.

We understand that after we move into deprecated status, there will be a period of 6 months before Composer is moved into EOL. We have no problems with this, but nearer the time we may want to discuss options around continuing to support certain users.

Please let me know if I misunderstood anything, or if you need us to do anything else on top of this note.

Many thanks,
Simon StoneUnless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Another community thinking about diversity vs convergence

Duncan Johnston-Watt
 

Brian

Very interesting.

Leaving aside legal niceties can we rebadge ourselves as the Hyperledger Foundation?

After all these years I still struggle when saying we are members of the Hyperledger ... 

I often find myself using the F word in conversation (sorry!) and when writing use ecosystem or community as Greenhouse doesn’t communicate anything meaningful to the rest of the world. 

Best
--
Duncan Johnston-Watt
CEO, Blockchain Technology Partners
+44 777 190 2653 | @duncanjw


On 28 Aug 2019, at 05:39, Brian Behlendorf <bbehlendorf@...> wrote:

The Continuous Delivery Foundation, http://cd.foundation/ (yes that's a real URL, stunned me too, didn't realize that TLD was active!) has been having a very similar conversation to our own:

https://lists.cd.foundation/g/cdf-toc/message/175

There was referenced the Xerces & XML parsers work, as I believe Arnaud mentioned in another thread.  Kohsuke put it really well: 

I'm a firm believer that the CDF should adopt a similar mindset. We should welcome projects that might disrupt some of our existing projects. And to reiterate the first point, I'm also a firm believer that we should actively recruit projects that are complementary and non-overlapping. Those two goals aren't mutually exclusive.

The OpenJS Foundation, https://js.foundation/ (holy TLDs Batman, I need to get out more) has this issue as well, even more so now that they merged with Node.js Foundation.

As explosive domains of technology well-provisioned by open-source-licensed options hits a crest, the pressure to merge efforts grows pretty naturally as a result of everyone eventually realizing that collaboration beats competition when the product's price is zero.  When that consolidation can play out in an environment where the specific license chosen is the same, where the collaboration tools are mostly or entirely the same, where opportunities to collaborate on the small bits (common libraries, APIs, etc) first are easy and encouraged, then it's much less painful than when it's the MechaGodzilla Foundation vs Mothra Foundation duking it out over Tokyo.

Brian

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


Another community thinking about diversity vs convergence

Brian Behlendorf
 

The Continuous Delivery Foundation, http://cd.foundation/ (yes that's a real URL, stunned me too, didn't realize that TLD was active!) has been having a very similar conversation to our own:

https://lists.cd.foundation/g/cdf-toc/message/175

There was referenced the Xerces & XML parsers work, as I believe Arnaud mentioned in another thread.  Kohsuke put it really well: 

I'm a firm believer that the CDF should adopt a similar mindset. We should welcome projects that might disrupt some of our existing projects. And to reiterate the first point, I'm also a firm believer that we should actively recruit projects that are complementary and non-overlapping. Those two goals aren't mutually exclusive.

The OpenJS Foundation, https://js.foundation/ (holy TLDs Batman, I need to get out more) has this issue as well, even more so now that they merged with Node.js Foundation.

As explosive domains of technology well-provisioned by open-source-licensed options hits a crest, the pressure to merge efforts grows pretty naturally as a result of everyone eventually realizing that collaboration beats competition when the product's price is zero.  When that consolidation can play out in an environment where the specific license chosen is the same, where the collaboration tools are mostly or entirely the same, where opportunities to collaborate on the small bits (common libraries, APIs, etc) first are easy and encouraged, then it's much less painful than when it's the MechaGodzilla Foundation vs Mothra Foundation duking it out over Tokyo.

Brian

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


minutes for 2019-08-22 TSC meeting are up

Dave Huseby <dhuseby@...>
 


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@...>
 


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.

1281 - 1300 of 3898