Date   

Upcoming Event: Hyperledger Ursa Quarterly Update Due #tsc-project-update - Thu, 09/12/2019 #cal-reminder #tsc-project-update

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

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

When: Thursday, 12 September 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Ursa update to the TSC was due 9 September, 2019, and it will be presented to the TSC on 12 September, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Upcoming Event: Hyperledger Learning Materials Development WG Quarterly Update Due #tsc-wg-update - Thu, 09/12/2019 #tsc-wg-update #cal-reminder

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

Reminder: Hyperledger Learning Materials Development WG Quarterly Update Due #tsc-wg-update

When: Thursday, 12 September 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Learning Materials Development WG update to the TSC was due 9 September, 2019, and it will be presented to the TSC on 12 September, 2019. Please review the update at TSC Working Group Updates prior to the meeting and add your questions to the update.


Contributor + Marketing call

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

Hi Contributors,

 

Reminder that the Marketing Committee is reaching out to stay engaged on how your projects are marketed. The first joint meeting is Sept 11 at 9am PT:

 

The purpose of this call is to discuss marketing related initiatives around the Hyperledger projects and community. This is a great opportunity for project maintainers and contributors to learn how they can get involved in many aspects of marketing including overall messaging, events, content, social media, and PR, to further help the public hear about and understand Hyperledger and its community. Goal(s): Improve the communication between marketing and technical leaders in the community Gain guidance and involvement from Hyperledger project technical experts in marketing initiatives Understand how we can better work together to amplify Hyperledger’s public presence and marketing messages Who should join: Maintainers, active contributors to Hyperledger projects Dial in information: The second Wednesday of every month Kick off call: Wednesday, Sept 11 at 9am PT Join Zoom Meeting https://zoom.us/j/982600073 One tap mobile +16465588656,,982600073# US (New York) +16699006833,,982600073# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 6833 US (San Jose) 877 369 0926 US Toll-free 855 880 1246 US Toll-free +1 647 558 0588 Canada 855 703 8985 Canada Toll-free Meeting ID: 982 600 073 Find your local number: https://zoom.us/u/abaoIu7JMk Hosted by: Jessica Rampen (Sr. Manager of Marketing Communications) Dan O’Prey (Hyperledger MC chair) Alissa Worley (Hyperledger MC vice chair)

 

Regards,

Dan


Re: Congratulations to the members of the 2019-2020 TSC!

VIPIN BHARATHAN
 


Hi Brian/Todd/Bob/all,

It is unfortunate that the happy incidence of having gender diversity is tied  to the debate about over-representation of a single firm on the TSC. The result is more diversity in one dimension as we lose diversity in another.

A 33%  turnout is not good for both.  It has been shown that in a low turnout election, committed and well organized groups dominate. 

If gender diversity was the result of a 60+% turnout, it would have appeared "more real".
A 60+% turnout would have been better to justify the domination of a single firm on the TSC.  

Increasing turnout is also needed for truer democracy in general. Increasing turnout is quite difficult in this age of cynicism and apathy. How do we break through the ice? A question that needs to be answered through concrete steps for stimulating turnout in the next election. I had provided some pointers to the election officer, maybe a little too late. There are well known techniques for this. We need to adopt them.

This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"; including the contributors on the wiki and the SIG participants in my view. The github query does not measure technical artifacts. I could contribute a single spelling correction in github and be included very easily; whereas someone who contributes only an extensive technical blog or article is excluded; if they are not on a Working Group list.

Best,
Vipin
 

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


From: tsc@... <tsc@...> on behalf of Todd Little via Lists.Hyperledger.Org <todd.little=oracle.com@...>
Sent: Saturday, September 7, 2019 1:45 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Congratulations to the members of the 2019-2020 TSC!
 
Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd


Re: Congratulations to the members of the 2019-2020 TSC!

Todd Little
 

Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd


Re: Congratulations to the members of the 2019-2020 TSC!

Bob Summerwill <bob@...>
 

I wrote a blog post on diversity while I was standing for the TSC in 2018, which triggered some debate:

https://bobsummerwill.com/2018/08/15/hyperledger-tsc-candidates-and-thoughts-on-diversity/

While I would agree that the high level of IBM affiliation on the 2019-2020 committee is less than ideal, I must take the opportunity to congratulate Tracy and Swetha both on standing for AND winning election to the TSC following years of 100% male candidates.

That is a big step in the right direction on diversity of representation in the TSC which should not be overlooked.   Bravo!


Bob Summerwill
Executive Director
Ethereum Classic Cooperative

On Fri., Sep. 6, 2019, 5:33 p.m. Brian Behlendorf, <bbehlendorf@...> wrote:
Hi Todd,

First, let me express congratulations to the newly elected TSC, particularly the new members who will bring fresh energy and perspectives to our conversations.  You are the heart of the technical credibility of this project, and I could not be happier to see it in such good hands.  (apologies for the delay, I've been traveling)

Todd: thank you for expression of concerns that no doubt are latent on other people's minds.  I am sure they are also on the minds of each of the TSC members, too.

We have been very careful at Hyperledger to separate out the sponsoring-member-consortium layer from the developer-driven product and technical layer.  The former is intended to run very much like any ordinary consortium would; the latter, like any well functioning open source project.  I may be projecting from my experience with Apache, and perhaps over-assuming that the following is obvious, but I always felt it's been clear that developers are expected to participate and contribute as individuals first, and as employees second.  For example:

* If a maintainer on a project, or a member of the TSC, changes employers, they do not lose their status; their "seat" is not conferred to someone else from the same employer, they keep it wherever they go. 

* If a developer is asked by their employer to submit code that the developer does not believe is the right thing to do, the developer should not submit that code.  In no case is "we were asked to do it this way" acceptable as a rationale for submitting or accepting a pull request or other technical decision, and they can ask us (HL staff) to delicately intervene if necessary.

* While we (Hyperledger staff) encourage companies to commit their developers to projects, and argue that they'll realize benefit from doing so, we constantly warn them that the public processes must rule the day; that project proposals, pull requests, even discussions will go whatever way the developer community decides it should, no matter how unfair or subject that may feel.  We also make it clear that a company's sponsoring membership in Hyperledger has no bearing on their technical contributions; and that conversely, non-member companies can realize the full benefit of using and contributing to Hyperledger projects.  We have several companies who contribute major amounts of code, and it's running code that usually dictates what happens (the do-ocracy).  Of course this swings both ways - it would be inappropriate for us to change the TSC election outcome because it didn't look the way we think it should.

Obviously, developers may feel pressure from their employers, and some will be able to push back but others won't feel so empowered.  The market for talent in this space is so hot, and the profile accrued to TSC members and project maintainers so high, that job security is likely not the overwhelming issue.  Others will act out of loyalty to their employers.  However, this community is capable of watching for, and calling out, behavior they feel might cross that line.  And we as HL staff have given feedback privately when we've seen that too.

By any metric, to date, IBM's technical contributions to Hyperledger have been substantial, and more than any other company.  They deserve credit for that.  Early on, that contribution level was so high that it led to public perception issues of "control", and a sense that technical decisions were being made on white boards and phone calls offline rather than online.  I won't speak for them, but it was made clear to us that IBM did not want that outcome - they brought Fabric to Hyperledger to get developer leverage, so that their headcount would be complemented by the efforts of many others.  And, they knew it was essential that Fabric not be a single-vendor product, but an industry movement.  So we worked with them on both the technical process issues, and the public perception issues, and I believe these are in the past.  They no longer are more than half the contributions into Fabric, as per Chris Ferris's numbers.  There are many other projects beyond Fabric in Hyperledger, and IBM has supported those, boosting Indy and Sawtooth and now even welcoming Besu.  Perhaps this is one reason the other electors felt comfortable voting for the IBM-employed candidates.

Now that every major public cloud provider offers a managed Fabric as a service, and those companies are now getting commercial traction, we expect those other companies to increase their investments into Fabric, entirely out of self-interest.  That will, no doubt, also increase the representation from those companies in the maintainer community in Fabric, into other Hyperledger projects, and in the next TSC election.

But all that said, there was talk about increasing the size of the TSC, to increase the prospect that more projects at Hyperledger will see one of their maintainers onboard, and to account for the growing developer community.  I think that would address both the perception of an issue here, and any actual attempt by a single vendor to exert "control" over their employees who become TSC members.  The new TSC can discuss this.  They could decide to ask the Governing Board to adjust the Hyperledger bylaws to increase the size of the TSC for the next election.  They could also ask the Governing Board to approve a one-time add of a set of new TSC members, so that this greater representation can happen in the current TSC term.  I think there are a lot of great reasons for either approach.

Again, I'm excited by the new TSC.  There's a lot of new hard work to do together!

Hope this helps,

Brian


On 9/6/19 3:04 PM, Todd Little wrote:
Hi TSC and Hyperledger in general,

While I don't doubt the results of the election, I do have to question whether this is the sort of outcome Hyperledger desires.  For projects to exit incubation they must exhibit diversity of contributions such that a project is not "controlled" by a single organization.  Why would the TSC find that TSC membership adheres to a lesser standard?  It is very clear that IBM now controls the TSC and is that the direction Hyperledger wants to take?

-tl


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


Re: Congratulations to the members of the 2019-2020 TSC!

Brian Behlendorf
 

Hi Todd,

First, let me express congratulations to the newly elected TSC, particularly the new members who will bring fresh energy and perspectives to our conversations.  You are the heart of the technical credibility of this project, and I could not be happier to see it in such good hands.  (apologies for the delay, I've been traveling)

Todd: thank you for expression of concerns that no doubt are latent on other people's minds.  I am sure they are also on the minds of each of the TSC members, too.

We have been very careful at Hyperledger to separate out the sponsoring-member-consortium layer from the developer-driven product and technical layer.  The former is intended to run very much like any ordinary consortium would; the latter, like any well functioning open source project.  I may be projecting from my experience with Apache, and perhaps over-assuming that the following is obvious, but I always felt it's been clear that developers are expected to participate and contribute as individuals first, and as employees second.  For example:

* If a maintainer on a project, or a member of the TSC, changes employers, they do not lose their status; their "seat" is not conferred to someone else from the same employer, they keep it wherever they go. 

* If a developer is asked by their employer to submit code that the developer does not believe is the right thing to do, the developer should not submit that code.  In no case is "we were asked to do it this way" acceptable as a rationale for submitting or accepting a pull request or other technical decision, and they can ask us (HL staff) to delicately intervene if necessary.

* While we (Hyperledger staff) encourage companies to commit their developers to projects, and argue that they'll realize benefit from doing so, we constantly warn them that the public processes must rule the day; that project proposals, pull requests, even discussions will go whatever way the developer community decides it should, no matter how unfair or subject that may feel.  We also make it clear that a company's sponsoring membership in Hyperledger has no bearing on their technical contributions; and that conversely, non-member companies can realize the full benefit of using and contributing to Hyperledger projects.  We have several companies who contribute major amounts of code, and it's running code that usually dictates what happens (the do-ocracy).  Of course this swings both ways - it would be inappropriate for us to change the TSC election outcome because it didn't look the way we think it should.

Obviously, developers may feel pressure from their employers, and some will be able to push back but others won't feel so empowered.  The market for talent in this space is so hot, and the profile accrued to TSC members and project maintainers so high, that job security is likely not the overwhelming issue.  Others will act out of loyalty to their employers.  However, this community is capable of watching for, and calling out, behavior they feel might cross that line.  And we as HL staff have given feedback privately when we've seen that too.

By any metric, to date, IBM's technical contributions to Hyperledger have been substantial, and more than any other company.  They deserve credit for that.  Early on, that contribution level was so high that it led to public perception issues of "control", and a sense that technical decisions were being made on white boards and phone calls offline rather than online.  I won't speak for them, but it was made clear to us that IBM did not want that outcome - they brought Fabric to Hyperledger to get developer leverage, so that their headcount would be complemented by the efforts of many others.  And, they knew it was essential that Fabric not be a single-vendor product, but an industry movement.  So we worked with them on both the technical process issues, and the public perception issues, and I believe these are in the past.  They no longer are more than half the contributions into Fabric, as per Chris Ferris's numbers.  There are many other projects beyond Fabric in Hyperledger, and IBM has supported those, boosting Indy and Sawtooth and now even welcoming Besu.  Perhaps this is one reason the other electors felt comfortable voting for the IBM-employed candidates.

Now that every major public cloud provider offers a managed Fabric as a service, and those companies are now getting commercial traction, we expect those other companies to increase their investments into Fabric, entirely out of self-interest.  That will, no doubt, also increase the representation from those companies in the maintainer community in Fabric, into other Hyperledger projects, and in the next TSC election.

But all that said, there was talk about increasing the size of the TSC, to increase the prospect that more projects at Hyperledger will see one of their maintainers onboard, and to account for the growing developer community.  I think that would address both the perception of an issue here, and any actual attempt by a single vendor to exert "control" over their employees who become TSC members.  The new TSC can discuss this.  They could decide to ask the Governing Board to adjust the Hyperledger bylaws to increase the size of the TSC for the next election.  They could also ask the Governing Board to approve a one-time add of a set of new TSC members, so that this greater representation can happen in the current TSC term.  I think there are a lot of great reasons for either approach.

Again, I'm excited by the new TSC.  There's a lot of new hard work to do together!

Hope this helps,

Brian


On 9/6/19 3:04 PM, Todd Little wrote:
Hi TSC and Hyperledger in general,

While I don't doubt the results of the election, I do have to question whether this is the sort of outcome Hyperledger desires.  For projects to exit incubation they must exhibit diversity of contributions such that a project is not "controlled" by a single organization.  Why would the TSC find that TSC membership adheres to a lesser standard?  It is very clear that IBM now controls the TSC and is that the direction Hyperledger wants to take?

-tl


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


Re: Congratulations to the members of the 2019-2020 TSC!

Todd Little
 

Hi TSC and Hyperledger in general,

While I don't doubt the results of the election, I do have to question whether this is the sort of outcome Hyperledger desires.  For projects to exit incubation they must exhibit diversity of contributions such that a project is not "controlled" by a single organization.  Why would the TSC find that TSC membership adheres to a lesser standard?  It is very clear that IBM now controls the TSC and is that the direction Hyperledger wants to take?

-tl


Re: HYP Wiki Upgrade

Tim Johnson <tijohnson@...>
 

Update complete.

On 9/6/19 9:37 AM, Tim Johnson wrote:
What: Upgrade Hyperledger wiki/wiki2 to latest version due to new exploit

When: Fri Sept 6 15:00 EST

How long: 1hr

Tim


HYP Wiki Upgrade

Tim Johnson <tijohnson@...>
 

What: Upgrade Hyperledger wiki/wiki2 to latest version due to new exploit

When: Fri Sept 6 15:00 EST

How long: 1hr

Tim


security vuln reporting policy in GH

Christopher Ferris <chris.ferris@...>
 

I know that GH has been reporting vulnerabilities in dependencies for a while now, but I see that they have also added the ability to publish your security vulnerability reporting process via the GH repository.


Seems to me that it would be A Good Thing (tm) to update all the Hyperledger repos with our process, with each project adding in the set of releases covered by the policy.


Thoughts?

Chris


Re: Hyperledger Besu Proposal is Live

Vipin Bharathan
 

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

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

Jonathan, Silas, all,

 

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

 

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

 

Cheers,

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

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

M: +44 7764 666821 | T: @gendal

richard@... . www.r3.com

 

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

 

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

 

(Typing from and old and dusty mobile)

 

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

<jonathan@...> wrote:

Hi everybody,

 

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

 

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

 

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

 

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

 

---- 

 

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

 

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

 

How did we get there? TOGETHER.

 

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

 

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

 

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

 

-----

 

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

 

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

 

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

 

Thanks again everyone.

 

Jonathan Levi

 

 

 

 

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

Hi all,

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

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

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

Cheers.

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




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





comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
Thanks for the thoughtful response.

  • Pluggable consensus has been in active discussion in the Architecture working group. Unfortunately participation in such cross dlt architectural conversations has dropped, at least under the aegis of the AWG. We have had conversations of how to reboot the WGs and you should join the conversation.

We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.

I would agree with Shawn, here. There could be a bit more alignment, across projects but we do have plug-able consensus. However, I will remind people that code doesn't write itself, and no one ever shipped an architecture diagram/paper into production. Hyperledger is, all being said, an open source community. I would really love to see people diving in and working out the "how" and then rolling up sleeves to help drive the implementation of their thinking.

  • There has been no support to bring "consistent technical principles". Working Groups and other cross-dlt areas where such work should take place are languishing and there are many actively campaigning against WGs. However this again has nothing to do with whether we should approve Besu or not.

The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.

Agree, no one is campaigning against WGs, per se. The discussion of WGs is more about making WGs *more relevant* to the projects so that the project contributors and maintainers might pay them more attention and participate, meaningfully to the benefit of the projects and the broader community.

  • HL is unique in its sheltering  of multiple DLT solutions, there is no comparable consortium and we are inventing the integrative concepts around such co-opetition. I am also an advocate of a full offering (integrating documentation, deployment, operational support, simple and intuitive UIs, adherence to regulation demonstrable with security audits, monitoring and self-healing),  having had some experience importing dlt solutions into highly regulated enterprises. 

To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.

...

  • The arrival of new projects into Hyperledger, especially something backed by large networks who are new to Hyperledger will stimulate work in all areas. When there is competition, people will be forced to improve their offerings to stay relevant.

But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.

...

  • In short, I am against holding Besu to a different standard than the existing platforms in Hyperledger. Let us be consistent. Getting new blood and new ideas into HL will make a difference in existing dlts as well. The new entrants may revive interest in cross-dlt efforts like the working groups and SIGs. 

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

Agreed. I've been struggling with this. I think that there's positive benefit to bringing the Hyperledger and Ethereum communities closer together in the hopes that kumbayah. Though, I don't necessarily think that there will ever be one DLT to rule them all, and in the darkness bind them. What I DO think that Hyperledger needs to sort out is how it positions and promotes its projects. Right now, there is a considerable amount of overlap/redundancy, and it can be difficult at best to try to articulate to the general public how the projects are differentiated from one another. Further, during any project's life-cycle there's a great deal of effort expended to raise its voice above the din, to get people to kick the tires and maybe get more interested/invested.

I'm fine if Hyperledger is to become the Apache-for-Enterprise-Blockchain-and-DLTs, but note that Apache marketing is about promoting Apache and the Apache Way, not Hadoop, Kafka, Maven, Tomcat, or OpenWhisk.

Brian and Jessica have a difficult job, just as any parents with multiple offspring. Each child is special yet loved and nurtured equally. When someone asks a parent which child they love more, the correct response is "all of them". So, what should be the Hyperledger response when asked by press and analysts which of its projects is better, the correct answer needs to be "judge for yourself, we support them all equally". Yet, in this ultra-competitive landscape there is a natural tendency for press and analysts to look for differentiation, conflict and adoption to inform their audiences (and drive clicks). How do we enable the projects to make their case if they are promoted as equals?

Where am I going with all of this? I think we need to collectively (with the Board and Marketing) address the question that Shawn posed: "What is Hyperledger?". If Hyperledger is indeed to be a "greenhouse" or "umbrella" organization where open source blockchain/dlt for enterprise is developed - taking its cue from Apache. Then, I think we need to come to terms with two things:

1) what we want to be the "Hyperledger Way", and
2) how projects are marketed

I think there's much to be learned from the success of Apache and Eclipse, both of which are home to hundreds of projects, some overlapping/competing, some collaborative integrate-able components that fit a given framework. It could be just about creating a "safe place to innovate", as I like to say. It could be about encouraging growth of community(s) around projects. It could be about defining a single compose-able framework for DLTs shepherded by a collection of WGs that do top-down architecture overseen by the TSC.

However, whatever we choose, we then need to sort out how (or whether) we market the projects via Hyperledger or, allow the projects to manage their own messaging.


-Shawn



Re: Hyperledger Besu Proposal is Live

Mohan Venkataraman
 

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

Mohan Venkataraman 
Chainyard



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

Jonathan, Silas, all,

 

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

 

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

 

Cheers,

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

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

M: +44 7764 666821 | T: @gendal

richard@... . www.r3.com

 

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

 

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

 

(Typing from and old and dusty mobile)

 

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

<jonathan@...> wrote:

Hi everybody,

 

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

 

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

 

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

 

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

 

---- 

 

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

 

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

 

How did we get there? TOGETHER.

 

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

 

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

 

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

 

-----

 

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

 

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

 

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

 

Thanks again everyone.

 

Jonathan Levi

 

 

 

 

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

Hi all,

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

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

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

Cheers.

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




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





comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
Thanks for the thoughtful response.

  • Pluggable consensus has been in active discussion in the Architecture working group. Unfortunately participation in such cross dlt architectural conversations has dropped, at least under the aegis of the AWG. We have had conversations of how to reboot the WGs and you should join the conversation.

We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.

I would agree with Shawn, here. There could be a bit more alignment, across projects but we do have plug-able consensus. However, I will remind people that code doesn't write itself, and no one ever shipped an architecture diagram/paper into production. Hyperledger is, all being said, an open source community. I would really love to see people diving in and working out the "how" and then rolling up sleeves to help drive the implementation of their thinking.

  • There has been no support to bring "consistent technical principles". Working Groups and other cross-dlt areas where such work should take place are languishing and there are many actively campaigning against WGs. However this again has nothing to do with whether we should approve Besu or not.

The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.

Agree, no one is campaigning against WGs, per se. The discussion of WGs is more about making WGs *more relevant* to the projects so that the project contributors and maintainers might pay them more attention and participate, meaningfully to the benefit of the projects and the broader community.

  • HL is unique in its sheltering  of multiple DLT solutions, there is no comparable consortium and we are inventing the integrative concepts around such co-opetition. I am also an advocate of a full offering (integrating documentation, deployment, operational support, simple and intuitive UIs, adherence to regulation demonstrable with security audits, monitoring and self-healing),  having had some experience importing dlt solutions into highly regulated enterprises. 

To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.

...

  • The arrival of new projects into Hyperledger, especially something backed by large networks who are new to Hyperledger will stimulate work in all areas. When there is competition, people will be forced to improve their offerings to stay relevant.

But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.

...

  • In short, I am against holding Besu to a different standard than the existing platforms in Hyperledger. Let us be consistent. Getting new blood and new ideas into HL will make a difference in existing dlts as well. The new entrants may revive interest in cross-dlt efforts like the working groups and SIGs. 

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

Agreed. I've been struggling with this. I think that there's positive benefit to bringing the Hyperledger and Ethereum communities closer together in the hopes that kumbayah. Though, I don't necessarily think that there will ever be one DLT to rule them all, and in the darkness bind them. What I DO think that Hyperledger needs to sort out is how it positions and promotes its projects. Right now, there is a considerable amount of overlap/redundancy, and it can be difficult at best to try to articulate to the general public how the projects are differentiated from one another. Further, during any project's life-cycle there's a great deal of effort expended to raise its voice above the din, to get people to kick the tires and maybe get more interested/invested.

I'm fine if Hyperledger is to become the Apache-for-Enterprise-Blockchain-and-DLTs, but note that Apache marketing is about promoting Apache and the Apache Way, not Hadoop, Kafka, Maven, Tomcat, or OpenWhisk.

Brian and Jessica have a difficult job, just as any parents with multiple offspring. Each child is special yet loved and nurtured equally. When someone asks a parent which child they love more, the correct response is "all of them". So, what should be the Hyperledger response when asked by press and analysts which of its projects is better, the correct answer needs to be "judge for yourself, we support them all equally". Yet, in this ultra-competitive landscape there is a natural tendency for press and analysts to look for differentiation, conflict and adoption to inform their audiences (and drive clicks). How do we enable the projects to make their case if they are promoted as equals?

Where am I going with all of this? I think we need to collectively (with the Board and Marketing) address the question that Shawn posed: "What is Hyperledger?". If Hyperledger is indeed to be a "greenhouse" or "umbrella" organization where open source blockchain/dlt for enterprise is developed - taking its cue from Apache. Then, I think we need to come to terms with two things:

1) what we want to be the "Hyperledger Way", and
2) how projects are marketed

I think there's much to be learned from the success of Apache and Eclipse, both of which are home to hundreds of projects, some overlapping/competing, some collaborative integrate-able components that fit a given framework. It could be just about creating a "safe place to innovate", as I like to say. It could be about encouraging growth of community(s) around projects. It could be about defining a single compose-able framework for DLTs shepherded by a collection of WGs that do top-down architecture overseen by the TSC.

However, whatever we choose, we then need to sort out how (or whether) we market the projects via Hyperledger or, allow the projects to manage their own messaging.


-Shawn



Re: Hyperledger Besu Proposal is Live

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

Jonathan, Silas, all,

 

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

 

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

 

Cheers,

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

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

M: +44 7764 666821 | T: @gendal

richard@... . www.r3.com

 

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

 

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

 

(Typing from and old and dusty mobile)

 

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

<jonathan@...> wrote:

Hi everybody,

 

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

 

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

 

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

 

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

 

---- 

 

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

 

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

 

How did we get there? TOGETHER.

 

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

 

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

 

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

 

-----

 

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

 

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

 

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

 

Thanks again everyone.

 

Jonathan Levi

 

 

 

 

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

Hi all,

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

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

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

Cheers.

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




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





comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
Hi Jon,
Thanks for the thoughtful response.

  • Pluggable consensus has been in active discussion in the Architecture working group. Unfortunately participation in such cross dlt architectural conversations has dropped, at least under the aegis of the AWG. We have had conversations of how to reboot the WGs and you should join the conversation.

We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.

I would agree with Shawn, here. There could be a bit more alignment, across projects but we do have plug-able consensus. However, I will remind people that code doesn't write itself, and no one ever shipped an architecture diagram/paper into production. Hyperledger is, all being said, an open source community. I would really love to see people diving in and working out the "how" and then rolling up sleeves to help drive the implementation of their thinking.

  • There has been no support to bring "consistent technical principles". Working Groups and other cross-dlt areas where such work should take place are languishing and there are many actively campaigning against WGs. However this again has nothing to do with whether we should approve Besu or not.

The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.

Agree, no one is campaigning against WGs, per se. The discussion of WGs is more about making WGs *more relevant* to the projects so that the project contributors and maintainers might pay them more attention and participate, meaningfully to the benefit of the projects and the broader community.

  • HL is unique in its sheltering  of multiple DLT solutions, there is no comparable consortium and we are inventing the integrative concepts around such co-opetition. I am also an advocate of a full offering (integrating documentation, deployment, operational support, simple and intuitive UIs, adherence to regulation demonstrable with security audits, monitoring and self-healing),  having had some experience importing dlt solutions into highly regulated enterprises. 

To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.

...

  • The arrival of new projects into Hyperledger, especially something backed by large networks who are new to Hyperledger will stimulate work in all areas. When there is competition, people will be forced to improve their offerings to stay relevant.

But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.

...

  • In short, I am against holding Besu to a different standard than the existing platforms in Hyperledger. Let us be consistent. Getting new blood and new ideas into HL will make a difference in existing dlts as well. The new entrants may revive interest in cross-dlt efforts like the working groups and SIGs. 

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

Agreed. I've been struggling with this. I think that there's positive benefit to bringing the Hyperledger and Ethereum communities closer together in the hopes that kumbayah. Though, I don't necessarily think that there will ever be one DLT to rule them all, and in the darkness bind them. What I DO think that Hyperledger needs to sort out is how it positions and promotes its projects. Right now, there is a considerable amount of overlap/redundancy, and it can be difficult at best to try to articulate to the general public how the projects are differentiated from one another. Further, during any project's life-cycle there's a great deal of effort expended to raise its voice above the din, to get people to kick the tires and maybe get more interested/invested.

I'm fine if Hyperledger is to become the Apache-for-Enterprise-Blockchain-and-DLTs, but note that Apache marketing is about promoting Apache and the Apache Way, not Hadoop, Kafka, Maven, Tomcat, or OpenWhisk.

Brian and Jessica have a difficult job, just as any parents with multiple offspring. Each child is special yet loved and nurtured equally. When someone asks a parent which child they love more, the correct response is "all of them". So, what should be the Hyperledger response when asked by press and analysts which of its projects is better, the correct answer needs to be "judge for yourself, we support them all equally". Yet, in this ultra-competitive landscape there is a natural tendency for press and analysts to look for differentiation, conflict and adoption to inform their audiences (and drive clicks). How do we enable the projects to make their case if they are promoted as equals?

Where am I going with all of this? I think we need to collectively (with the Board and Marketing) address the question that Shawn posed: "What is Hyperledger?". If Hyperledger is indeed to be a "greenhouse" or "umbrella" organization where open source blockchain/dlt for enterprise is developed - taking its cue from Apache. Then, I think we need to come to terms with two things:

1) what we want to be the "Hyperledger Way", and
2) how projects are marketed

I think there's much to be learned from the success of Apache and Eclipse, both of which are home to hundreds of projects, some overlapping/competing, some collaborative integrate-able components that fit a given framework. It could be just about creating a "safe place to innovate", as I like to say. It could be about encouraging growth of community(s) around projects. It could be about defining a single compose-able framework for DLTs shepherded by a collection of WGs that do top-down architecture overseen by the TSC.

However, whatever we choose, we then need to sort out how (or whether) we market the projects via Hyperledger or, allow the projects to manage their own messaging.


-Shawn



2019-09-05 TSC meeting minutes are up

Dave Huseby <dhuseby@...>
 

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Congratulations to the members of the 2019-2020 TSC!

Ry Jones
 

Angelo De Caro
Arnaud J Le Hors
Christopher Ferris
Dan Middleton
Gari Singh
Hart Montgomery
Mark Wagner
Nathan George
Swetha Repakula
Tracy Kuhrt
Troy Ronda


--
Ry Jones
Community Architect, Hyperledger


Re: FW: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #tsc-wg-update #cal-notice

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

Typo Sept 5 not 6.

 

From: <tsc@...> on behalf of Dan Middleton <dan.middleton@...>
Date: Thursday, September 5, 2019 at 2:50 PM
To: Sofia Terzi <sterzi@...>, "tsc@..." <tsc@...>
Cc: "Community-architects@..." <Community-architects@...>
Subject: Re: [Hyperledger TSC] FW: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #cal-notice

 

Hi,

Thanks for the update. I guess there may be a paste artifact in the reminder notification.

The TSC is indeed scheduled to meet today Sept 5. Generally we review these updates offline and if there is not sufficient time in the meeting we may forego verbal review. Also typically that offline review happens in the days leading up to the meeting. As such, it’s unlikely that it will be widely reviewed by the TSC before today’s meeting.

 

Thanks,

Dan

 

From: <tsc@...> on behalf of Sofia Terzi <sterzi@...>
Date: Thursday, September 5, 2019 at 2:12 PM
To: "tsc@..." <tsc@...>
Cc: "Community-architects@..." <Community-architects@...>
Subject: [Hyperledger TSC] FW: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #cal-notice

 

Hi everybody,

 

I received this notification about the SC WG’s report presentation which apart from the wrong title (SC WG China??) it mentions that the presentation to the TSC is on 6 September. Is this right? Because as far as I know the TSC’s meeting is today. Please confirm which is the right day/time. You can find the report here https://wiki.hyperledger.org/display/HYP/2019+Q2+Smart+Contracts+WG

 

Thank you,

Sofia

 

---------------------------------------------------------------------

Sofia Terzi | Blockchain Solutions Architect MSc.

[Email] <sterzi@...>

[CERTH-ITI] <https://www.iti.gr/iti/index.html>

 

 

 

From: smart-contracts-wg@... <smart-contracts-wg@...> On Behalf Of smart-contracts-wg@... Calendar
Sent: Thursday, September 5, 2019 10:00 AM
To: smart-contracts-wg@...
Subject: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #cal-notice

 

Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update

When:
Thursday, 5 September 2019

Organizer:
community-architects@...

Description:
The Hyperledger Smart Contracts WG update to the TSC is due 3 September, 2019. Please be sure that someone from the community completes the update and is available to present it to the TSC on 6 September, 2019. Please follow this link to create the update.


Re: FW: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #tsc-wg-update #cal-notice

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

Hi,

Thanks for the update. I guess there may be a paste artifact in the reminder notification.

The TSC is indeed scheduled to meet today Sept 6. Generally we review these updates offline and if there is not sufficient time in the meeting we may forego verbal review. Also typically that offline review happens in the days leading up to the meeting. As such, it’s unlikely that it will be widely reviewed by the TSC before today’s meeting.

 

Thanks,

Dan

 

From: <tsc@...> on behalf of Sofia Terzi <sterzi@...>
Date: Thursday, September 5, 2019 at 2:12 PM
To: "tsc@..." <tsc@...>
Cc: "Community-architects@..." <Community-architects@...>
Subject: [Hyperledger TSC] FW: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #cal-notice

 

Hi everybody,

 

I received this notification about the SC WG’s report presentation which apart from the wrong title (SC WG China??) it mentions that the presentation to the TSC is on 6 September. Is this right? Because as far as I know the TSC’s meeting is today. Please confirm which is the right day/time. You can find the report here https://wiki.hyperledger.org/display/HYP/2019+Q2+Smart+Contracts+WG

 

Thank you,

Sofia

 

---------------------------------------------------------------------

Sofia Terzi | Blockchain Solutions Architect MSc.

[Email] <sterzi@...>

[CERTH-ITI] <https://www.iti.gr/iti/index.html>

 

 

 

From: smart-contracts-wg@... <smart-contracts-wg@...> On Behalf Of smart-contracts-wg@... Calendar
Sent: Thursday, September 5, 2019 10:00 AM
To: smart-contracts-wg@...
Subject: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #cal-notice

 

Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update

When:
Thursday, 5 September 2019

Organizer:
community-architects@...

Description:
The Hyperledger Smart Contracts WG update to the TSC is due 3 September, 2019. Please be sure that someone from the community completes the update and is available to present it to the TSC on 6 September, 2019. Please follow this link to create the update.


FW: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #tsc-wg-update #cal-notice

Sofia Terzi
 

Hi everybody,

 

I received this notification about the SC WG’s report presentation which apart from the wrong title (SC WG China??) it mentions that the presentation to the TSC is on 6 September. Is this right? Because as far as I know the TSC’s meeting is today. Please confirm which is the right day/time. You can find the report here https://wiki.hyperledger.org/display/HYP/2019+Q2+Smart+Contracts+WG

 

Thank you,

Sofia

 

---------------------------------------------------------------------

Sofia Terzi | Blockchain Solutions Architect MSc.

[Email] <sterzi@...>

[CERTH-ITI] <https://www.iti.gr/iti/index.html>

 

 

 

From: smart-contracts-wg@... <smart-contracts-wg@...> On Behalf Of smart-contracts-wg@... Calendar
Sent: Thursday, September 5, 2019 10:00 AM
To: smart-contracts-wg@...
Subject: [Hyperledger Smart Contracts WG] Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update - Thu, 09/05/2019 #cal-notice

 

Hyperledger Smart Contracts WG China Quarterly Update Due #tsc-wg-update

When:
Thursday, 5 September 2019

Organizer:
community-architects@...

Description:
The Hyperledger Smart Contracts WG update to the TSC is due 3 September, 2019. Please be sure that someone from the community completes the update and is available to present it to the TSC on 6 September, 2019. Please follow this link to create the update.


2019-08-29 TSC meeting minutes are up

Dave Huseby <dhuseby@...>
 


Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

1241 - 1260 of 3892