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

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!

--

Best wishes!

Baohua Yang

_______________________________________________
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.