[prev in list] [next in list] [prev in thread] [next in thread]
List: hyperledger-tsc
Subject: Re: [Hyperledger TSC] technical implications of the EEA arrangement ?
From: "Brian Behlendorf" <bbehlendorf () linuxfoundation ! org>
Date: 2018-10-11 7:16:31
Message-ID: 17045fea-e78a-4e67-e365-64423d92552f () linuxfoundation ! org
[Download RAW message or body]
Sorry I didn't get to writing this note earlier; I certainly should have
followed up the announcement on Monday with a message here so that folks
understood better what it meant. It's been a busy few weeks for us.
I want to start with what motivated us to work on this:
1) Hyperledger's use of Ethereum-related standards has been active now
for over a year. Contributions to Burrow are growing, and we have the
Private Data Objects work in Labs that is being developed in parallel to
a related spec at EEA (Mick, hope I characterized that right). There
are other pieces of the Ethereum ecosystem where bridgebuilding is going
on, and even where more spec work is interesting - I was just at
Trufflecon on Saturday morning, actually, as they announced support for
developing to Sawtooth and Fabric. But people love a horserace, and
they'd locked in their heads that the big decision was a binary
"Hyperledger vs. Ethereum", when the reality was much more nuanced.
That nuance matters as I felt like this misunderstanding sharpened the
tribalism that the blockchain world already suffers from, and could keep
both contributors and new projects out of Hyperledger that we'd really
like to be able to work with. So we wanted to get closer to how those
standards are being developed in a more formal way, and signaling to the
public that this was a good thing.
2) It's important, some people feel, to cleanly separate the development
of standards from the development of open source software that
implements those standards. IETF/Apache httpd, for instance. When I
arrived at Hyperledger I talked to everyone in the community (it was a
bit smaller then) to see what they thought we should be, and how big our
tent should be. From those conversations it became clear we were
builders, and should be a home for a well-curated portfolio of
frameworks and tools that are best-of-breed. While EEA had been formed
with the idea that it might do both standards and implementation, when
Ron joined it was clear to me (both because of his background) that EEA
would focus on standards, and through that to platform certification,
etc. We are complementary and it's worth letting people know that - not
least if it helps bring more devs to Burrow etc., and maybe new activity
in Labs or as a full fledged project for folks interested in
implementing an EEA spec.
3) We also wanted to very clearly indicate that our Ethereum-related
work was not related to the cryptocurrency token, ETH. Ethereum is
challenged by the fact that the same trademark/brand is associated with
three very different things: a set of standards (EEA's terrain w/r/t
"enterprise" needs), a set of implementations (which should be more
properly called "Geth", "Parity", etc when people deploy them) and
tokens. All this makes it challenging to talk about the value of this
to enterprises. I've noted to Ron that all this would be a lot easier if
they'd been called the Enterprise Blockchain Standards Alliance or
something :) But it also became clear when they published the 1.0 spec
that they're not mandating use of ETH in enterprise deployments, or
doing other things that might unnecessarily tie conformant
implementations to the ETH network, even if the specs come out of
activity driven by engagement with main-net. Some of their community
may see the Ethereum main-net as a backbone network between enterprise
side-chains, but that does not (yet!) seem to have hobbled the
specifications developed so far. Worth keeping an eye on this of course.
4) We should not be too comfortable in our permissioned-ledger world and
believe we have nothing to learn from the unpermissioned-ledger world.
As our enterprise networks get larger and larger (which they should -
the value of a network at small and mid sizes is still the square of the
sum of the nodes/participants) it may be that they look and act more
like public networks. There's useful experiments happening with
consensus mechanisms (like Proof of Authority and Proof of Stake), smart
contracts, etc., that we should be tracking. A relationship with EEA is
one potential funnel for those ideas, in both directions.
So now let's talk about what it means for us:
1) Only Hyperledger itself (well, technically, the Linux Foundation) and
EEA itself have joined each other's organizations, at no cost. We have
a number of such relationships in our Associate Member category,
reserved for non-profits, universities, government agencies, and other
consortia with whom we generally have a sense we'll be working with in
some way, either to recruit more developers, develop great use cases or
other content, etc. When a consortium joins Hyperledger, the benefits of
membership (participation in our own members-only events, like the
Member Summit) confer only to employees or specific named people at that
organization - it's not open to their members as well. And likewise,
the agreement we signed with EEA regarding benefits, IP arrangements,
etc., are between LF/HL staff and EEA, not our members by proxy. This
means if any of you want to participate in EEA's processes that are
limited to members, you need to join them as a member.
2) Nothing in this relationship is exclusive - there are other standards
bodies we can bring specs to or implement from, and likewise I don't
expect that suddenly there'll be a wave of new projects/labs or that all
EEA specs will get an implementation as a corresponding project at HL.
That's all up to you to make the call, and if there's no value to
implementing an EEA spec or proposing a new spec to them, then it won't
happen. If you want to see us develop similar relationships with any
other standards efforts, I'd be happy to chat about that further.
3) EEA is like many other standards bodies, such as W3C, ISO, and
others, where membership is required to participate in some technical
work. ISO has in particular TC307 which I know some of you participate
in, and which has public artifacts but private conversations (it
seems). I was more or less literally raised on an IETF WG mailing list,
so I am much more inclined towards open processes for the development of
specifications, and why I'm so proud that Hyperledger is different here
I'm hoping we can nudge EEA in that direction, if only to help ensure
EEA's standards receive wider scrutiny and improvement, but also it's
because enterprises are growing more and more comfortable with more open
processes anyways. We know from our own community discussions how
challenging being as open as we are can be. But we can work with what
EEA have now while encouraging them further.
4) My initial plan is to have a Hyperledger staff member (likely Tracy,
Ry, or future hires in their group) participate in the larger
conversations or gatherings, and we'll make a case by case call on more
specifics. If they feel there are issues of relevance to the
Hyperledger community, they'll bring that back to the rest of us. There
may be other staff I put on if EEA processes go into more marketing
kinds of areas. We'll be proactive here, and relay some questions on to
you as appropriate.
When working on this relationship I did engage many of the people on
this list, as well as others in our membership, and more, mostly 1:1,
because the issues here can be a bit complicated, and this is still
relatively the beginnings of something than a finished accomplishment.
At the end both their board and our Governing Board agreed to the
relationship. It could not be a more public process just given the
sensitivities. Of course I feel differently about debates about code :)
EEA is younger than Hyperledger, and Ron has had a busy 9 months pulling
things together from a very amorphous beginning. Let's operate from an
assumption of the best of intentions on both sides.
Looking forward to more discussion on this in a few hours on the TSC call.
Brian
On 10/08/2018 08:44 AM, mark wagner wrote:
>
> Hi
>
> I think it would be very pragmatic for the TSC to discuss and
> understand if there are technical implications on Hyperledger efforts
> given the new relationship with EEA.
>
> Do other members feel the same ?
> Is it worth adding to the agenda of a future TSC call ?
>
> -mark
>
> --
> Mark Wagner
> Senior Principal Software Engineer
> Performance and Scalability
> Red Hat, Inc
>
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1725): https://lists.hyperledger.org/g/tsc/message/1725
Mute This Topic: https://lists.hyperledger.org/mt/26875903/953895
Group Owner: tsc+owner@lists.hyperledger.org
Unsubscribe: https://lists.hyperledger.org/g/tsc/unsub [hyperledger-tsc@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Sorry I didn't get to writing this note
earlier; I certainly should have followed up the announcement on
Monday with a message here so that folks understood better what it
meant. It's been a busy few weeks for us.<br>
<br>
I want to start with what motivated us to work on this:<br>
<br>
1) Hyperledger's use of Ethereum-related standards has been active
now for over a year. Contributions to Burrow are growing, and we
have the Private Data Objects work in Labs that is being developed
in parallel to a related spec at EEA (Mick, hope I characterized
that right). There are other pieces of the Ethereum ecosystem
where bridgebuilding is going on, and even where more spec work is
interesting - I was just at Trufflecon on Saturday morning,
actually, as they announced support for developing to Sawtooth and
Fabric. But people love a horserace, and they'd locked in their
heads that the big decision was a binary "Hyperledger vs.
Ethereum", when the reality was much more nuanced. That nuance
matters as I felt like this misunderstanding sharpened the
tribalism that the blockchain world already suffers from, and
could keep both contributors and new projects out of Hyperledger
that we'd really like to be able to work with. So we wanted to
get closer to how those standards are being developed in a more
formal way, and signaling to the public that this was a good
thing.<br>
<br>
2) It's important, some people feel, to cleanly separate the
development of standards from the development of open source
software that implements those standards. IETF/Apache httpd, for
instance. When I arrived at Hyperledger I talked to everyone in
the community (it was a bit smaller then) to see what they thought
we should be, and how big our tent should be. From those
conversations it became clear we were builders, and should be a
home for a well-curated portfolio of frameworks and tools that are
best-of-breed. While EEA had been formed with the idea that it
might do both standards and implementation, when Ron joined it was
clear to me (both because of his background) that EEA would focus
on standards, and through that to platform certification, etc. We
are complementary and it's worth letting people know that - not
least if it helps bring more devs to Burrow etc., and maybe new
activity in Labs or as a full fledged project for folks interested
in implementing an EEA spec.<br>
<br>
3) We also wanted to very clearly indicate that our
Ethereum-related work was not related to the cryptocurrency token,
ETH. Ethereum is challenged by the fact that the same
trademark/brand is associated with three very different things: a
set of standards (EEA's terrain w/r/t "enterprise" needs), a set
of implementations (which should be more properly called "Geth",
"Parity", etc when people deploy them) and tokens. All this makes
it challenging to talk about the value of this to enterprises.
I've noted to Ron that all this would be a lot easier if they'd
been called the Enterprise Blockchain Standards Alliance or
something :) But it also became clear when they published the 1.0
spec that they're not mandating use of ETH in enterprise
deployments, or doing other things that might unnecessarily tie
conformant implementations to the ETH network, even if the specs
come out of activity driven by engagement with main-net. Some of
their community may see the Ethereum main-net as a backbone
network between enterprise side-chains, but that does not (yet!)
seem to have hobbled the specifications developed so far. Worth
keeping an eye on this of course.<br>
<br>
4) We should not be too comfortable in our permissioned-ledger
world and believe we have nothing to learn from the
unpermissioned-ledger world. As our enterprise networks get
larger and larger (which they should - the value of a network at
small and mid sizes is still the square of the sum of the
nodes/participants) it may be that they look and act more like
public networks. There's useful experiments happening with
consensus mechanisms (like Proof of Authority and Proof of Stake),
smart contracts, etc., that we should be tracking. A relationship
with EEA is one potential funnel for those ideas, in both
directions.<br>
<br>
So now let's talk about what it means for us:<br>
<br>
1) Only Hyperledger itself (well, technically, the Linux
Foundation) and EEA itself have joined each other's organizations,
at no cost. We have a number of such relationships in our
Associate Member category, reserved for non-profits, universities,
government agencies, and other consortia with whom we generally
have a sense we'll be working with in some way, either to recruit
more developers, develop great use cases or other content, etc.
When a consortium joins Hyperledger, the benefits of membership
(participation in our own members-only events, like the Member
Summit) confer only to employees or specific named people at that
organization - it's not open to their members as well. And
likewise, the agreement we signed with EEA regarding benefits, IP
arrangements, etc., are between LF/HL staff and EEA, not our
members by proxy. This means if any of you want to participate in
EEA's processes that are limited to members, you need to join them
as a member.<br>
<br>
2) Nothing in this relationship is exclusive - there are other
standards bodies we can bring specs to or implement from, and
likewise I don't expect that suddenly there'll be a wave of new
projects/labs or that all EEA specs will get an implementation as
a corresponding project at HL. That's all up to you to make the
call, and if there's no value to implementing an EEA spec or
proposing a new spec to them, then it won't happen. If you want
to see us develop similar relationships with any other standards
efforts, I'd be happy to chat about that further.<br>
<br>
3) EEA is like many other standards bodies, such as W3C, ISO, and
others, where membership is required to participate in some
technical work. ISO has in particular TC307 which I know some of
you participate in, and which has public artifacts but private
conversations (it seems). I was more or less literally raised on
an IETF WG mailing list, so I am much more inclined towards open
processes for the development of specifications, and why I'm so
proud that Hyperledger is different here I'm hoping we can nudge
EEA in that direction, if only to help ensure EEA's standards
receive wider scrutiny and improvement, but also it's because
enterprises are growing more and more comfortable with more open
processes anyways. We know from our own community discussions how
challenging being as open as we are can be. But we can work with
what EEA have now while encouraging them further. <br>
<br>
4) My initial plan is to have a Hyperledger staff member (likely
Tracy, Ry, or future hires in their group) participate in the
larger conversations or gatherings, and we'll make a case by case
call on more specifics. If they feel there are issues of
relevance to the Hyperledger community, they'll bring that back to
the rest of us. There may be other staff I put on if EEA
processes go into more marketing kinds of areas. We'll be
proactive here, and relay some questions on to you as appropriate.<br>
<br>
When working on this relationship I did engage many of the people
on this list, as well as others in our membership, and more,
mostly 1:1, because the issues here can be a bit complicated, and
this is still relatively the beginnings of something than a
finished accomplishment. At the end both their board and our
Governing Board agreed to the relationship. It could not be a
more public process just given the sensitivities. Of course I
feel differently about debates about code :)<br>
<br>
EEA is younger than Hyperledger, and Ron has had a busy 9 months
pulling things together from a very amorphous beginning. Let's
operate from an assumption of the best of intentions on both
sides.<br>
<br>
Looking forward to more discussion on this in a few hours on the
TSC call.<br>
<br>
Brian<br>
<br>
On 10/08/2018 08:44 AM, mark wagner wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHF+6Heq-43tWBkob5YhtRyjDhteTgX9jJSU+23E7jso0T_FmQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">
<div><br>
</div>
<div>Hi <br>
</div>
<div><br>
</div>
<div>I think it would be very pragmatic for the TSC to discuss
and understand if there are technical implications on
Hyperledger efforts given the new relationship with EEA. <br>
</div>
<div><br>
</div>
<div>Do other members feel the same ?</div>
<div>Is it worth adding to the agenda of a future TSC call ?</div>
<div><br>
</div>
<div>-mark<br>
</div>
<br>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div>
<div>Mark Wagner<br>
</div>
Senior Principal Software Engineer<br>
</div>
Performance and Scalability<br>
</div>
Red Hat, Inc<br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Brian Behlendorf
Executive Director, Hyperledger
<a class="moz-txt-link-abbreviated" \
href="mailto:bbehlendorf@linuxfoundation.org">bbehlendorf@linuxfoundation.org</a>
Twitter: @brianbehlendorf</pre>
</body>
</html>
<div width="1" style="color:white;clear:both">_._,_._,_</div>
<hr>
Links:<p>
You receive all messages sent to this group.
<p>
<a target="_blank" href="https://lists.hyperledger.org/g/tsc/message/1725">View/Reply \
Online (#1725)</a> |
<a target="_blank" \
href="mailto:bbehlendorf@linuxfoundation.org?subject=Private:%20Re:%20Re%3A%20%5BHyper \
ledger%20TSC%5D%20technical%20implications%20of%20the%20EEA%20arrangement%20%3F">Reply \
To Sender</a>
| <a target="_blank" \
href="mailto:tsc@lists.hyperledger.org?subject=Re:%20Re%3A%20%5BHyperledger%20TSC%5D%20technical%20implications%20of%20the%20EEA%20arrangement%20%3F">Reply \
To Group</a>
>
<a target="_blank" href="https://lists.hyperledger.org/mt/26875903/953895">Mute \
This Topic</a>
> <a href="https://lists.hyperledger.org/g/tsc/post">New Topic</a><br>
<br>
<a href="https://lists.hyperledger.org/g/tsc/editsub/953895">Your Subscription</a> |
<a href="mailto:tsc+owner@lists.hyperledger.org">Contact Group Owner</a> |
<a href="https://lists.hyperledger.org/g/tsc/unsub">Unsubscribe</a>
[hyperledger-tsc@marc.info]<br>
<div width="1" style="color:white;clear:both">_._,_._,_</div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic