Page tree
Skip to end of metadata
Go to start of metadata
Status

RESOLVED 

Blocking
OutcomeApproved
Minutes Link2020 04 30 TSC Minutes

Overview of Proposal

The proposal is to move the Blockchain Integration Framework (BIF) lab into a Hyperledger Project.

The formal proposal, which is linked from the next section, was completed with the following information:

We also recommend reading the whitepaper if you have technical questions.  Many of the most commonly asked technical questions that are not answered directly in the project proposal document may be answered there.

Formal Proposal(s)

Blockchain Integration Framework (BIF) proposal (Blockchain Integration Framework Proposal.pdf)

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

Reviewed By


7 Comments

  1. I do not think this is ready to become a project at this time.
    I also recall that one of the reasons they are requesting to become a project is to get more attention and I have concerns about that being the main motivation.  I understand the chicken and egg problem, but you if there's real interest, you can build a community without being a project.

    1. Thanks for the comment!

      Can you elaborate on what you think is necessary for the BIF to be ready to become an incubated project, or why the BIF is not ready?  Currently there aren't really any guidelines for what projects need to become an incubated project other than what is stated in the project proposal document, which is relatively minimal.  We don't want to waste both our time and the TSC's time if there are unwritten readiness guidelines of which we aren't aware that haven't been met, but it's difficult for us to make a decision based on information we don't know.  So, would you mind outlining some principles for us?  This would be useful to not only us but to any other people coming along looking for project incubation status.

      For the record, most of the projects that have been approved for incubation status in the recent past have not been feature-complete (Besu was obviously a notable exception).  Here are some examples that we used for precedent:

      Transact proposal:  

      Avalon proposal:  Hyperledger Avalon Proposal

      Aries proposal:  Hyperledger Aries Proposal

      Historically, the judgement for project incubation status has been based on whether there is an appropriate community in place to start a successful project rather than a metric on how close the codebase is to production readiness.  We actually do have TWO production-ready blockchain integration/interoperability solutions (from Fujitsu and Accenture), so we feel that our team is up to the challenge and meets this metric of "community in place."  However, if you (and others on the TSC) feel this is no longer the correct metric, we'd love to hear your thoughts.

      In addition, since we have had a number of proposals recently where the proposers thought they were ready but where at least some of the TSC disagreed, it might be time for a task force to write up a more detailed document detailing criteria for achieving project incubation status.  Otherwise there will probably be a lot of continued frustration on all sides.

    2. To further elaborate:  our motivation for "getting attention" was to make sure that others in Hyperledger weren't working on a blockchain interoperability solution that would substantially overlap with ours, and if they were, that we could collaborate in the future.  We don't want to increase fragmentation.  If there were other solutions out there, we wanted to make sure we could architect in a way that made future collaboration easy. 

      That being said, we think our current community and contributor base is more than enough to successfully build a production-grade BIF.  As we mentioned before, we already have 2 different interoperability solutions (one from Accenture, one from Fujitsu) that are being used in the wild.  So this really isn't a chicken and egg problem for us of getting more contributors, it's more of a "speak now or forever hold your peace."

      So, in summary, our purpose in this was not to gain new contributors (although we would welcome them).  We recognize that most of the development work done in Hyperledger is company-based and recruiting true independent contributors through interest in a project is very rare.  Instead, we wanted to make the company-based developers aware of our solution and give the big business folks a chance to look through our architecture before we committed to something that would be difficult to move away from.  We're already working on a large codebase refactoring to merge the Accenture and Fujitsu solutions, and we don't want to have to do another one if another big contributor (most likely in the form of a company dev team) comes along in the future.

      Does this clarify things?  Sorry if it wasn't clear from the proposal document.

      1. Thanks @hartm - this is very helpful.  It's possible that based on something I thought I heard that I interpreted things with the wrong perspective.

        1. Thank you for providing feedback!  It's always better to receive feedback (positive or negative) in advance so that we can provide more detailed responses, so thank you for your comments here.  It would have been hard to spell out the above response in a TSC meeting with everyone trying to talk, so thanks again for bringing up issues here and now.

          As always, if you have any other questions or comments, please feel free to ask.

          I still maintain that we should probably have a task force to detail a more fine-grained criteria for project incubation status.  In an ideal world, projects should know for themselves with a high degree of certainty whether they are likely to be approved or not for incubation.  This would save both the TSC and people looking to contribute projects to Hyperledger quite a bit of time and frustration.

  2. We'd also like to encourage people to ask questions (either here, on the TSC list, or directly on the proposal document) in advance of the TSC meeting, if possible.  This proposal has burned through a ton of time at recent TSC meetings, and we'd like to minimize the overall disruption to the TSC.  You all are busy people!  In addition, sometimes a little offline preparation can make answering a question much easier (e.g. some questions are much more easily answered with a diagram, which isn't necessarily the easiest thing to find or produce in a meeting).

    If there is anything else that you all think we should present in the TSC meeting (for instance, a non-financial use case was discussed at the last meeting) please let us know as well so that we can put something together.

    Thank you all very much for your time!

  3. In support of BIF

    Joseph Orlicky was an engineer at IBM when he first constructed the principles of MRP (materials requirements planning). Orlicky's MRP, the first edition published in 1975 sold 175,000 copies; the third edition is on Amazon. Effectively open sourcing the bill-of-materials processor that when combined with the general ledger and SQL databases underpins today’s vendor ERP industry. Many facilities run ERPs (enterprise resource planning systems) that are decentralized.

    Traceability generally requires integrating the ERPs to trading systems for master purchase orders, traditionally with EDI, lately with smart contracts. Tier 1 ERPs from SAP and Oracle are often interfaced with tier-2 ERPs for both contracts and synchronisation of MRP. Few tier-3 ERPs are interfaced with tier-2 because the cost of integration is too high. Difficult to solve because many ERP codebases have over 20 years of investment.

    As of January 22, 2014 there were 195,518 food facilities registered with the FDA for U.S. Food Safety Modernisation Act (FSMA) traceability. The U.S. Drug Supply Chain Security Act (DSCSA), also includes a provision to register facilities by 2023.

    BIF offers a bridge to solve the digital divide between ERP systems designed for operations and blockchain designed for trading. Once a bridge is in place we can expect further convergence. Because DLT was designed for secure internet trading, unlike MRP/ERP that was designed in a prior PC-era, unconcerned with computer insecurity and distributed systems issues.       

    Trust is key to adopting new databases for long term mission critical investments. More so because Hyperledger success will attract business consultants who often find creative ways to integrate without an in-depth understanding of fundamentals.   

    Cosmos is working with Agoric, where Mark Miller (erights@github) is the leader in SES (secure ECMAScript) and technologies such as frozen realms for memory safe membranes to compose secure web plugins. SalesForce is already a platform adopter and contributor to realms at TC39 toward secure multiparty environments.

    Hyperledger projects address complex businesses requiring a resilient BIF built with a plugin architecture for the diversity and inclusion of open source contributions.