Middleton, Dan <dan.middleton@...>
toggle quoted messageShow quoted text
Hi Yi Deng,
Building on my initial reply:
The TSC had some previous discussion which Hart has linked to.
In reviewing that discussion we decided that the best approach for proposals like yours is for you to first
“seek and document support from the maintainers of a project it depends on”.
Can I ask you to please post this proposal to the fabric mailing list?
Solicit feedback from the maintainers and then include that with your proposal.
The maintainers may ask you to include your code in the existing Fabric project or may decline your proposal. If they decline the proposal you are still free to raise it again to the TSC along with that context and we can help decide what
the right path is.
From: <tsc@...> on behalf of Yi DENG <michaelyideng@...>
Date: Sunday, November 25, 2018 at 8:30 PM
To: "Olson, Kelly M" <kelly.m.olson@...>
Cc: "hmontgomery@..." <hmontgomery@...>, "mwagner@..." <mwagner@...>, "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop
Hi TSC and all,
I think Olson gave a great explanation. Firstly, as the project devoloper, I personally don't care about if it is a top-level or sub-level project, but I do care about the autonomy.
Secondly, this app is general-purpose. You can also call it a tool, not an app.
Thirdly, supporting multiple blockchain projects is promising. But so far, I don't see a great standard to abstract workflow models. It leads to some projects which claim it will support multiple framworks, but hard to implement. Or may
it be better to support different blockchain frameworks by different projects? In the case of desktop tools, maybe it is. If we do want tools that are cross-framework, a standard is needed.
On Thu, Nov 15, 2018 at 8:29 AM Olson, Kelly M <kelly.m.olson@...
Thanks for sending this e-mail. I agree with Hart that a lot has changed in the past couple of years. I am generally in favor of applications being ‘projects’. The main reason is
that I believe allowing applications will bring in new developers and increase deployments of Hyperledger projects. I think getting new contributors into Hyperledger is one of our biggest challenges and an inability to do that poses a risk to the long-term
health of Hyperledger as a community.
The question of what exactly an ‘app’ is, is a bit fuzzy, but I haven’t yet seen a compelling reason for them to be out of scope. Ethereum has arguably the largest developer ecosystem,
and many of its applications run on standardized smart contract logic (e.g. ERC20 and ERC721 contracts). By creating high-quality community-owned business logic, application development speed and security can be increased. The biggest issue I see is that the
bar for developing an application is significantly lower than developing an entire blockchain stack, and so I think there are some governance questions around what are the criteria for accepting an application. This decision would also mean an expansion of
the number of projects under the ‘umbrella’, which should cause us to re-think how we market and fund the projects (though that is probably better left to the board and marketing committee). I’d be interested in hearing other’s opinions on the potential downsides
that they see by allowing applications.
On the second topic, I’m in favor of consolidating single-ledger tools into their top-level projects. It’s confusing that ‘Sawtooth Explorer’ supports Sawtooth, but ‘Hyperledger
Explorer’ supports Fabric. These sorts of things continue to cause people to conflate Hyperledger the community with the Fabric project. However, if these projects were to move under their respective ledger, I think it raises some governance questions that
need to be worked out. For example, ‘Hyperledger Explorer’ is predominately managed by DTTC maintainers last I checked, and I think it’s important that tool maintainers are able to keep their ‘sovereignty’ from the larger top-level projects. Similarly, top-level
projects may want to protect their brand by not allowing tools under their project without first approving. In the event of a top-level project rejecting a tool, there should be a process to resolve that conflict at the TSC. I would support tools graduating
to top-level projects as they support more than one ledger.
Finally, I think this leads to a question about whether apps should be top level projects or be under their respective ledgers. I would suggest following the same model as tools,
where if the app is specifically designed around one ledger, then it should likely target being a subproject. If an app can be run across multiple ledgers (say an EVM-based smart contract) then it would be a good candidate for a top-level project as it could
run across Burrow/Sawtooth/Fabric.
I’ll defer #1 for now, but I have a number of comments about #2.
If you do want to take the angle that proposals that are specific to a DLT (or other existing project) should be under the same umbrella as the project,
then you’d probably want to start with the Fabric Go SDK, the Fabric Python SDK, and the Java Chaincode support for Hyperledger Fabric projects. These were all passed as fully independent projects (before you were on the TSC) but are clearly Fabric-specific
to a degree that even Composer is not. Correct me if I am wrong here, but I believe they are still wholly independent, although the maintainers are heavily involved in Fabric directly as well.
However, we did discuss this quite a bit almost a year and a half ago. I have a bunch of emails from March and April 2017 where we discussed essentially
this exact issue. Some examples:
A thread on the Fabric Go SDK proposal:
A discussion about whether or not we should have a tiered or flat project structure, with a lot of rambling by me:
There are a bunch of other relevant emails around that time on the TSC list that you can find if you’re interested and search a little bit (I’m still
waiting for someone to comb all of these for an all-time “dumb things said in TSC emails” list, on which I will surely be prominently featured). In the end, we decided around that time that independent projects and a flat structure were the best way to maximize
contributions. I’m not sure if this group wants to have that discussion again, but, to be fair, Hyperledger has changed a lot in the last year and a half.
Anyways, I hope this helps you (and others) who weren’t around when we had to walk uphill both ways to the TSC meetings navigate this issue.
On Behalf Of mark wagner
Sent: Wednesday, November 14, 2018 11:16 AM
To: Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop
I would like the TSC to discuss two things that this proposal raises.
1) if its an app, can it be a project ?
iirc some previous discussions, our charter does not allow that.
2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?
I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.
What do other members think ?
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc