Introduction
The Linux Foundation Networking umbrella consists of multiple projects. This document describes the lifecycle of those LFN projects. Each LFN project governs itself. LFN projects may consist of multiple subprojects with their own lifecycles. This document's scope is limited to top-level LFN projects. The TAC is responsible for facilitating communication and collaboration among the technical projects. They are also responsible for making informed recommendations to the projects about best practices and collaborative opportunities. In addition, they inform the LFN Governing Board about projects under the LFN umbrella and any project seeking to join the LFN. This page will help your project communicate its overall status, which in turn can help the TAC provide the best opportunity for your community's success.
Project Lifecycle
LFN projects have a lifecycle characterized by Project State defined by their maturity.
Project States
Project State | State Summary |
|---|---|
| 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 | 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. |
Click here for more details about the Project Review Process
Guidelines
The guidelines presented in the table below are not strict requirements that must be met for each lifecycle stage. Instead, they represent goals and standards that communities should strive to achieve as they progress through the lifecycle stages. Meeting more of these guidelines will increase the likelihood that a proposal for induction or advancement to the next stage will be accepted.
It is essential to recognize that these guidelines are suggestive and can be adapted to the unique circumstances and needs of each project. The Technical Advisory Council (TAC) will evaluate proposals on a case-by-case basis, considering the overall health, maturity, and potential of the project in its review process. Flexibility and context-specific judgment will be applied to ensure that the lifecycle process fosters innovation, inclusivity, and growth within the LFN ecosystem.
This table is provided as guidance to a Project seeking induction or promotion to the next tier.
| Coding | Sandbox | Incubation | Graduated |
|---|---|---|---|
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. |
| Development Governance | Sandbox | Incubation | Graduated |
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. |
Documentation | Sandbox | Incubation | Graduated |
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 | 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. |