Following up from our conversation last month about the taxonomy of projects, so that we can create a useful updated new greenhouse graphic...
I have reviewed the feedback from the last round, and want to suggest the below taxonomy based on those comments. I also am open to changing the labels of the categories,
so I wanted to list a couple of them. But I want to get a bit more structured in the feedback so we can try to get to closure.
1) using the taxonomy labels in
RED as placeholders (sorted out in questions 2 and 3), does the following make sense, yes or no?
Please only vote "no" if you feel that this gets something overwhelmingly wrong for you, for a project you are very close to. In other words, if you can live with this, please either abstain or vote yes.
Distributed Ledgers: Burrow, Fabric, Iroha, Indy, Sawtooth
suggestion to use DLTs since it is well understood and can encompass the whole ecosystem, including storage, network protocols and smart
contract engine
Libraries: Aries, Quilt, Transact, Ursa
Except for Ursa, this may include a combination of statically or dynamically linked as well as an entire sub-system with separate processes
running on a mixture of edge and towards the center.
Tools: Caliper, Cello, Composer, Explorer
Some of these may be considered sub-projects in the future. Depends on outcome of project life-cycle task force.
2)
For Fabric, Sawtooth, etc: So far we have used "Frameworks", and that's been a challenge conceptually to seeing these as composable (e.g. Fabric+Burrow) or interoperable. Do we want
to use "Blockchains", "Distributed Ledgers", or "Engines", or something else? [1]
3)
For Grid, do we prefer Shawn's original "Specialty", or "Domain-Specific", or something else? [2]
4)
In our original proposal, we included a single icon representing Labs. Should we still include it as a separate box in the greenhouse, at the cost of complexity? Yes or No.
Yes
5) We also include SIGs, WGs, Hl Global Forum, and Meetups as boxes in the greenhouse.
Should we still include these as well, at the cost of complexity? Yes or No.
Yes-differentiation between WG+SIG/And Global Forum-meetups should be made clear.
Overall-Suggested a multitier visual structure accessible from the landing page, instead of a flat graphic- may also be necessary to have all in a single
(or two)slide(s) for conferences and presentations.
Please submit answers to these questions, either direct to me or cc the list, by next week Wednesday July 24th, and I'll collate and report back and submit for TSC approval.
Hopefully we can converge!
[1] My sense is that people were most comfortable based on feedback or lack of feedback with "Distributed Ledgers", acknowledging that right now we have a tight binding
between the actual ledger and the smart contract system in Fabric, Sawtooth, and Burrow. Over time we may be able to split these apart to "DL" and "Smart Contract Engine" if Transact is successful, but we don't have separate projects yet for chainode or transaction
processors. So we'd have to accept for now that "DL" means both the ledger & smart contract engine. Alternately, the word "engine", while a bit generic, might help articulate that its a combo of the two.
[2] While Shawn's original proposal had several other projects here, I feel like many of those are more architectural foci rather than domain- or use-case-related foci,
e.g. identity and interop are more foundational or component-y. Grid really does feel like the first of what could be a series of other projects addressing collections of common use cases or solution patterns; there isn't so much a "supply chain industry"
as every industry has a supply chain, but it is a large domain of related use cases, which look surprisingly similar between pharmaceuticals, heads of lettuce, electronics components, or buckets of iron ore. I'm hoping we see more along other recurring patterns:
directory services perhaps, or settlement systems, or marketplaces, or even health records. I don't expect this to remain a single-item category for long. So "Domain-Specific" feels better here, but it's not my call. :)
Brian
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf
