Project Incubation Entry Considerations

This document provides information to help people who are considering bringing their projects to Hyperledger for Incubation. Specifically, it will outline items that the TOC will take into consideration when evaluating the project, as well as, some best practices that have been followed by other projects prior to the project proposal being submitted to the TOC. Our hope is that this document will smooth the entry process for new projects being proposed. The project proposal process and the template for project proposals are outlined outside of this document. The goal of Incubation within Hyperledger is to provide a space for projects that have high potential to grow in the community. Ideas should start in Hyperledger Labs.

Considerations

When considering projects that are proposed for incubation to Hyperledger, the TOC will consider the following items: codebase, maintainers, community, sponsors, legal, and overlap with existing projects. The below items are not hard and fast rules for projects being accepted. The considerations are a guide to project proposers. If you meet most of the considerations, you are most likely to be accepted. If you do not meet any of the considerations, you are most likely to not be accepted.

Goal Setting

Every project team has a vision for why they exist. The project is more likely to succeed if it sets annual goals with expected outcomes. Hyperledger Foundation’s governance model allows for projects to go through an annual review process against these set goals. The goal evaluation helps the stakeholders, and the community that is invested in the project to anticipate what’s coming next. This process will open-up collaboration opportunities to those having similar interests.

Codebase

  • Code should exist as open source software in some form. Previous accepted projects have come up through labs (e.g., Cactus, Ursa); while others previously had stand alone governance prior to joining (e.g., Besu).
  • DCO sign off should exists in the code repository. If not 100% ready, the code must be capable of becoming compliant upon entry (i.e., squash commit).

Maintainers

  • The project should have multiple maintainers. These maintainers need not be from different companies; however, having maintainers from different companies is seen as a positive sign. Proposals with only one maintainer have been rejected by prior TOCs.
  • The project should have demonstrable examples of POC/production uses publicly available.
  • The project should have the backing of more than one organization/individuals (i.e., the project proposers should be able to demonstrate significant, long term contribution in codebase).

Community

  • The TOC is more likely to accept projects that have contributors familiar with open source practices. Participating in existing projects or starting in Hyperledger Labs is a great place to grow this experience.

Sponsors

  • Sponsors are advocates for the project. There should be more than one sponsor, and they should be from different organizations. They may or may not be committing resources to the project.
  • Trademark concerns – project names should not be trademarked by a contributing company or if it is, then the trademark will need to be handed over to Hyperledger. Project names must be approved by the Hyperledger marketing committee
  • Projects do not require a name prior to being submitted.
    • Codebase should be Apache 2 licensable, without encumbrances
    • Non-Apache 2 licensed code is possible, but requires Governing board approval (Section 12 subsection d of the Hyperledger Charter)
    • Special examination should be given to copyleft and non-licensed code.
    • Required patent licensing issues have prevented projects from entering Incubation.
    • GPL licensing issues have prevented projects from entering Incubation.
  • If code does not already have copyright, the code should be modified to include copyright as per Copyright and License Policy prior to being brought into Hyperledger.

Overlap with Existing Projects

  • The TOC has mentioned that they are not interested in bringing in additional distributed ledger projects. There should be a distinct advantage for a new distributed ledger project. This will be similar for other types of projects. In general, if a project is similar to an existing project, there should be a distinct advantage that the project brings over and beyond the existing project and that this cannot be contributed directly to the existing project.
  • New projects should bring something to the table that current projects do not.

Best Practices

The following best practices have been identified by previous proposals.

  • Discuss the new project proposal within the community prior to submitting to the TOC for consideration. You might do this through existing chat channels, mailing lists, or direct communication with members of the community.
  • Make sure that any links provided in the proposal are publicly available.
  • If you need an introduction into the Hyperledger Community, the Learnings Material Development Working Group will provide a good introduction.