|
Baohua Yang
Dear TSC members
After last TSC meeting, Dan, Pardha, Satheesh and I make some conversations on Cello's proposal and the collaborations in community, with more and more projects joining Hyperledger today.
We bring some interesting thoughts together and wish share out for boarder discussions.
(Feel free to replenish if i missed some points.)
1. What kind of project are welcome to Hyperledger? Hyperledger community should be open to any kind of technical contributions, especially those can fill new scopes, meet different requirements, and work well with existing projects.
Cello is exactly filling the gap of BaaS (Blockchain as a Service) requirement, and its proposed scope will let it work very well with the existing projects, e.g., fabric, sawtoothlake, iroha, blockchain-explorer, chaintool and sdk. It would be nice to consider Cello as the initial effort towards Hyperledger BaaS platform.
We welcome more such kind of collaboration potentials between different projects, under the same umbrella, while remaining the users' flexibility to choose what projects can meet their requirement best.
2. How to encourage better collaborations inside the Community? To encourage more collaboration between various projects from different teams with different programming languages, we may bring up the concept of "suite".
A suite is a collection of Hyperledger projects, to achieve some open-to-use solution for specific scenarios, e.g., for Cloud scenario, for BigData scenario, for stock-trading scenario. This can help mitigate the technical challenge for users adoptions, and also help develop teams of the same suite to work more close with each other.
After enough practical adoptions, we may provide various community-recommended suites, just as the Linux, OpenStack and BigData communities do.
Would be glad if these ideas can attract more thoughts.
Look forward to hearing more insightful comments!
Thanks!
--
|
|
|
Brian Behlendorf <bbehlendorf@...>
On 12/08/2016 11:54 PM, Baohua Yang via
hyperledger-tsc wrote:
Dear TSC members
After last TSC meeting, Dan, Pardha, Satheesh and I make
some conversations on Cello's proposal and the collaborations
in community, with more and more projects joining Hyperledger
today.
We bring some interesting thoughts together and wish share
out for boarder discussions.
(Feel free to replenish if i missed some points.)
1. What kind of project are welcome to Hyperledger?
Hyperledger community should be open to any kind of
technical contributions, especially those can fill new scopes,
meet different requirements, and work well with existing
projects.
Cello is exactly filling the gap of BaaS (Blockchain as a
Service) requirement, and its proposed scope will let it work
very well with the existing projects, e.g., fabric,
sawtoothlake, iroha, blockchain-explorer, chaintool and sdk.
It would be nice to consider Cello as the initial effort
towards Hyperledger BaaS platform.
We welcome more such kind of collaboration potentials
between different projects, under the same umbrella, while
remaining the users' flexibility to choose what projects can
meet their requirement best.
My personal read of the conversation: I didn't sense any resistance
to the idea of Cello, whether a Blockchain-as-a-service application
would belong at Hyperledger, amongst the TSC or the people at the
HackFest or anywhere else. This seems to fill an important need
when it comes to building and managing the "dev ops" side of running
a chain. I think the question with respect to Explorer was simply
whether these belonged as two separate projects from day one, or
whether the scope of Explorer could be expanded to also include
Cello. I think this broader question is still interesting - how
big is our big tent? - but w/r/t to Cello I'd say don't worry about
it. Others?
My personal take: we should bring it in and not worry up front about
forcing two different codebases (and potentially two different
communities) to integrate before getting started. If it makes sense
technically or from a product perspective, it'll happen. More
granularity between projects early on means a faster way to run
experiments (as Dan Middleton put it at the member summit) and keep
an eye to building a more scalable community.
2. How to encourage better collaborations inside the
Community?
To encourage more collaboration between various projects
from different teams with different programming languages, we
may bring up the concept of "suite".
A suite is a collection of Hyperledger projects, to achieve
some open-to-use solution for specific scenarios, e.g., for
Cloud scenario, for BigData scenario, for stock-trading
scenario. This can help mitigate the technical challenge for
users adoptions, and also help develop teams of the same suite
to work more close with each other.
After enough practical adoptions, we may provide various
community-recommended suites, just as the Linux, OpenStack
and BigData communities do.
Right. There could will be some projects under
the Hyperledger banner which are aggregations of the output of other
projects, plus maybe new code too. It could be, for instance, that
over time, Fabric makes sense to divide into a handful of smaller
projects to make it easier to build a community around each, with
well-defined APIs in between, and then the "Fabric" project would
aggregate those pieces together along with an installer and other
glue code and be the larger combined work. Likewise, Cello might
incorporate Explorer's code and functionality as one screen tab
among several within Cello - no problems at all with that.
Brian
Would be glad if these ideas can attract more thoughts.
Look forward to hearing more insightful comments!
Thanks!
--
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf
|
|
|
Christopher Ferris <chris.ferris@...>
+1 I agree, I would suggest we proceed and where it makes sense, we start leveraging more of explorer rather than reinvent the wheel, and where it makes sense we should see function migrate from Cello to Explorer etc.
Cheers
On Fri, Dec 9, 2016 at 7:58 AM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...> wrote:
On 12/08/2016 11:54 PM, Baohua Yang via
hyperledger-tsc wrote:
Dear TSC members
After last TSC meeting, Dan, Pardha, Satheesh and I make
some conversations on Cello's proposal and the collaborations
in community, with more and more projects joining Hyperledger
today.
We bring some interesting thoughts together and wish share
out for boarder discussions.
(Feel free to replenish if i missed some points.)
1. What kind of project are welcome to Hyperledger?
Hyperledger community should be open to any kind of
technical contributions, especially those can fill new scopes,
meet different requirements, and work well with existing
projects.
Cello is exactly filling the gap of BaaS (Blockchain as a
Service) requirement, and its proposed scope will let it work
very well with the existing projects, e.g., fabric,
sawtoothlake, iroha, blockchain-explorer, chaintool and sdk.
It would be nice to consider Cello as the initial effort
towards Hyperledger BaaS platform.
We welcome more such kind of collaboration potentials
between different projects, under the same umbrella, while
remaining the users' flexibility to choose what projects can
meet their requirement best.
My personal read of the conversation: I didn't sense any resistance
to the idea of Cello, whether a Blockchain-as-a-service application
would belong at Hyperledger, amongst the TSC or the people at the
HackFest or anywhere else. This seems to fill an important need
when it comes to building and managing the "dev ops" side of running
a chain. I think the question with respect to Explorer was simply
whether these belonged as two separate projects from day one, or
whether the scope of Explorer could be expanded to also include
Cello. I think this broader question is still interesting - how
big is our big tent? - but w/r/t to Cello I'd say don't worry about
it. Others?
My personal take: we should bring it in and not worry up front about
forcing two different codebases (and potentially two different
communities) to integrate before getting started. If it makes sense
technically or from a product perspective, it'll happen. More
granularity between projects early on means a faster way to run
experiments (as Dan Middleton put it at the member summit) and keep
an eye to building a more scalable community.
2. How to encourage better collaborations inside the
Community?
To encourage more collaboration between various projects
from different teams with different programming languages, we
may bring up the concept of "suite".
A suite is a collection of Hyperledger projects, to achieve
some open-to-use solution for specific scenarios, e.g., for
Cloud scenario, for BigData scenario, for stock-trading
scenario. This can help mitigate the technical challenge for
users adoptions, and also help develop teams of the same suite
to work more close with each other.
After enough practical adoptions, we may provide various
community-recommended suites, just as the Linux, OpenStack
and BigData communities do.
Right. There could will be some projects under
the Hyperledger banner which are aggregations of the output of other
projects, plus maybe new code too. It could be, for instance, that
over time, Fabric makes sense to divide into a handful of smaller
projects to make it easier to build a community around each, with
well-defined APIs in between, and then the "Fabric" project would
aggregate those pieces together along with an installer and other
glue code and be the larger combined work. Likewise, Cello might
incorporate Explorer's code and functionality as one screen tab
among several within Cello - no problems at all with that.
Brian
Would be glad if these ideas can attract more thoughts.
Look forward to hearing more insightful comments!
Thanks!
--
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Brian Behlendorf <bbehlendorf@...>
I see Explorer and Cello as pretty different, actually, with nearly(?) no overlap in functionality other than both expose a web interface to an end user, so let's bring Cello in and let both teams figure out over time what moves where.
Brian On December 9, 2016 11:13:30 AM EST, Christopher Ferris <chris.ferris@...> wrote:
+1 I agree, I would suggest we proceed and where it makes sense, we start leveraging more of explorer rather than reinvent the wheel, and where it makes sense we should see function migrate from Cello to Explorer etc.
Cheers
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
|
Christopher Ferris <chris.ferris@...>
there was a dashboard if I recall, but yes the overlap is not significant
Chris
On Dec 9, 2016, at 11:29 AM, Brian Behlendorf < bbehlendorf@...> wrote: I see Explorer and Cello as pretty different, actually, with nearly(?) no overlap in functionality other than both expose a web interface to an end user, so let's bring Cello in and let both teams figure out over time what moves where.
Brian On December 9, 2016 11:13:30 AM EST, Christopher Ferris < chris.ferris@...> wrote:
+1 I agree, I would suggest we proceed and where it makes sense, we start leveraging more of explorer rather than reinvent the wheel, and where it makes sense we should see function migrate from Cello to Explorer etc.
Cheers
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
|
Middleton, Dan <dan.middleton@...>
I think we want a big tent while at the same time not proliferating narrow utilities tied to existing projects as separate projects unto themselves.
For example, I do not think it would make sense to spin out the ‘sawtooth cluster’ command as a separate project even though it is a useful way to spawn a network
of validators.
I initially felt that Cello would stand a better chance of success with a broader scope and a broader team, hence merging with explorer.
The committed scope, though, to expand beyond launching Fabric dockers to include the other infrastructure projects (Iroha and Sawtooth Lake) seems like it may
rise to the level of a distinct project.
I’m inclined towards more rather than fewer projects, but I would appreciate hearing views from the rest of the TSC with considerations on repo clutter, dilution,
overhead, etc.
Thanks,
Dan
toggle quoted message
Show quoted text
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...]
On Behalf Of Brian Behlendorf via hyperledger-tsc
Sent: Friday, December 09, 2016 11:29
To: Christopher Ferris <chris.ferris@...>
Cc: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Cello conversations + Community collaboration thoughts
I see Explorer and Cello as pretty different, actually, with nearly(?) no overlap in functionality other than both expose a web interface to an end user, so let's bring Cello in and let both teams figure out
over time what moves where.
Brian
On December 9, 2016 11:13:30 AM EST, Christopher Ferris <chris.ferris@...> wrote:
+1 I agree, I would suggest we proceed and where it makes sense, we start leveraging more of explorer rather than reinvent the wheel, and where it makes sense we should see function migrate from Cello to Explorer etc.
On Fri, Dec 9, 2016 at 7:58 AM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...> wrote:
On 12/08/2016 11:54 PM, Baohua Yang via hyperledger-tsc wrote:
Dear TSC members
After last TSC meeting, Dan, Pardha, Satheesh and I make some conversations on
Cello's proposal and the collaborations in community, with more and more projects joining Hyperledger today.
We bring some interesting thoughts together and wish share out for boarder discussions.
(Feel free to replenish if i missed some points.)
1. What kind of project are welcome to Hyperledger?
Hyperledger community should be open to any kind of technical contributions, especially those can fill new scopes, meet different requirements, and work well with existing projects.
Cello is exactly filling the gap of BaaS (Blockchain as a Service) requirement, and its proposed scope will let it work very well with the existing projects, e.g., fabric, sawtoothlake, iroha, blockchain-explorer, chaintool and sdk. It
would be nice to consider Cello as the initial effort towards Hyperledger BaaS platform.
We welcome more such kind of collaboration potentials between different projects, under the same umbrella, while remaining the users' flexibility to choose what projects can meet their requirement best.
My personal read of the conversation: I didn't sense any resistance to the idea of Cello, whether a Blockchain-as-a-service application would belong at Hyperledger, amongst the TSC or the people at the HackFest or anywhere else. This seems to fill an important
need when it comes to building and managing the "dev ops" side of running a chain. I think the question with respect to Explorer was simply whether these belonged as two separate projects from day one, or whether the scope of Explorer could be expanded to
also include Cello. I think this broader question is still interesting - how big is our big tent? - but w/r/t to Cello I'd say don't worry about it. Others?
My personal take: we should bring it in and not worry up front about forcing two different codebases (and potentially two different communities) to integrate before getting started. If it makes sense technically or from a product perspective, it'll happen.
More granularity between projects early on means a faster way to run experiments (as Dan Middleton put it at the member summit) and keep an eye to building a more scalable community.
2. How to encourage better collaborations inside the Community?
To encourage more collaboration between various projects from different teams with different programming languages, we may bring up the concept of "suite".
A suite is a collection of Hyperledger projects, to achieve some open-to-use solution for specific scenarios, e.g., for Cloud scenario, for BigData scenario, for stock-trading scenario. This can help mitigate the technical challenge for
users adoptions, and also help develop teams of the same suite to work more close with each other.
After enough practical adoptions, we may provide various community-recommended suites, just as the Linux, OpenStack and BigData communities do.
Right. There could will be some projects under the Hyperledger banner which are aggregations of the output of other projects, plus maybe new code too. It could be, for instance, that over time, Fabric makes sense to divide into a handful of smaller
projects to make it easier to build a community around each, with well-defined APIs in between, and then the "Fabric" project would aggregate those pieces together along with an installer and other glue code and be the larger combined work. Likewise, Cello
might incorporate Explorer's code and functionality as one screen tab among several within Cello - no problems at all with that.
Brian
Would be glad if these ideas can attract more thoughts.
Look forward to hearing more insightful comments!
--
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
|
Baohua Yang
Dear Brian, Chris and Dan Thanks for all your insightful suggestions!
Agree, dashboard is not the key point for Cello, as illustrated in the architecture.
As an initial effort, the core of Cello is to target a backend BaaS engine. And it provides two kinds of front-end RESTful APIs for 1) chain-users and 2) system operators.
To demo the capability, we integrate an operational dashboard for system operators, which is used to create/delete/operate multiple chains. This is of a different goal from what our Explorer does today (to "view/query" status of a chain as a "user-friendly web application"). At the same time, you may notice that there's no default chain-user dashboard in Cello yet, because we'd like to think it's up to the end-consumers, who may want to adopt their own dashboards in different scenarios.
Today, we're very glad to find that Explorer can be a good candidate as the chain-user dashboard, and Chaintool as the chaincode pkg tool for Cello, as practiced by one of Cello's consumers. This opens the possibility to make some "suite", which can be recommended to Hyperledger users after more verifications. To help that, I just got a patchset merged recently to containerize the Explorer as the first step.
It would be nice if Cello can attract more people into the community by taking Hyperledger easily, to adopt fabric, sawtoothlake, iroha and even more as the underly ledger, to use projects like Explorer and chaintool as development tools.
IMHO, besides Cello as the BaaS effort, there are still lots of interesting topics to exploit, e.g., Blockchain+BigData, Blockchain+Cognitive Analysis. We hope to encourage more such ideas and discussions to make the community more energetic.
This is gonna a long-term evolution and need every Hyperledger contributor's help!
Thanks again for all the advice and have a great weekend!
On Sat, Dec 10, 2016 at 12:53 AM, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:
I think we want a big tent while at the same time not proliferating narrow utilities tied to existing projects as separate projects unto themselves.
For example, I do not think it would make sense to spin out the ‘sawtooth cluster’ command as a separate project even though it is a useful way to spawn a network
of validators.
I initially felt that Cello would stand a better chance of success with a broader scope and a broader team, hence merging with explorer.
The committed scope, though, to expand beyond launching Fabric dockers to include the other infrastructure projects (Iroha and Sawtooth Lake) seems like it may
rise to the level of a distinct project.
I’m inclined towards more rather than fewer projects, but I would appreciate hearing views from the rest of the TSC with considerations on repo clutter, dilution,
overhead, etc.
Thanks,
Dan
I see Explorer and Cello as pretty different, actually, with nearly(?) no overlap in functionality other than both expose a web interface to an end user, so let's bring Cello in and let both teams figure out
over time what moves where.
Brian
On December 9, 2016 11:13:30 AM EST, Christopher Ferris <chris.ferris@...> wrote:
+1 I agree, I would suggest we proceed and where it makes sense, we start leveraging more of explorer rather than reinvent the wheel, and where it makes sense we should see function migrate from Cello to Explorer etc.
On Fri, Dec 9, 2016 at 7:58 AM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@lists.hyperledger.org> wrote:
On 12/08/2016 11:54 PM, Baohua Yang via hyperledger-tsc wrote:
Dear TSC members
After last TSC meeting, Dan, Pardha, Satheesh and I make some conversations on
Cello's proposal and the collaborations in community, with more and more projects joining Hyperledger today.
We bring some interesting thoughts together and wish share out for boarder discussions.
(Feel free to replenish if i missed some points.)
1. What kind of project are welcome to Hyperledger?
Hyperledger community should be open to any kind of technical contributions, especially those can fill new scopes, meet different requirements, and work well with existing projects.
Cello is exactly filling the gap of BaaS (Blockchain as a Service) requirement, and its proposed scope will let it work very well with the existing projects, e.g., fabric, sawtoothlake, iroha, blockchain-explorer, chaintool and sdk. It
would be nice to consider Cello as the initial effort towards Hyperledger BaaS platform.
We welcome more such kind of collaboration potentials between different projects, under the same umbrella, while remaining the users' flexibility to choose what projects can meet their requirement best.
My personal read of the conversation: I didn't sense any resistance to the idea of Cello, whether a Blockchain-as-a-service application would belong at Hyperledger, amongst the TSC or the people at the HackFest or anywhere else. This seems to fill an important
need when it comes to building and managing the "dev ops" side of running a chain. I think the question with respect to Explorer was simply whether these belonged as two separate projects from day one, or whether the scope of Explorer could be expanded to
also include Cello. I think this broader question is still interesting - how big is our big tent? - but w/r/t to Cello I'd say don't worry about it. Others?
My personal take: we should bring it in and not worry up front about forcing two different codebases (and potentially two different communities) to integrate before getting started. If it makes sense technically or from a product perspective, it'll happen.
More granularity between projects early on means a faster way to run experiments (as Dan Middleton put it at the member summit) and keep an eye to building a more scalable community.
2. How to encourage better collaborations inside the Community?
To encourage more collaboration between various projects from different teams with different programming languages, we may bring up the concept of "suite".
A suite is a collection of Hyperledger projects, to achieve some open-to-use solution for specific scenarios, e.g., for Cloud scenario, for BigData scenario, for stock-trading scenario. This can help mitigate the technical challenge for
users adoptions, and also help develop teams of the same suite to work more close with each other.
After enough practical adoptions, we may provide various community-recommended suites, just as the Linux, OpenStack and BigData communities do.
Right. There could will be some projects under the Hyperledger banner which are aggregations of the output of other projects, plus maybe new code too. It could be, for instance, that over time, Fabric makes sense to divide into a handful of smaller
projects to make it easier to build a community around each, with well-defined APIs in between, and then the "Fabric" project would aggregate those pieces together along with an installer and other glue code and be the larger combined work. Likewise, Cello
might incorporate Explorer's code and functionality as one screen tab among several within Cello - no problems at all with that.
Brian
Would be glad if these ideas can attract more thoughts.
Look forward to hearing more insightful comments!
--
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
