Date   

Re: Transact as a TLP

Duncan Johnston-Watt
 

Danno

I don't think long term Hyperledger can afford to be a "Not Collaborated Here" venture.  That limits its relevance, scope, and impact tht Hyplereder could provice to the whole DLT/Blockchain/Distributed Computing space.  I strongly feel there needs to be room for projects that are primarily Hyperledger focused, projects that are simply Hyperledger homed, and all the gradients in between.

+1

Best

Duncan

On Sat, Sep 5, 2020 at 6:19 AM Danno Ferrin <danno.ferrin@...> wrote:


On Fri, Sep 4, 2020 at 8:01 PM Brian Behlendorf <bbehlendorf@...> wrote:

And hey, it's 2020, and not even ICO-funded Swiss shell corps have piles of money to spend reinventing wheels and duplicating efforts.

A number of them actually do have the "money."  The next issue they run into is engineering resources: there is a limited supply of engineers that are (a) good enough (b) willing to work in crypto/DLT/blockchain and (c) aren't total narcissists.  Even without a Code of Conduct such behavior gets in the way of successful projects. Not a dig on our CoC, we need to establish boundaries and it provides a touchpoint when boundary enforcement is required. 

Be careful where you look on crypto-twitter and various crypto reddits.  It will make your eyes bleed and our struggles in HL pale by comparison.  No one at HL has sent each other death threats (not hyperbole).  We are not perfect in the way we deal with each other but with that perspective you can see we are doing fairly well.

So for those who want to be involved in those design decisions around Transact - where do they go? Whether I go to the wiki page, the mailing list, or the RocketChat channel, I don't see those discussions, despite those being listed in the Transact README.md as the place to go. The Kanban page isn't a useful way to see design discussions, it's a way to prioritize work already agreed upon. It looks and feels like the actual discussions and work are taking place elsewhere, hidden?, with the community tools used as an after-development way to get feedback from end-users. The cheerful Q3 report doesn't give any clues either. With Grid it's the same deal - I'm quite encouraged by that community call, but again, the Wiki, the mailing list, and the RocketChat channel all leave the impression that the real work is happening elsewhere. To even find the agenda for the Grid meeting I had to go scroll up in the Rocketchat channel, and then, who knows what the results of that meeting were? I want to be wrong about all this, that I missed a memo on where these discussions are happening - what am I missing? 

This brings up an existential question: how much of this collaboration must occur in Hyperledger forums? Some part of it should but how far should we go to force it? For Besu this is not an abstract question.  Basically none of the future of ethereum is planned in Hyperledger forums, instead it's a series of discord servers, message boards, gitter rooms, and twitter threads.  Yes, at least one critical decision was made as a consequence of Twitter threads.  But for better or worse that is the way it is.  Our maintainers can't afford to focus on just HL arenas and must interact outside of the tower to keep up with our mandate of being a mainnet capable enterprise blockchain.

I don't think long term Hyperledger can afford to be a "Not Collaborated Here" venture.  That limits its relevance, scope, and impact tht Hyplereder could provice to the whole DLT/Blockchain/Distributed Computing space.  I strongly feel there needs to be room for projects that are primarily Hyperledger focused, projects that are simply Hyperledger homed, and all the gradients in between.



--
Duncan Johnston-Watt
CEO, BTP

Twitter: @duncanjw


Re: Transact as a TLP

Danno Ferrin <danno.ferrin@...>
 



On Fri, Sep 4, 2020 at 8:01 PM Brian Behlendorf <bbehlendorf@...> wrote:

And hey, it's 2020, and not even ICO-funded Swiss shell corps have piles of money to spend reinventing wheels and duplicating efforts.

A number of them actually do have the "money."  The next issue they run into is engineering resources: there is a limited supply of engineers that are (a) good enough (b) willing to work in crypto/DLT/blockchain and (c) aren't total narcissists.  Even without a Code of Conduct such behavior gets in the way of successful projects. Not a dig on our CoC, we need to establish boundaries and it provides a touchpoint when boundary enforcement is required. 

Be careful where you look on crypto-twitter and various crypto reddits.  It will make your eyes bleed and our struggles in HL pale by comparison.  No one at HL has sent each other death threats (not hyperbole).  We are not perfect in the way we deal with each other but with that perspective you can see we are doing fairly well.

So for those who want to be involved in those design decisions around Transact - where do they go? Whether I go to the wiki page, the mailing list, or the RocketChat channel, I don't see those discussions, despite those being listed in the Transact README.md as the place to go. The Kanban page isn't a useful way to see design discussions, it's a way to prioritize work already agreed upon. It looks and feels like the actual discussions and work are taking place elsewhere, hidden?, with the community tools used as an after-development way to get feedback from end-users. The cheerful Q3 report doesn't give any clues either. With Grid it's the same deal - I'm quite encouraged by that community call, but again, the Wiki, the mailing list, and the RocketChat channel all leave the impression that the real work is happening elsewhere. To even find the agenda for the Grid meeting I had to go scroll up in the Rocketchat channel, and then, who knows what the results of that meeting were? I want to be wrong about all this, that I missed a memo on where these discussions are happening - what am I missing? 

This brings up an existential question: how much of this collaboration must occur in Hyperledger forums? Some part of it should but how far should we go to force it? For Besu this is not an abstract question.  Basically none of the future of ethereum is planned in Hyperledger forums, instead it's a series of discord servers, message boards, gitter rooms, and twitter threads.  Yes, at least one critical decision was made as a consequence of Twitter threads.  But for better or worse that is the way it is.  Our maintainers can't afford to focus on just HL arenas and must interact outside of the tower to keep up with our mandate of being a mainnet capable enterprise blockchain.

I don't think long term Hyperledger can afford to be a "Not Collaborated Here" venture.  That limits its relevance, scope, and impact tht Hyplereder could provice to the whole DLT/Blockchain/Distributed Computing space.  I strongly feel there needs to be room for projects that are primarily Hyperledger focused, projects that are simply Hyperledger homed, and all the gradients in between.


Re: Transact as a TLP

Brian Behlendorf
 

On 9/4/20 11:49 AM, Shawn Amundson wrote:
On Fri, Sep 4, 2020 at 3:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
...

But then... that enthusiasm seemed to fizzle. Like any such collaborative process [...]

Enthusiasm among those involved in Transact hasn't fizzled. Quite the opposite, since Sawtooth is at warp-speed right now integrating it (Sawtooth will be the 2nd DLT to use Transact, after Scabbard),

To be clear, it wasn't a statement about Transact as a project - I went out of my way to note that there is a healthy development clip to Transact for a young project. What didn't materialize - perhaps that's a more neutral term than fizzled - was a clear process for designing Transact as a bridge specifically for the other DLTs at Hyperledger. That was what I read coming out of the Maintainer Summit, and the basis for its accelerated approval as a TLP, and that's the momentum that felt lost. Apologies that I wasn't clear.

I challenge the assertion that the success of Transact should be defined by the participation of the Fabric team.  The Fabric team loses out on extending its overall engineering capability by maintaining a walled-garden approach. At the end of the day though, it is a hard sell - Fabric is a Go project and we have a Rust library.

Indeed, this has hobbled Fabric's potential adoption of Ursa too, and our attempts to standardize and make it easier/more foolproof to adopt modern cryptography. I still can't believe Go can't do what SWIG brought to pretty much every other programming language in like 2001. Go fans, am I wrong?

This is the kind of Technical Steering that the TSC could do, if it chose. Steering projects towards languages and architectures that encourage modularization and re-use. The selection of Go is hard to fault for having been made in 2015, and the Go client for Ethereum is clearly very successful. But It'd be really nice if the Fabric team could start thinking about whether portions of Fabric in languages other than Go would make sense going forward. Seeing Sawtooth move from Python to Rust and Iroha from C to Rust is really encouraging and I'm sure couldn't have been an easy decision. I see James made this point as well, thanks James!

Here lies the conundrum - in order to collaborate on the same code, so that we might save time/money/effort on common objectives, we have to spend more time/money/effort to get there. The calculus is challenging for sake of all the unknowns. There's a cost/benefit to engaging early in the lifecycle of something like Transact, if the architectures can adapt; versus later, when more unknowns are settled, but decisions are now more hard-coded. If there's one thing a TSC should be useful at, it's brokering the trust and conversations required to assist that calculus. Carrots, not sticks, to get to better alignment across Hyperledger. Because sticks fucking hurt.

And hey, it's 2020, and not even ICO-funded Swiss shell corps have piles of money to spend reinventing wheels and duplicating efforts. We all have to get better at building upon each other's work if we're going to survive what is clearly still a very long blockchain winter, and very few of the solutions in the market will survive it. My hope is that at least a few of the ones that do are at Hyperledger. There can be more than one :) but the case for their differentiation better be really, really strong, and they better share as much code as possible.

Transact is a fundamental piece of keeping Grid DLT-agnostic, so I assume this is an anti-Grid play overall, and everyone else is just sucked into the "objective" discussion.

Not that I can see, I'm personally pretty eager to see it succeed. By the way, other TSC listers, Grid recently restarted its regular calls, and had a decently well attended meeting that sounded pretty productive, including that they use the RFCs process other projects have started to adopt. Cool.

The original goal of creating a Rust library that can be used across DLTs remains. You are suggesting we aren't factoring these things in already, but you are incorrect as it is a normal part of design discussions to consider how different DLTs work.

Note that the pitch was somewhat different - not just an abstract notion that it could work across other DLTs, but specifically that it would aim to help the ones we already have at Hyperledger. That signaling was clear in the Google doc proposal, and I'm sure the basis of Gari and Chris's support for it as well.

So for those who want to be involved in those design decisions around Transact - where do they go? Whether I go to the wiki page, the mailing list, or the RocketChat channel, I don't see those discussions, despite those being listed in the Transact README.md as the place to go. The Kanban page isn't a useful way to see design discussions, it's a way to prioritize work already agreed upon. It looks and feels like the actual discussions and work are taking place elsewhere, hidden?, with the community tools used as an after-development way to get feedback from end-users. The cheerful Q3 report doesn't give any clues either. With Grid it's the same deal - I'm quite encouraged by that community call, but again, the Wiki, the mailing list, and the RocketChat channel all leave the impression that the real work is happening elsewhere. To even find the agenda for the Grid meeting I had to go scroll up in the Rocketchat channel, and then, who knows what the results of that meeting were? I want to be wrong about all this, that I missed a memo on where these discussions are happening - what am I missing?

Working in the public is extremely challenging. When the majority of your initial maintainer cohort physically sit in the same office and work for the same company, it's a nearly unavoidable outcome. We tortured the IBM Fabric team in Raleigh by sending Dave Huseby out to sit with them for a week to find ways to both nudge and force them to work in the public, and it paid off. It builds trust, it makes it easier to help people climb the learning curve without being a burden on the maintainers, it helps end users solve their issues, it helps avoid bikeshedding... the list goes on Working across projects gets even harder - the square of how hard it is for one project, perhaps?

This is the kind of community management the TSC could do, if it chose. The quarterly reports are the ideal time to be looking at these resources and asking these questions, and I fear we might be going too quickly through them. It can be done in a way that's intended to be helpful rather than judgemental, but it has to hold the maintainers accountable to a higher standard of what an Open Source project needs to be than any ol github repo on its own. So anyone reading my paragraph above and thinking I'm taking Shawn / Transact / Grid to town, think again - this is on us, collectively, to say what's important, what our standards are, and what we'll support. Those are the objective criteria, that Arnaud is rightfully looking for, that should ultimately be the basis for accepting new projects as TLPs and keeping them there. At the same time, Shawn, I think if these projects were more public in how they work, a lot of the angst on these issues might fade, and we could get back to talking about working across projects.

Brian


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


Re: Transact as a TLP

James Barry
 

Brian and Arnaud,

Without emotion into to it, these things take a while to gestate. I think that Transact is maturing now so that it can be used as a solid external component.  Iroha is enquiring about the use within their 2.0 and testing the framework. Sawtooth 2.0 will be using it as a core component.  Outside of Hyperledger, at this point Scabbard, the default engine for Splinter (not a Hyperledger project) is definitely using Transact.  I believe other DLT’s will use it once it gets a bit more mature and more publicity. 

These things are hard to make reusable as the TSC noted when Bill and I made our componentization pitch to the TSC last Spring.  I do think it would be a good thing for the TSC to look at common component frameworks and see if there is any uptick for the projects.  If so, perhaps a member or two might find it good for a resource to work for 3-4 months to see if it would fit into the top level frameworks.  I was on the call asking the TSC for some fairly straight forward changes so the Chinese encryption algorithm could be used by Fabric.  The pushback surprised me, especially talking about all of the issues around hardware devices etc.  Accommodating the encryption was IMHO a perfect use case for componentization, and a great one for URSA to tackle.  Yes it would take longer, but then Fabric would not be caught flat footed by the next country requiring their own proprietary encryption. So it is this hard level of reuse or accommodation that needs to be looked at, unless Hyperledger is to become a single codebase project.  Brian has some great discussions on how the DLT should all be getting closer together with clients, API’s, I/O’s etc.  Things like Quorum are in use at large Hyperledger members.  Transact had a great vision when it started and “should" be something that a Quorum project is interested in. Because Transact slowed down delivering its original promise, that should be a reason to see how to help it, not fold it in.  Same with URSA frankly.  Starting out as a Labs project might work, so long as the sponsors would be able to find two projects that would lend dedicated programmers to integrate into their project.  

Hyperledger’s TSC could define what is expected from shareable components.  URSA is another one that could use that expectation of the shared components in my opinion. 

Transact had a great vision at the beginning and is now starting to realize that vision.  Let's see how we can help it along and achieve its vision.  Its time for shareable components to emerge for the DLT’s (blockchains) as they were all islands back in 2018.  If we are to get widespread use, they need to start having some reusable pieces, not simply build it and they will come. That fractionalization really killed the overall blockchain momentum and created the “disillusionment” trough that individual walled projects have created. Through projects like Transact/Ursa etc. that sense of an entire framework, not individual projects, enterprises will find DLT’s (blockchains) more mainstream and usable within their environments.

I hope to see Transact and other projects nurtured to help each other.  I would hope that the needs of other projects are added to the architectures as they are being developed so they can be reused throughout the Hyperledger community.  We have been working with Shawn to get Sawtooth 2.x to be accommodating to our needs including putting items in the plans that were not originally in the architecture. And we are not the only ones with needs not originally contemplated by the 2.0 architecture.  Transact could use some solid PR’s or whatever process the TSC thinks will accommodate the acquiring needs of other projects. Through some strong suggestions, we can help mold Transact to be an awesome project. 

Thanks,


James Barry
Cell 303-956-8835
james@...
http://www.linkedin.com/in/jamesbarry




On Sep 4, 2020, at 2:04 PM, Arnaud Le Hors <lehors@...> wrote:

Hi Shawn,

While I understand your emotional response I think it's important to keep it to facts. In what way has the TSC been disruptive to date?? The TSC isn't trying to kill anything. At best it is trying to get some order into a house that by at least some measure is a bit more chaotic than one might like (as Hart pointed out this may be more of a marketing issue than anything else). Despite what you're claiming this is definitely not a Fabric vs Transact endeavor because when I asked whether this issue should be pursued or not the only two people who said no where Dan from Intel and Chris from IBM.

I'm still uncertain as to whether the rollover idea is something we should do and what I drafted is the way we should go at it but I don't think it helps to distort what is intended or claim that the TSC is only trying to get in the way. I think the track record clearly shows that the TSC is trying to help. And, as chair, I'm only trying to facilitate discussion and helping us, as a community, progress on whatever issue is raised. If the community thinks the TSC is going in the wrong direction I have no doubts the TSC will listen and react accordingly.

Let's please stop speculating on other people's intention and try to be constructive. For that matter, if Transact is already used in more than one project or about to, this whole issue shouldn't worry you at all. So, why is this even of a concern to you? Brian made it a Transact specific issue starting this thread but this surely wasn't my intent because I think it'd be wrong to treat Transact any differently from other projects.

Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Shawn Amundson" <amundson@...>
To:        Brian Behlendorf <bbehlendorf@...>
Cc:        "hyperledger-tsc@..." <hyperledger-tsc@...>
Date:        09/04/2020 08:49 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Transact as a TLP
Sent by:        tsc@...




On Fri, Sep 4, 2020 at 3:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
...
But then... that enthusiasm seemed to fizzle. Like any such collaborative process, it can be awfully hard to try and figure out why projects don't make that leap from great initial hopes to continued participation. Should the Fabric team have bent their plans for their 2.0 architecture more? Should Transact's initial architecture have changed more? Were Iroha even asked to participate? Even if we couldn't figure it out in 2019, could we figure it out in the Sawtooth 2.0 / Fabric 3.0 / Iroha-next / etc timeframe? I imagine there'll be as many different reasons why things went south as there were people engaged. There's really no need to assign blame here - we've long believed strongly that maintainers should set the technical course for their projects, unless they royally screw up - but we should acknowledge that collectively this effort hasn't lived up to that promise, and that promise was the basis for the vote in favor of Transact as a TLP. Collaboration is hard and it requires all sides to make extra effort beyond scratching their own itches (which is a metaphor for open source I've long despised!). It's a challenge to prioritize that over customer-paying work, let alone the usual technical differences of opinion on The Way To Build A DLT. It requires people realizing they have more to gain from a common platform than lose from that extra work. That requires a leap of faith and trust between individuals. Sometimes, that just can't be willed into existence. Or maybe everyone just realized one API to rule them all was too hard, asked for too many compromises to be useful. One sign of this is that Digital Asset went to some lengths to port their DAML engine across Fabric, Sawtooth, Corda and I think Quorum, and while that wasn't cheap I'm sure, it suggested it wasn't a show-stopper either.
Enthusiasm among those involved in Transact hasn't fizzled. Quite the opposite, since Sawtooth is at warp-speed right now integrating it (Sawtooth will be the 2nd DLT to use Transact, after Scabbard), and we just learned the future of Iroha will be Rust (very enthusiastic about that, and also, very likely future collaborations - if the TSC can stay out of the way).

I challenge the assertion that the success of Transact should be defined by the participation of the Fabric team.  The Fabric team loses out on extending its overall engineering capability by maintaining a walled-garden approach. At the end of the day though, it is a hard sell - Fabric is a Go project and we have a Rust library. Transact covers about 3/4 of what the endorser does, and no one likes to throw away their existing code on a whim. Does it still make sense to collaborate? Probably. Academically, I'm quite interested in a from-scratch Rust implementation of the endorser. Could be a parallel effort with the current implementation, maybe a new labs project. Do I have time to implement it? ... not in isolation, but we haven't really explored whether there is a sufficient Rust community within the Fabric community. Maybe?

...
That's what, I believe, is at the heart of the issue for several people on the TSC and in the community - a history that is more personal than can be fixed by a rule like "when to combine projects", which is really "when to combine projects against the will of their maintainers". It doesn't sound like the maintainers of either Sawtooth or Transact want them to be combined. But at the same time, the existence of Transact as a top level project is a reminder of that failed effort, a totem for our difficulties in collaborating across projects.

While we continue to put up PRs and do real engineering work on the project, please do elaborate on this: "a reminder of that failed effort, a totem for our difficulties" -- My initial reaction was like WTF, but I'm sure I'm misunderstanding you... I'm sure you meant the opportunities are ahead of us as we continue to foster collaboration across projects, but it is totally not how it initially reads.

FWIW, the only negativity currently is generated from the TSC and this surrounding discussion fallout. The TSC itself is mostly disruptive, not productive. There is a big difference between "how should we get projects to collaborate more" and "we should kill this project we aren't involved with". Transact is a fundamental piece of keeping Grid DLT-agnostic, so I assume this is an anti-Grid play overall, and everyone else is just sucked into the "objective" discussion.
 
...
There are three possible fixes I see based on this history:
This would be a fun exercise across projects. "1) Fabric and Sawtooth maintainers declare that they are still interested in distributed non-centralized ledgers." etc.

1) Transact maintainers declare that they're still interested in that original goal, and are willing to put in the work to adapt their current architectural plans to meet the needs of others. Maintainers on other projects also commit to further discussions and efforts to use Transact on their platforms as appropriate. Meetings to discuss how each DLT takes steps in their next major release to allow them to use Transact, or at least narrow the gap. Transact might still take a few years to achieve that goal, but it remains a top level project so long as those attempts continue.
The original goal of creating a Rust library that can be used across DLTs remains. You are suggesting we aren't factoring these things in already, but you are incorrect as it is a normal part of design discussions to consider how different DLTs work. AFAIK the gaps you are suggesting aren't as big as you are suggesting, and the majority of the work here is in cleaning up DLT code enough to draw the boundary around transaction execution -- a super non-trivial task, to be sure, since the functionality provided by Transact is specific but also substantial.
...
4) Ditch all this, let proposal goal bygones be bygones, and devise strictly objective metrics for demoting or removing TLPs based on community health metrics, not based on what-depends-upon-what. Someone would need to define those health metrics and the sequence of steps the TSC does to help projects meet those metrics before taking such a harsh measure.
...

"Ditch all this" -- probably a good approach for those not involved in the project. TBH, I don't see how engineering work continuing to go into HL projects gets this type of negative response.
 
No one is asking, but Transact's goals are likely to expand as we go forward into a more full solution around the current capability -- so that if you adopt it, it comes with more stuff "for free" -- which will make it more compelling over time.

-Shawn





Re: Transact as a TLP

Arnaud Le Hors
 

Hi Shawn,

While I understand your emotional response I think it's important to keep it to facts. In what way has the TSC been disruptive to date?? The TSC isn't trying to kill anything. At best it is trying to get some order into a house that by at least some measure is a bit more chaotic than one might like (as Hart pointed out this may be more of a marketing issue than anything else). Despite what you're claiming this is definitely not a Fabric vs Transact endeavor because when I asked whether this issue should be pursued or not the only two people who said no where Dan from Intel and Chris from IBM.

I'm still uncertain as to whether the rollover idea is something we should do and what I drafted is the way we should go at it but I don't think it helps to distort what is intended or claim that the TSC is only trying to get in the way. I think the track record clearly shows that the TSC is trying to help. And, as chair, I'm only trying to facilitate discussion and helping us, as a community, progress on whatever issue is raised. If the community thinks the TSC is going in the wrong direction I have no doubts the TSC will listen and react accordingly.

Let's please stop speculating on other people's intention and try to be constructive. For that matter, if Transact is already used in more than one project or about to, this whole issue shouldn't worry you at all. So, why is this even of a concern to you? Brian made it a Transact specific issue starting this thread but this surely wasn't my intent because I think it'd be wrong to treat Transact any differently from other projects.

Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Shawn Amundson" <amundson@...>
To:        Brian Behlendorf <bbehlendorf@...>
Cc:        "hyperledger-tsc@..." <hyperledger-tsc@...>
Date:        09/04/2020 08:49 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Transact as a TLP
Sent by:        tsc@...




On Fri, Sep 4, 2020 at 3:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
...
But then... that enthusiasm seemed to fizzle. Like any such collaborative process, it can be awfully hard to try and figure out why projects don't make that leap from great initial hopes to continued participation. Should the Fabric team have bent their plans for their 2.0 architecture more? Should Transact's initial architecture have changed more? Were Iroha even asked to participate? Even if we couldn't figure it out in 2019, could we figure it out in the Sawtooth 2.0 / Fabric 3.0 / Iroha-next / etc timeframe? I imagine there'll be as many different reasons why things went south as there were people engaged. There's really no need to assign blame here - we've long believed strongly that maintainers should set the technical course for their projects, unless they royally screw up - but we should acknowledge that collectively this effort hasn't lived up to that promise, and that promise was the basis for the vote in favor of Transact as a TLP. Collaboration is hard and it requires all sides to make extra effort beyond scratching their own itches (which is a metaphor for open source I've long despised!). It's a challenge to prioritize that over customer-paying work, let alone the usual technical differences of opinion on The Way To Build A DLT. It requires people realizing they have more to gain from a common platform than lose from that extra work. That requires a leap of faith and trust between individuals. Sometimes, that just can't be willed into existence. Or maybe everyone just realized one API to rule them all was too hard, asked for too many compromises to be useful. One sign of this is that Digital Asset went to some lengths to port their DAML engine across Fabric, Sawtooth, Corda and I think Quorum, and while that wasn't cheap I'm sure, it suggested it wasn't a show-stopper either.
Enthusiasm among those involved in Transact hasn't fizzled. Quite the opposite, since Sawtooth is at warp-speed right now integrating it (Sawtooth will be the 2nd DLT to use Transact, after Scabbard), and we just learned the future of Iroha will be Rust (very enthusiastic about that, and also, very likely future collaborations - if the TSC can stay out of the way).

I challenge the assertion that the success of Transact should be defined by the participation of the Fabric team.  The Fabric team loses out on extending its overall engineering capability by maintaining a walled-garden approach. At the end of the day though, it is a hard sell - Fabric is a Go project and we have a Rust library. Transact covers about 3/4 of what the endorser does, and no one likes to throw away their existing code on a whim. Does it still make sense to collaborate? Probably. Academically, I'm quite interested in a from-scratch Rust implementation of the endorser. Could be a parallel effort with the current implementation, maybe a new labs project. Do I have time to implement it? ... not in isolation, but we haven't really explored whether there is a sufficient Rust community within the Fabric community. Maybe?

...
That's what, I believe, is at the heart of the issue for several people on the TSC and in the community - a history that is more personal than can be fixed by a rule like "when to combine projects", which is really "when to combine projects against the will of their maintainers". It doesn't sound like the maintainers of either Sawtooth or Transact want them to be combined. But at the same time, the existence of Transact as a top level project is a reminder of that failed effort, a totem for our difficulties in collaborating across projects.

While we continue to put up PRs and do real engineering work on the project, please do elaborate on this: "a reminder of that failed effort, a totem for our difficulties" -- My initial reaction was like WTF, but I'm sure I'm misunderstanding you... I'm sure you meant the opportunities are ahead of us as we continue to foster collaboration across projects, but it is totally not how it initially reads.

FWIW, the only negativity currently is generated from the TSC and this surrounding discussion fallout. The TSC itself is mostly disruptive, not productive. There is a big difference between "how should we get projects to collaborate more" and "we should kill this project we aren't involved with". Transact is a fundamental piece of keeping Grid DLT-agnostic, so I assume this is an anti-Grid play overall, and everyone else is just sucked into the "objective" discussion.
 
...
There are three possible fixes I see based on this history:
This would be a fun exercise across projects. "1) Fabric and Sawtooth maintainers declare that they are still interested in distributed non-centralized ledgers." etc.

1) Transact maintainers declare that they're still interested in that original goal, and are willing to put in the work to adapt their current architectural plans to meet the needs of others. Maintainers on other projects also commit to further discussions and efforts to use Transact on their platforms as appropriate. Meetings to discuss how each DLT takes steps in their next major release to allow them to use Transact, or at least narrow the gap. Transact might still take a few years to achieve that goal, but it remains a top level project so long as those attempts continue.
The original goal of creating a Rust library that can be used across DLTs remains. You are suggesting we aren't factoring these things in already, but you are incorrect as it is a normal part of design discussions to consider how different DLTs work. AFAIK the gaps you are suggesting aren't as big as you are suggesting, and the majority of the work here is in cleaning up DLT code enough to draw the boundary around transaction execution -- a super non-trivial task, to be sure, since the functionality provided by Transact is specific but also substantial.
...
4) Ditch all this, let proposal goal bygones be bygones, and devise strictly objective metrics for demoting or removing TLPs based on community health metrics, not based on what-depends-upon-what. Someone would need to define those health metrics and the sequence of steps the TSC does to help projects meet those metrics before taking such a harsh measure.
...

"Ditch all this" -- probably a good approach for those not involved in the project. TBH, I don't see how engineering work continuing to go into HL projects gets this type of negative response.
 
No one is asking, but Transact's goals are likely to expand as we go forward into a more full solution around the current capability -- so that if you adopt it, it comes with more stuff "for free" -- which will make it more compelling over time.

-Shawn




Re: Transact as a TLP

Shawn Amundson
 



On Fri, Sep 4, 2020 at 4:03 AM Duncan Johnston-Watt <duncan@...> wrote:
...
 

My 2c is that given the variety of top level DLTs within the Hyperledger community and their very different architectures it is highly unlikely that a TLP like a Transact will be capable of supporting all of them. Therefore my simple minded approach would be to see if at least one other of the top level DLT projects is seriously interested in supporting it as a starting point.


I'd personally like to see Iroha adopt Transact. But I don't think it can/should be a TSC mandate, nor do I think it should be a metric by which we judge HL's success.

Keep in mind that Transact is used in Grid, Scabbard, Sawtooth -- and because it is used in Grid, you can run Grid today on Scabbard without Sawtooth, if that's what you want to do. A "totem for our difficulties" for some, and "holy shit that's cool" for others.

-Shawn


Re: Transact as a TLP

Shawn Amundson
 

On Fri, Sep 4, 2020 at 3:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
...

But then... that enthusiasm seemed to fizzle. Like any such collaborative process, it can be awfully hard to try and figure out why projects don't make that leap from great initial hopes to continued participation. Should the Fabric team have bent their plans for their 2.0 architecture more? Should Transact's initial architecture have changed more? Were Iroha even asked to participate? Even if we couldn't figure it out in 2019, could we figure it out in the Sawtooth 2.0 / Fabric 3.0 / Iroha-next / etc timeframe? I imagine there'll be as many different reasons why things went south as there were people engaged. There's really no need to assign blame here - we've long believed strongly that maintainers should set the technical course for their projects, unless they royally screw up - but we should acknowledge that collectively this effort hasn't lived up to that promise, and that promise was the basis for the vote in favor of Transact as a TLP. Collaboration is hard and it requires all sides to make extra effort beyond scratching their own itches (which is a metaphor for open source I've long despised!). It's a challenge to prioritize that over customer-paying work, let alone the usual technical differences of opinion on The Way To Build A DLT. It requires people realizing they have more to gain from a common platform than lose from that extra work. That requires a leap of faith and trust between individuals. Sometimes, that just can't be willed into existence. Or maybe everyone just realized one API to rule them all was too hard, asked for too many compromises to be useful. One sign of this is that Digital Asset went to some lengths to port their DAML engine across Fabric, Sawtooth, Corda and I think Quorum, and while that wasn't cheap I'm sure, it suggested it wasn't a show-stopper either.

Enthusiasm among those involved in Transact hasn't fizzled. Quite the opposite, since Sawtooth is at warp-speed right now integrating it (Sawtooth will be the 2nd DLT to use Transact, after Scabbard), and we just learned the future of Iroha will be Rust (very enthusiastic about that, and also, very likely future collaborations - if the TSC can stay out of the way).

I challenge the assertion that the success of Transact should be defined by the participation of the Fabric team.  The Fabric team loses out on extending its overall engineering capability by maintaining a walled-garden approach. At the end of the day though, it is a hard sell - Fabric is a Go project and we have a Rust library. Transact covers about 3/4 of what the endorser does, and no one likes to throw away their existing code on a whim. Does it still make sense to collaborate? Probably. Academically, I'm quite interested in a from-scratch Rust implementation of the endorser. Could be a parallel effort with the current implementation, maybe a new labs project. Do I have time to implement it? ... not in isolation, but we haven't really explored whether there is a sufficient Rust community within the Fabric community. Maybe?

...

That's what, I believe, is at the heart of the issue for several people on the TSC and in the community - a history that is more personal than can be fixed by a rule like "when to combine projects", which is really "when to combine projects against the will of their maintainers". It doesn't sound like the maintainers of either Sawtooth or Transact want them to be combined. But at the same time, the existence of Transact as a top level project is a reminder of that failed effort, a totem for our difficulties in collaborating across projects.


While we continue to put up PRs and do real engineering work on the project, please do elaborate on this: "a reminder of that failed effort, a totem for our difficulties" -- My initial reaction was like WTF, but I'm sure I'm misunderstanding you... I'm sure you meant the opportunities are ahead of us as we continue to foster collaboration across projects, but it is totally not how it initially reads.

FWIW, the only negativity currently is generated from the TSC and this surrounding discussion fallout. The TSC itself is mostly disruptive, not productive. There is a big difference between "how should we get projects to collaborate more" and "we should kill this project we aren't involved with". Transact is a fundamental piece of keeping Grid DLT-agnostic, so I assume this is an anti-Grid play overall, and everyone else is just sucked into the "objective" discussion.
 
...

There are three possible fixes I see based on this history:

This would be a fun exercise across projects. "1) Fabric and Sawtooth maintainers declare that they are still interested in distributed non-centralized ledgers." etc.

1) Transact maintainers declare that they're still interested in that original goal, and are willing to put in the work to adapt their current architectural plans to meet the needs of others. Maintainers on other projects also commit to further discussions and efforts to use Transact on their platforms as appropriate. Meetings to discuss how each DLT takes steps in their next major release to allow them to use Transact, or at least narrow the gap. Transact might still take a few years to achieve that goal, but it remains a top level project so long as those attempts continue.

The original goal of creating a Rust library that can be used across DLTs remains. You are suggesting we aren't factoring these things in already, but you are incorrect as it is a normal part of design discussions to consider how different DLTs work. AFAIK the gaps you are suggesting aren't as big as you are suggesting, and the majority of the work here is in cleaning up DLT code enough to draw the boundary around transaction execution -- a super non-trivial task, to be sure, since the functionality provided by Transact is specific but also substantial.
...

4) Ditch all this, let proposal goal bygones be bygones, and devise strictly objective metrics for demoting or removing TLPs based on community health metrics, not based on what-depends-upon-what. Someone would need to define those health metrics and the sequence of steps the TSC does to help projects meet those metrics before taking such a harsh measure.

...

"Ditch all this" -- probably a good approach for those not involved in the project. TBH, I don't see how engineering work continuing to go into HL projects gets this type of negative response.
 
No one is asking, but Transact's goals are likely to expand as we go forward into a more full solution around the current capability -- so that if you adopt it, it comes with more stuff "for free" -- which will make it more compelling over time.

-Shawn


Re: Transact as a TLP

Duncan Johnston-Watt
 

Brian/All

This is definitely something we should talk about next week.

My 2c is that given the variety of top level DLTs within the Hyperledger community and their very different architectures it is highly unlikely that a TLP like a Transact will be capable of supporting all of them. Therefore my simple minded approach would be to see if at least one other of the top level DLT projects is seriously interested in supporting it as a starting point.

Brian notes -

One sign of this is that Digital Asset went to some lengths to port their DAML engine across Fabric, Sawtooth, Corda and I think Quorum, and while that wasn't cheap I'm sure, it suggested it wasn't a show-stopper either.

It's actually Besu not Quorum and the list includes VMware Blockchain and FISCO BCOS  too. However he is quite right that Digital Asset has invested to ensure that DAML "reaches the parts that other smart contract languages cannot reach" to misquote a Heineken advert from my youth.

Best

Duncan

On Fri, Sep 4, 2020 at 9:35 AM Brian Behlendorf <bbehlendorf@...> wrote:

In Rocketchat, Shawn Amundson had this to say about the "Rollover of projects tied to a single other project" proposal:

It would be helpful to be specific about the intent in relation to existing projects. A policy that forces X project and Y project to merge may be equivalent to ejecting X project or Y project from HL. Such a move should be explicit and discussed. As it is now, it sounds like malicious maneuvering against projects that specific TSC members aren't directly invested in. TSC should focus instead on fostering collaboration instead of attacking projects. "If you don't write your project report the right way, we will immediately start to talk about 'sanctions' or removing the project." isn't collaborative.

Shawn is right. Conversations that try to address subjective disagreements with objective rulemaking can come across as attempts to legislatively solve disputes and issues that are actually more interpersonal in nature and that almost always leads to bad laws/rules. Rather than talking about new rules to try and tackle what is actually a fairly specific disagreement and possibly a niche situation, it might help to try and explain how we got here, and use that as a basis to figure out a better path out.

As I retell this, please be kind to my interpretation. I'll cite links when I can find them, but much of this covers conversations and events happening on phone calls, DMs, personal emails, etc, as well as my unavoidably subjective read of the situation. I'll try and state interpretations as plainly as I can, and avoid imputing motives, so apologies if I slip on that. If you feel I got something wrong, feel free to let me or the list know, but please assume benign ignorance of details rather than maliciousness on my part.

Transact was proposed as a top-level project at a pretty early stage in its life, likely long before any project would be accepted today. No need to revisit that decision, but to remember its rationale - that there was a strong desire across the TSC (it seemed) for a common, unified approach to allow for portability of smart contract engines across an array of different ledgers. Such an approach, of course, is never guaranteed to work - there was no small amount of optimism, risk, and hope in that goal, and it requires a ton of communication, architectural humility, and looking for common ground before writing code. Trying to define a common dividing line across systems as different in their architectures as Fabric, Sawtooth, and Iroha (let alone Besu, which hadn't shown up yet) wasn't even clear if it was possible, or if the compromises it would require wouldn't have unacceptable costs. But there was a sincere intent shown in the Transact proposal to explore this domain, and the proposed ideas seemed worth pursuing, so much so that the TSC relied upon them to make its decision to approve. You can see mention of it in the original proposal and discussion on TSC calls that led to an email-based vote. I'd say the enthusiasm for getting this right across HL projects was part of the reason people went in so early, as it's much harder to adapt once that first architecture is laid out. While I was not at the Maintainer Summit in Minnesota, I recall hearing there were very promising conversations between Sawtooth and Fabric developers and others about the possible ways for Transact to become that kind of project. So I view the TSC's approval of Transact as not just an endorsement of the principle - hey, sounds good, someone aught to do it - but a reflection of sincere intent on behalf of the other DLTs to invest time into a shared approach. That was not "we'll wait and see", but "this is good enough, let's start to work together."

But then... that enthusiasm seemed to fizzle. Like any such collaborative process, it can be awfully hard to try and figure out why projects don't make that leap from great initial hopes to continued participation. Should the Fabric team have bent their plans for their 2.0 architecture more? Should Transact's initial architecture have changed more? Were Iroha even asked to participate? Even if we couldn't figure it out in 2019, could we figure it out in the Sawtooth 2.0 / Fabric 3.0 / Iroha-next / etc timeframe? I imagine there'll be as many different reasons why things went south as there were people engaged. There's really no need to assign blame here - we've long believed strongly that maintainers should set the technical course for their projects, unless they royally screw up - but we should acknowledge that collectively this effort hasn't lived up to that promise, and that promise was the basis for the vote in favor of Transact as a TLP. Collaboration is hard and it requires all sides to make extra effort beyond scratching their own itches (which is a metaphor for open source I've long despised!). It's a challenge to prioritize that over customer-paying work, let alone the usual technical differences of opinion on The Way To Build A DLT. It requires people realizing they have more to gain from a common platform than lose from that extra work. That requires a leap of faith and trust between individuals. Sometimes, that just can't be willed into existence. Or maybe everyone just realized one API to rule them all was too hard, asked for too many compromises to be useful. One sign of this is that Digital Asset went to some lengths to port their DAML engine across Fabric, Sawtooth, Corda and I think Quorum, and while that wasn't cheap I'm sure, it suggested it wasn't a show-stopper either.

Today, if Transact had been proposed, we probably would have said "let's start it in Labs" first, and given it time to make measured progress against that objective, before approving it as a TLP.  This is the path that Cactus and Avalon have gone through, successfully, and there are a lot of great ideas in Labs that haven't yet achieved their initial goals and many that won't. Had Transact started in labs, and still arrived to where it was today, my personal view is that it likely would not be accepted as a top level project, given how  core it still seems to Sawtooth. I believe we were concerned about having a production-grade DLT like Sawtooth depending upon a Labs project - which could have been solved by making it a "sawtooth-transact" repo.

That's what, I believe, is at the heart of the issue for several people on the TSC and in the community - a history that is more personal than can be fixed by a rule like "when to combine projects", which is really "when to combine projects against the will of their maintainers". It doesn't sound like the maintainers of either Sawtooth or Transact want them to be combined. But at the same time, the existence of Transact as a top level project is a reminder of that failed effort, a totem for our difficulties in collaborating across projects.

To be completely fair to Transact, as an individual project it has by no means failed. I don't know if there are production systems running on it yet, but objectively there are commits and code and docs and all the trappings of a competently managed source tree. Its last release was version 0.3.1 just 12 hours ago. There are commits to the repo from more than just Bitwise employees this past year, according to the dashboard. So let's think instead about how to respect the effort those devs are putting in, an approach that helps them and Transact get closer to its original goal, or if that goal no longer applies, provides a dignified alternative path.

There are three possible fixes I see based on this history:

1) Transact maintainers declare that they're still interested in that original goal, and are willing to put in the work to adapt their current architectural plans to meet the needs of others. Maintainers on other projects also commit to further discussions and efforts to use Transact on their platforms as appropriate. Meetings to discuss how each DLT takes steps in their next major release to allow them to use Transact, or at least narrow the gap. Transact might still take a few years to achieve that goal, but it remains a top level project so long as those attempts continue.

2) Transact maintainers declare that they're still interested in that original goal, and are willing to put in the work to adapt their current architectural plans to meet the needs of others. BUT, maintainers on other projects can't find the time or inclination to sincerely take part in that process. In that case, Transact remains a TLP, because they should not be penalized if other projects can't be bothered to meet them halfway. Even just one such DLT stepping in would be enough.

3) Transact maintainers declare that other projects are more than welcome to use the architecture they've developed, but they have their own priorities and opinions on how things should be built, take them or leave them. Many projects are successful with that perspective - including the Linux kernel! - so that's not an incorrect approach. But that seems different than how the project was originally sold as appropriate for a TLP. In this case, Transact is folded into Sawtooth as a sawtooth-transact repo, or becomes a Lab.

4) Ditch all this, let proposal goal bygones be bygones, and devise strictly objective metrics for demoting or removing TLPs based on community health metrics, not based on what-depends-upon-what. Someone would need to define those health metrics and the sequence of steps the TSC does to help projects meet those metrics before taking such a harsh measure.

Comparing Transact to other tools/utilities projects like Cello, Caliper, and Explorer is difficult, because none of those projects were about so deeply about rebooting how our DLTs would work; instead they are add-ons where adaptation to other DLTs doesn't require such tight coordination with core maintainers on those DLTs. Ursa is more comparable, and Ursa now is consumed by both Indy and Iroha, who did put in the work in good faith.

There may be other proposals to put on the table. However, putting aside my "HL/LF staff objective community facilitator" hat and putting on my "experienced open source community leader" hat, the use of dependencies to argue for whether something should be a TLP inside an umbrella or not (or worse, as a basis for that status to be removed) is something I have never heard of before here, and so of course have never seen successfully applied, and my spidey sense is that aside from suggesting it (e.g. "that FabToken proposal you made, have you talked with Fabric about being a module there first? or over at Labs?") it's a poor criteria here.

Brian

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



--
Duncan Johnston-Watt
CEO, BTP

Twitter: @duncanjw


Transact as a TLP

Brian Behlendorf
 

In Rocketchat, Shawn Amundson had this to say about the "Rollover of projects tied to a single other project" proposal:

It would be helpful to be specific about the intent in relation to existing projects. A policy that forces X project and Y project to merge may be equivalent to ejecting X project or Y project from HL. Such a move should be explicit and discussed. As it is now, it sounds like malicious maneuvering against projects that specific TSC members aren't directly invested in. TSC should focus instead on fostering collaboration instead of attacking projects. "If you don't write your project report the right way, we will immediately start to talk about 'sanctions' or removing the project." isn't collaborative.

Shawn is right. Conversations that try to address subjective disagreements with objective rulemaking can come across as attempts to legislatively solve disputes and issues that are actually more interpersonal in nature and that almost always leads to bad laws/rules. Rather than talking about new rules to try and tackle what is actually a fairly specific disagreement and possibly a niche situation, it might help to try and explain how we got here, and use that as a basis to figure out a better path out.

As I retell this, please be kind to my interpretation. I'll cite links when I can find them, but much of this covers conversations and events happening on phone calls, DMs, personal emails, etc, as well as my unavoidably subjective read of the situation. I'll try and state interpretations as plainly as I can, and avoid imputing motives, so apologies if I slip on that. If you feel I got something wrong, feel free to let me or the list know, but please assume benign ignorance of details rather than maliciousness on my part.

Transact was proposed as a top-level project at a pretty early stage in its life, likely long before any project would be accepted today. No need to revisit that decision, but to remember its rationale - that there was a strong desire across the TSC (it seemed) for a common, unified approach to allow for portability of smart contract engines across an array of different ledgers. Such an approach, of course, is never guaranteed to work - there was no small amount of optimism, risk, and hope in that goal, and it requires a ton of communication, architectural humility, and looking for common ground before writing code. Trying to define a common dividing line across systems as different in their architectures as Fabric, Sawtooth, and Iroha (let alone Besu, which hadn't shown up yet) wasn't even clear if it was possible, or if the compromises it would require wouldn't have unacceptable costs. But there was a sincere intent shown in the Transact proposal to explore this domain, and the proposed ideas seemed worth pursuing, so much so that the TSC relied upon them to make its decision to approve. You can see mention of it in the original proposal and discussion on TSC calls that led to an email-based vote. I'd say the enthusiasm for getting this right across HL projects was part of the reason people went in so early, as it's much harder to adapt once that first architecture is laid out. While I was not at the Maintainer Summit in Minnesota, I recall hearing there were very promising conversations between Sawtooth and Fabric developers and others about the possible ways for Transact to become that kind of project. So I view the TSC's approval of Transact as not just an endorsement of the principle - hey, sounds good, someone aught to do it - but a reflection of sincere intent on behalf of the other DLTs to invest time into a shared approach. That was not "we'll wait and see", but "this is good enough, let's start to work together."

But then... that enthusiasm seemed to fizzle. Like any such collaborative process, it can be awfully hard to try and figure out why projects don't make that leap from great initial hopes to continued participation. Should the Fabric team have bent their plans for their 2.0 architecture more? Should Transact's initial architecture have changed more? Were Iroha even asked to participate? Even if we couldn't figure it out in 2019, could we figure it out in the Sawtooth 2.0 / Fabric 3.0 / Iroha-next / etc timeframe? I imagine there'll be as many different reasons why things went south as there were people engaged. There's really no need to assign blame here - we've long believed strongly that maintainers should set the technical course for their projects, unless they royally screw up - but we should acknowledge that collectively this effort hasn't lived up to that promise, and that promise was the basis for the vote in favor of Transact as a TLP. Collaboration is hard and it requires all sides to make extra effort beyond scratching their own itches (which is a metaphor for open source I've long despised!). It's a challenge to prioritize that over customer-paying work, let alone the usual technical differences of opinion on The Way To Build A DLT. It requires people realizing they have more to gain from a common platform than lose from that extra work. That requires a leap of faith and trust between individuals. Sometimes, that just can't be willed into existence. Or maybe everyone just realized one API to rule them all was too hard, asked for too many compromises to be useful. One sign of this is that Digital Asset went to some lengths to port their DAML engine across Fabric, Sawtooth, Corda and I think Quorum, and while that wasn't cheap I'm sure, it suggested it wasn't a show-stopper either.

Today, if Transact had been proposed, we probably would have said "let's start it in Labs" first, and given it time to make measured progress against that objective, before approving it as a TLP.  This is the path that Cactus and Avalon have gone through, successfully, and there are a lot of great ideas in Labs that haven't yet achieved their initial goals and many that won't. Had Transact started in labs, and still arrived to where it was today, my personal view is that it likely would not be accepted as a top level project, given how  core it still seems to Sawtooth. I believe we were concerned about having a production-grade DLT like Sawtooth depending upon a Labs project - which could have been solved by making it a "sawtooth-transact" repo.

That's what, I believe, is at the heart of the issue for several people on the TSC and in the community - a history that is more personal than can be fixed by a rule like "when to combine projects", which is really "when to combine projects against the will of their maintainers". It doesn't sound like the maintainers of either Sawtooth or Transact want them to be combined. But at the same time, the existence of Transact as a top level project is a reminder of that failed effort, a totem for our difficulties in collaborating across projects.

To be completely fair to Transact, as an individual project it has by no means failed. I don't know if there are production systems running on it yet, but objectively there are commits and code and docs and all the trappings of a competently managed source tree. Its last release was version 0.3.1 just 12 hours ago. There are commits to the repo from more than just Bitwise employees this past year, according to the dashboard. So let's think instead about how to respect the effort those devs are putting in, an approach that helps them and Transact get closer to its original goal, or if that goal no longer applies, provides a dignified alternative path.

There are three possible fixes I see based on this history:

1) Transact maintainers declare that they're still interested in that original goal, and are willing to put in the work to adapt their current architectural plans to meet the needs of others. Maintainers on other projects also commit to further discussions and efforts to use Transact on their platforms as appropriate. Meetings to discuss how each DLT takes steps in their next major release to allow them to use Transact, or at least narrow the gap. Transact might still take a few years to achieve that goal, but it remains a top level project so long as those attempts continue.

2) Transact maintainers declare that they're still interested in that original goal, and are willing to put in the work to adapt their current architectural plans to meet the needs of others. BUT, maintainers on other projects can't find the time or inclination to sincerely take part in that process. In that case, Transact remains a TLP, because they should not be penalized if other projects can't be bothered to meet them halfway. Even just one such DLT stepping in would be enough.

3) Transact maintainers declare that other projects are more than welcome to use the architecture they've developed, but they have their own priorities and opinions on how things should be built, take them or leave them. Many projects are successful with that perspective - including the Linux kernel! - so that's not an incorrect approach. But that seems different than how the project was originally sold as appropriate for a TLP. In this case, Transact is folded into Sawtooth as a sawtooth-transact repo, or becomes a Lab.

4) Ditch all this, let proposal goal bygones be bygones, and devise strictly objective metrics for demoting or removing TLPs based on community health metrics, not based on what-depends-upon-what. Someone would need to define those health metrics and the sequence of steps the TSC does to help projects meet those metrics before taking such a harsh measure.

Comparing Transact to other tools/utilities projects like Cello, Caliper, and Explorer is difficult, because none of those projects were about so deeply about rebooting how our DLTs would work; instead they are add-ons where adaptation to other DLTs doesn't require such tight coordination with core maintainers on those DLTs. Ursa is more comparable, and Ursa now is consumed by both Indy and Iroha, who did put in the work in good faith.

There may be other proposals to put on the table. However, putting aside my "HL/LF staff objective community facilitator" hat and putting on my "experienced open source community leader" hat, the use of dependencies to argue for whether something should be a TLP inside an umbrella or not (or worse, as a basis for that status to be removed) is something I have never heard of before here, and so of course have never seen successfully applied, and my spidey sense is that aside from suggesting it (e.g. "that FabToken proposal you made, have you talked with Fabric about being a module there first? or over at Labs?") it's a poor criteria here.

Brian

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


Cancelled Event: Technical Steering Committee (TSC) - Thursday, 10 September 2020 #cal-cancelled

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

Cancelled: Technical Steering Committee (TSC)

This event has been cancelled.

When:
Thursday, 10 September 2020
7:00am to 8:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.backup

Organizer: Technical Steering Committee (TSC) community-architects@...

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community.backup

Or iPhone one-tap :
US: +16699006833,,6223336701# or +16465588656,,6223336701#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
Meeting ID: 622-333-6701
International numbers available: https://zoom.us/zoomconference?m=BYDz1WGXJTTJ_s4_zumD9hqKjJv-Whgs


2020 Q3 Hyperledger Grid

Andrea Gunderson
 

The 2020 Q3 Hyperledger Grid update is available at https://wiki.hyperledger.org/display/TSC/2020+Q3+Hyperledger+Grid

Thank you,
Andrea Gunderson


TSC agenda for Sept 3, 2020

Arnaud Le Hors
 

Hi all,

The agenda for this week is online:
https://wiki.hyperledger.org/display/TSC/2020-09-03+TSC+Agenda

We have a significant number of reports that have come in and need to be reviewed with one question raised by the Besu team regarding the release taxonomy. Otherwise, I have posted a draft proposal for the rollover policy we should discuss.
We can probably entertain another item or two if you'd like to add them to the agenda.

Note that we will not have a call next week because of the Member Summit.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


Re: Rollover of projects tied to a single other project (was Re: [Hyperledger TSC] TSC Agenda for Aug 20, 2020)

Arun S M
 

Hi,

I wanted to join these discussion threads for a while now, and feel like this is a best topic to start on.

The proposal looks good and in my opinion, this is a solution to the aftermath problem. I would like to take a step back and discuss what led us to such scenarios. I have jotted down a few thoughts on it in the comment section. The approach is to reform the project lifecycle and distribute responsibility of a project to a diverse set of people, rather than just relying on project maintainers. Happy to discuss more live on the call.

Regards,
Arun

On Tue, Sep 1, 2020 at 1:20 AM Arnaud Le Hors <lehors@...> wrote:
Hi Hart,

I think that makes sense. As I said on our last call, I would also expect the TSC to talk to the maintainers of the project before making any decision for that matter.
I have now drafted a proposal which states that explicitly. I invite everyone to check it out and comment:
https://wiki.hyperledger.org/display/TSC/Rollover+of+projects+tied+to+a+single+other+project

Regards. I hope everything is fine with you too.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Arnaud Le Hors <lehors@...>, "Technical Steering Committee (TSC)" <tsc@...>
Date:        08/27/2020 11:48 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] TSC Agenda for Aug 20, 2020
Sent by:        tsc@...




Hi Everyone,

If we are going to continue the discussion on projects that end up being tied to a single framework (which it looks like people wanted to do), can we (as a TSC) formally solicit the opinion of the maintainers of those projects?  In the discussions we've had so far (well, at least in this iteration of the extended "subprojects" debate) we haven't heard from anyone who is a maintainer in these projects.  It would be nice to hear the reasons why they are independent projects, and why they want to stay that way (assuming they do--but maybe they don't; for instance, if the "parent" project doesn't want them).  This would give us a lot of perspective on this issue, as I think none of the "home" projects of any of the TSC members are any of the projects we've discussed as one of these "tied to a single framework" projects.

What does everyone think about this?  If there is still momentum for this discussion (and the vote last week seemed to indicate that there was, even accounting for the "coffee" voters), I think it would be useful to decide on a list of projects that we consider falling into this category, and then asking what the maintainers of those projects think.

I hope everyone is doing OK in these difficult times.  Thanks for your time, and have a great day.

Thanks,
Hart


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors <lehors@...>
Sent:
Tuesday, August 18, 2020 11:37 PM
To:
Technical Steering Committee (TSC) <tsc@...>
Subject:
[Hyperledger TSC] TSC Agenda for Aug 20, 2020

 
Hi all,

We only have one agenda item so if anyone wants to add anything please go ahead. In any case, I'd like to continue the discussion we started last week with regard to how we manage projects that end up being tied to a single framework.


https://wiki.hyperledger.org/display/TSC/2020-08-20+TSC+Agenda

Please, note that several quarterly reports are due.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




A project proposal to Hyperledger Foundation #tsc-project-update #tsc-wg-update #tsc

Jayakar <Jayakar_J_Joseph@...>
 

Hereby a Hyperledger Project is proposed to the Hyperledger Foundation for implementing.

This project is mainly focused to procure IP Addresses for the Units of 'Digital Cluster Control Nodes (DCCN)' with cluster of 'Digitizable Healthcare-centres (DHC)', to the Blockchain of Hyperledger during their registrations.  These units to be deployed around the Globe for every 3 to 10 Healthcare Centres, for a 'Global Digital Corona Virus Harmful Mutation Control Program' that on proposal with UN.

Expecting interested partners to collaborate on this under the Umbrella of Hyperledger Foundation.


Accepted: Technical Steering Committee (TSC)

Simon Stone <sstone1@...>
 


Re: Rollover of projects tied to a single other project (was Re: [Hyperledger TSC] TSC Agenda for Aug 20, 2020)

Arnaud Le Hors
 

Hi Hart,

I think that makes sense. As I said on our last call, I would also expect the TSC to talk to the maintainers of the project before making any decision for that matter.
I have now drafted a proposal which states that explicitly. I invite everyone to check it out and comment:
https://wiki.hyperledger.org/display/TSC/Rollover+of+projects+tied+to+a+single+other+project

Regards. I hope everything is fine with you too.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Arnaud Le Hors <lehors@...>, "Technical Steering Committee (TSC)" <tsc@...>
Date:        08/27/2020 11:48 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] TSC Agenda for Aug 20, 2020
Sent by:        tsc@...




Hi Everyone,

If we are going to continue the discussion on projects that end up being tied to a single framework (which it looks like people wanted to do), can we (as a TSC) formally solicit the opinion of the maintainers of those projects?  In the discussions we've had so far (well, at least in this iteration of the extended "subprojects" debate) we haven't heard from anyone who is a maintainer in these projects.  It would be nice to hear the reasons why they are independent projects, and why they want to stay that way (assuming they do--but maybe they don't; for instance, if the "parent" project doesn't want them).  This would give us a lot of perspective on this issue, as I think none of the "home" projects of any of the TSC members are any of the projects we've discussed as one of these "tied to a single framework" projects.

What does everyone think about this?  If there is still momentum for this discussion (and the vote last week seemed to indicate that there was, even accounting for the "coffee" voters), I think it would be useful to decide on a list of projects that we consider falling into this category, and then asking what the maintainers of those projects think.

I hope everyone is doing OK in these difficult times.  Thanks for your time, and have a great day.

Thanks,
Hart


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors <lehors@...>
Sent:
Tuesday, August 18, 2020 11:37 PM
To:
Technical Steering Committee (TSC) <tsc@...>
Subject:
[Hyperledger TSC] TSC Agenda for Aug 20, 2020

 
Hi all,

We only have one agenda item so if anyone wants to add anything please go ahead. In any case, I'd like to continue the discussion we started last week with regard to how we manage projects that end up being tied to a single framework.


https://wiki.hyperledger.org/display/TSC/2020-08-20+TSC+Agenda

Please, note that several quarterly reports are due.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




Re: TSC Agenda for Aug 20, 2020

Hart Montgomery
 

Hi Everyone,

If we are going to continue the discussion on projects that end up being tied to a single framework (which it looks like people wanted to do), can we (as a TSC) formally solicit the opinion of the maintainers of those projects?  In the discussions we've had so far (well, at least in this iteration of the extended "subprojects" debate) we haven't heard from anyone who is a maintainer in these projects.  It would be nice to hear the reasons why they are independent projects, and why they want to stay that way (assuming they do--but maybe they don't; for instance, if the "parent" project doesn't want them).  This would give us a lot of perspective on this issue, as I think none of the "home" projects of any of the TSC members are any of the projects we've discussed as one of these "tied to a single framework" projects.

What does everyone think about this?  If there is still momentum for this discussion (and the vote last week seemed to indicate that there was, even accounting for the "coffee" voters), I think it would be useful to decide on a list of projects that we consider falling into this category, and then asking what the maintainers of those projects think.

I hope everyone is doing OK in these difficult times.  Thanks for your time, and have a great day.

Thanks,
Hart


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors <lehors@...>
Sent: Tuesday, August 18, 2020 11:37 PM
To: Technical Steering Committee (TSC) <tsc@...>
Subject: [Hyperledger TSC] TSC Agenda for Aug 20, 2020
 
Hi all,

We only have one agenda item so if anyone wants to add anything please go ahead. In any case, I'd like to continue the discussion we started last week with regard to how we manage projects that end up being tied to a single framework.

https://wiki.hyperledger.org/display/TSC/2020-08-20+TSC+Agenda

Please, note that several quarterly reports are due.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


Looking for a sponsor for our project - EasyDoser for HyperledgerLabs

Anoop Vijayan
 

Hi all,

  Hope you are doing well.

Me and Abhimanyu have been working on a project: EasyDoser.

This eases endorsement operations for hyperledger based products.

We would like to promote our project into hyperledgerLabs and we are in the process of looking for a sponsor.


This is currently a mentorship project which just finished 2nd (out of 4) checkpoint.

This means, from timeline point of view, we are half way through.

Some description and project plan about the project is available here: https://wiki.hyperledger.org/pages/viewpage.action?pageId=29035323


The proposal for hyperledgerLabs is already made and available as pull request here: https://github.com/hyperledger-labs/hyperledger-labs.github.io/pull/145

From the implementation standpoint, we have a bare minimum ReactJS frontend talking to hyperledger Fabric network via golang api server.

The pull request contains pictures which gives a glimpse of how backend and frontend looks.

Currently the code repository is private in github, we can share if someone is interested in taking a look.

The project status is checked and planned every week.


Looking forward for your support,


Thanks,

 - Anoop


Accepted: Technical Steering Committee (TSC)

Angelo De Caro
 


Cancelled Event: Technical Steering Committee (TSC) - Thursday, 27 August 2020 #cal-cancelled

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

Cancelled: Technical Steering Committee (TSC)

This event has been cancelled.

When:
Thursday, 27 August 2020
7:00am to 8:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.backup

Organizer: Technical Steering Committee (TSC) community-architects@...

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community.backup

Or iPhone one-tap :
US: +16699006833,,6223336701# or +16465588656,,6223336701#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
Meeting ID: 622-333-6701
International numbers available: https://zoom.us/zoomconference?m=BYDz1WGXJTTJ_s4_zumD9hqKjJv-Whgs

541 - 560 of 3658