Candidate

Projects looking to integrate with the LFN umbrella of projects may be inducted at any lifecycle state, provided it meets The Linux Foundation's proven best practices for success. 

Sandbox

The Sandbox stage is designed to provide a lightweight entry process for new projects that align with the LFN mission and follow the guidelines described below.  It is ideal for early-stage projects that require time to explore their community, governance, and technical roadmap.

Incubation

The project meets all the prerequisites for the Sandbox stage. Furthermore, the Incubation stage is intended for projects that have implemented open source best practices, including having a varied contributor base and adhering to open governance principles. Projects at this stage should actively cooperate with other LFN projects, engage in cross-LFN endeavors, or contribute to broadening or reinforcing the LFN's scope.

Graduated
(TAC Project)

The project has fulfilled the Incubation stage requirements and exhibited project diversity, compliance with open source best practices, and active participation in LFN. Moreover, the project has established a documented release process that has been consistently followed. As a result, the project has progressed to the Graduated TAC Project stage, and now has a voting representative on the TAC.

Archived

A project can be Archived if it has received no significant commits within the previous 12 months or if the Project's TSC requests archiving. An Archival Review will be initiated to determine if the project meets the criteria for archiving.

Code Scanning

An intake scan is conducted to ensure basic security and license compliance.

Scanning is done on an ad-hoc cadence to catch any potential issues early, allowing for timely resolution.

In addition to regular scans, mature tooling and processes are in place to scan all new code submissions, ensuring continuous security and license compliance.

Seed code handoff

A date for seed code handoff is planned and communicated to stakeholders.

Seed code handoff is completed. It's mandatory at this stage to ensure that the project has a solid foundation to build on.

At this stage, the seed code handoff is already completed (mandatory). The project is now focusing on iterating and improving upon this initial codebase.

Coding Standards

Coding standards are loosely defined, allowing for flexibility and creativity in the early stages of the project.

A moderate set of coding standards is enforced to ensure code quality and maintainability without stifling innovation.

Strict coding standards are enforced to ensure high code quality, maintainability, and consistency. Regular code reviews are conducted to ensure these standards are adhered to.

Adding/Removing Committers

Mandatory - Projects must have a documented process for adding and removing committers.  

Mandatory - The need for committers may shift as the project grows and evolves, hence it's necessary to have a mechanism for adding/removing them.

It's essential at this stage to build a diverse and inclusive team of committers to facilitate the project's progress.

Mandatory - As the project matures, maintaining the right set of committers is crucial to ensure high quality and continuous progress.

Adding/Removing PTLs (Project Team Leads)

Not required at this early stage, roles might be more informal and fluid.

Mandatory - As the project grows, it's necessary to have designated leaders (PTLs) steering different aspects of the project and a process to add or remove them.

Mandatory - At this mature stage, the mechanism to add/remove PTLs is crucial for maintaining effective leadership and governance.

Sub-Project Lifecycle

Not required at this early stage, the focus is on the core project.

Adding a sub-project - The project may grow and expand into different areas, requiring the addition of sub-projects.

Adding, advancing, and archiving a sub-project - As the project matures, there's a need for mechanisms to add new sub-projects and advance or archive them based on their activity and relevance.

Sub-Projects Without a Designated Lead

Allowed - At this stage, sub-projects might not yet be formalized

Not recommended - It's important to have a designated lead for each sub-project to ensure its progress and alignment with overall project goals.

Not allowed - At this mature stage, every sub-project must have a designated lead to ensure effective management and progress.

Dispute Resolution

Not mandatory, but it's beneficial to have some basic dispute resolution mechanism.

Mandatory - As the project and its community grow, it's important to have a defined process for resolving disputes.

Mandatory - With a mature and larger community, a clear dispute resolution process is crucial to ensure a healthy and harmonious community.

TSC/TOC Governance 

Appointments OK - At this early stage, key roles can be appointed to steer the project.

Some Meritocracy - As the project progresses, the governance should start to transition towards a merit-based system, though some roles might still be appointed.

Full Meritocracy - At this mature stage, all governance roles are based on merit. Contributors who have demonstrated their commitment and made significant contributions earn their roles.

Technical Documentation

Build - Initial creation of technical documentation to guide early adopters and contributors.

Build, deploy - Comprehensive technical documentation is developed and deployed, covering the necessary details of the project's functionality.

Build, deploy, test, debug, upgrade - Extensive documentation is maintained, providing instructions for various tasks, including testing, debugging, and upgrading the project.

Contributor onboarding Documentation

Not required at this early stage.

Simple - A basic set of documentation is made available to guide new contributors.

Detailed - Comprehensive documentation is provided, covering all aspects of contributing to the project, from setting up the development environment to submitting patches.

Company Diversity (past 12 months)

variable

variable

6 companies suggested to maintain diverse and balanced representation.

# of Contributors
(past 12 months)

Few - At this early stage, the focus is on setting up the project and attracting initial contributors.

10 or more as a target - As the project grows, it attracts more contributors.

More than 2 dozen - As the project matures, the number of contributors increases, reflecting the project's growing community and impact.

Release Management

RM consultation with LFN (minimum) - At this stage, the release management process is being set up with guidance from LFN.

Processes established and documented - The release management processes are well-defined and documented, providing clear guidance to the project community.

Processes followed to deliver a release - Mature projects should be following a well-established, documented release process to deliver each release.

CI/CD

Manual - At this stage, the project might rely more on manual methods for integration and deployment.

Somewhat Integrated - The project starts to integrate some aspects of CI/CD into their development process.

Mostly Integrated - Most parts of the development process are automated through CI/CD, improving efficiency and reliability.

Adoption

Not a focus at this stage.

Not a focus at this stage.

At least one end user - For a graduated project, it's expected that at least one end user has adopted it.

Security design principals

Not a focus at this early stage.

OSSF Scorecard has been established and is being tracked as work in progress 

OSSF Scorecard is 80% to "Passing" or better - Mature projects are expected to maintain or improve their OSSF Scorecard performance, demonstrating a continuous focus on security.