Project Incubation Entry Considerations

This document provides information to help people who are considering bringing their projects to LF Decentralized Trust (hereafter “LFDT”) for Incubation. Specifically, it will outline items that the TAC 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 TAC. 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 LFDT is to provide a space for projects that have high potential to grow in the community. Ideas should start in Labs.

Considerations

When considering projects that are proposed for incubation to LFDT, the TAC 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.

Roadmap

A project is more likely to succeed if it publicly states its intent and estimated timelines for how the project evolves. LFDT’s governance model allows for projects to go through an annual review process against its roadmap. The roadmap 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., Cacti, FireFly); while others previously had stand alone governance prior to joining (e.g., Besu).
  • DCO sign off should be enforced in the code repository as it transitions to LFDT. Historical commits that existed in the repository before a decision to transition the project to LFDT was made do not need to be squashed, in order to preserve metadata.

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 TACs.
  • 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 TAC is more likely to accept projects that have contributors familiar with open source practices. Contributing to existing LFDT projects or starting in LFDT 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 LFDT. Project names must be approved by the LFDT 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 (see allowed third-party licenses)
    • 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 LFDT.

Overlap with Existing Projects

There should be a distinct advantage for a new distributed ledger project. 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.
  • Distributed ledger projects without a proven track record of adoption would not be considered.

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