|
Re: [Hyperledger Composer] Deprecation of Composer
Krupal_Agileinfoways <krupal.shah@...>
Hello, It is unfortunate that you have deprecated composer toolchain. With the increasing number of frameworks, shall we also assume deprecation of some frameworks as well? We can see most frameworks other than Fabric and Sawtooth are useless. Is there any explanation for such useless fragmentation?
Thanks & Regards, Krupal Shah Sr. Software Developer
|
Sender notified by
Mailtrack
08/29/19, 5:53:26 PM
|
|
On Wed, 28 Aug 2019 at 18:14, Simon Stone < 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
|
|
|
Re: FAQ: What does Condorcet mean by "your ballot will be visible"?
Ry Jones
I plan on a new, public git repo with the data that I have available once the election concludes.
On Thu, Aug 29, 2019 at 5:15 AM VIPIN BHARATHAN < vip@...> wrote:
Hi Ry/Brian,
In the interests of transparency, the final turnout should be released. Also tracking this during the election and nudging people to vote will increase the turnout. Voter apathy is a real issue in most elections. We will never know
whether apathy is an issue in TSC elections unless we know the turnout.
As this is an aggregate figure, privacy will still be preserved.
Best,
Vipin
The page that you vote on says:
Your ballot (the rankings you assign to choices) will be visible in the poll results when the poll ends.
This has caused confusion. I cannot see your specific ballots; the email says:
Your privacy will not be violated by voting. The voting service has already destroyed the record of your email address and will not release any information about whether or how you have voted.
Here is what I see in the UI, which makes this more clear:
Write-in choices are not allowed.
Detailed ballot reporting is enabled.
Voter identities will be kept anonymous
I only know in aggregate how many eligible voters there are, and how many have voted. I do not know, and cannot tell, who has voted or how they have voted.
Ry
--
Ry Jones
Community Architect, Hyperledger
-- Ry Jones Community Architect, Hyperledger
|
|
|
Re: Hyperledger Besu Proposal is Live
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: FAQ: What does Condorcet mean by "your ballot will be visible"?
VIPIN BHARATHAN
Hi Ry/Brian,
In the interests of transparency, the final turnout should be released. Also tracking this during the election and nudging people to vote will increase the turnout. Voter apathy is a real issue in most elections. We will never know
whether apathy is an issue in TSC elections unless we know the turnout.
As this is an aggregate figure, privacy will still be preserved.
Best,
Vipin
From: tsc@... <tsc@...> on behalf of Ry Jones via Lists.Hyperledger.Org <rjones=linuxfoundation.org@...>
Sent: Thursday, August 29, 2019 12:54:03 AM
To: TSC <tsc@...>
Cc: tsc@... <tsc@...>
Subject: [Hyperledger TSC] FAQ: What does Condorcet mean by "your ballot will be visible"?
The page that you vote on says:
Your ballot (the rankings you assign to choices) will be visible in the poll results when the poll ends.
This has caused confusion. I cannot see your specific ballots; the email says:
Your privacy will not be violated by voting. The voting service has already destroyed the record of your email address and will not release any information about whether or how you have voted.
Here is what I see in the UI, which makes this more clear:
Write-in choices are not allowed.
Detailed ballot reporting is enabled.
Voter identities will be kept anonymous
I only know in aggregate how many eligible voters there are, and how many have voted. I do not know, and cannot tell, who has voted or how they have voted.
Ry
--
Ry Jones
Community Architect, Hyperledger
|
|
|
FAQ: What does Condorcet mean by "your ballot will be visible"?
Ry Jones
The page that you vote on says: Your ballot (the rankings you assign to choices) will be visible in the poll results when the poll ends.
This has caused confusion. I cannot see your specific ballots; the email says: Your privacy will not be violated by voting. The voting service has already destroyed the record of your email address and will not release any information about whether or how you have voted.
Here is what I see in the UI, which makes this more clear: Write-in choices are not allowed.
Detailed ballot reporting is enabled.
Voter identities will be kept anonymous
I only know in aggregate how many eligible voters there are, and how many have voted. I do not know, and cannot tell, who has voted or how they have voted.
Ry
-- Ry Jones Community Architect, Hyperledger
|
|
|
Middleton, Dan <dan.middleton@...>
Thanks, Lynn and Sam.
I’ve updated the agenda with the link.
Note we have a very full agenda this week and may not verbally review the project updates. TSC members will review them offline however and add any questions/comments on the form.
From: <tsc@...> on behalf of Lynn Bendixsen <lynn@...>
Date: Wednesday, August 28, 2019 at 5:23 PM
To: "tsc@... Calendar" <tsc@...>
Cc: Sam Curren <sam@...>
Subject: Re: [Hyperledger TSC] Upcoming Event: Hyperledger Aries Quarterly Update Due #tsc-project-update - Thu, 08/29/2019 #cal-reminder
Sam Curren has posted the Aries Q3 Update for review:
toggle quoted messageShow quoted text
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.
|
|
|
Lynn Bendixsen <lynn@...>
Sam Curren has posted the Aries Q3 Update for review:
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
|
|
|
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
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
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
|
|
|
TSC meeting minutes backlog: 2019-07-25 minutes are out
Dave Huseby <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
----- 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
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 PMSubject:
[EXTERNAL]
Re: [Hyperledger TSC] Hyperledger Besu Proposal is LiveSent
by: tsc@...
comments in-lined, below.
toggle quoted messageShow quoted text
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", and2) how projects are marketedI 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
----- 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
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.
|
|
|
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
----- 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
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.
|
|
|
Re: TSC 2019-2020 Nominee slate
Many thanks for blazingly quick turnaround time here Ry !
Jonathan
|
|
|
