Introduction
Software projects do not have a strictly linear lifecycle, but they typically move through the lifecycle stages in this order:
When a software project begins its goal will be to move to the Graduated stage.
1. Proposal
A software project is in this stage if it has been submitted to a Working Group as a proposal.
How to submit a proposal:
Any GSF member can submit a proposal. It should be submitted to a Working Group using the New Project Proposal issue template.
‣
Proposal-writing tips and tricks:
A Proposal must:
- Have a clear description
- Have a well-defined scope
- Identify committed development resources
- Identify initial maintainers
- Be vendor-neutral
- Have identified any risks
- Describe what success looks like
- Know its audience/community
Moving to the next stage:
Approving body: Working Group
As above, any software project idea can be proposed to a Working Group for consensus approval. We have low barriers to entry at this stage: a proposal will be refined over the project’s lifecycle into something truly awesome and impactful.
‣
Approval criteria
To move to the next stage, the proposed project must:
- Have an assigned GSF PM
- Have a representative of at least one member organization of the GSF.
- As the project moves through its lifecycle, this representative will attend the parent Working Group, champion the project, volunteer to lead it, and provide updates.
The project’s name must:
- Have the approval of the GSF Marketing team
- Not be trademarked
Please note that similar / competitive projects are allowed. Projects are not excluded for reasons of overlap.
‣
Approval process
- Proposal template is submitted by GSF member to the Working Group.
- Working Group gives consensus approval.
- Assigned GSF PM submits an issue to the Oversight Committee repo for awareness. The Oversight Committee has 2 weeks to comment / object.
- If a proposal is deemed by the Working Group or Oversight Committee to be high risk (e.g. there is reputational, financial, legal, or greenwashing risk), it must also be reviewed by the Steering Committee and the Executive Director.
2. Incubation
The project is in its iterative stage: it is being explored by the project team.
What features does an Incubated project have?
Incubated projects are where collaborative development happens. Therefore:
- They must be publicly accessible in a designated repository
- The repo must contain the following disclaimer at the top of the README file and all other public-facing documentation:
[!important] Incubation Project This project is an incubation project being run inside the Green Software Foundation; as such, we *DON’T* recommend using it in any critical use case. Incubation projects are experimental, offer no support guarantee, have minimal governance and process, and may be retired at any moment. This project may one day graduate, in which case this disclaimer will be removed.
What are the benefits of an Incubated project?
When a project is in Incubation, it is considered an official GSF project. This means it gets the resources it requires to move through the remainder of the lifecycle, including:
- A project environment that fosters collaborative, open development and provides a path to maturity via the graduation process
- Marketing support from GSF, including:
- being listed on the GSF website and in our newsletter updates;
- the opportunity to participate in GSF events; and
- shout-outs and connections via social media.
- Mentorship in areas such as, but not limited to:
- project management;
- governance;
- legal;
- tooling;
- security best practices; and
- documentation.
Moving to the next stage
Approving body: Working Group Chairs
‣
Approval criteria
In addition to the criteria from the previous stage, the project must have:
- An active set of contributing members from at least two member organizations
- A public GitHub repo with clear project documentation that sets out:
- the project overview (README)
- how to contribute (contributing.md)
- end-user guide (enablement.md)
- test coverage
- how it fits within GSF Theory of Change
- evidence of utility through real world use cases in the production environment, including testimonials (adopters.md)
- how it meets 100% of the applicable criteria for the Open SSF Best Practice Badge (security.md)
- Made a release deployment, even if this is a ‘developer preview’
- An incident process agreed with GSF PM
- GSF processes set up including:
- a project team mailing list
- regular project meetings
- the provision of regular updates to the Working Group
- defined OKRs agreed by the assigned GSF PM
Note that although similar / competitive projects are allowed, the project should not directly contradict another GSF Graduated project.
‣
Approval process
- Project lead(s) submit an issue to the Oversight Committee repo.
- GSF PM (and project lead(s)) join the next Oversight Committee meeting to demonstrate that their project meets the approval criteria above. Approval is reached by consensus.
- Once Oversight Committee approval is gained, the GSF PM must submit an issue to the Steering Committee repo for awareness. The Steering Committee has 14 days to review and comment on the project.
- If there are no comments the submission will be approved automatically. However, if any comments were made, the project team addresses them at this point. The Steering Committee must then agree that the comments have been addressed.
- Once consensus is reached, the project is approved. If there are sustained objections, the chairs may carry on trying to reach a consensus or a vote can be held to move the project forward.
3. Graduated
The project is considered mature and stable. It is supported by an active community.
Features of a Graduated project
In a graduated project:
- At least version 1 of the project is released and publicly available
- Contributors may continue to explore further versions of the project
- The repo must contain the following disclaimer at the top of the README file and all other public-facing documentation:
[!important] Graduated Project This project is a Graduated Project, supported by the Green Software Foundation. The publicly available version documented in the README is trusted by the GSF. New versions of the project may be released, or it may move to the Maintained or Retired Stage at any moment.
Benefits of a Graduated project
Graduated projects:
- Have the backing of the GSF;
- Receive marketing support to celebrate the graduation of the project;
- Replace the ‘Incubation’ disclaimer with one that shows it is a trusted project supported by the GSF.
Moving to Maintained
Approving body: Working Group Chairs
A project moves from Graduated to Maintained when the Project Team notifies the GSF PM that they are no longer actively working on the project, but will continue maintenance.
‣
Approval process
- Project lead(s) submit an issue to the Working Group Chairs repo.
- Working Group Chairs approve via consensus.
Moving to Archived
Approving body: Working Group Chairs
A project moves to Archived when the Project team notifies the GSF PM they can no longer commit to maintaining the project.
‣
Approval process
- Project lead(s) submit an issue to the Working Group Chairs repo.
- Working Group Chairs approve via consensus.
4. Maintained
The project is considered Graduated but new versions (excepting for bug fix maintenance) are not being released
Features of a Maintained project
Maintained projects must:
- be maintained by their team
- keep their repo open for contributions
- contain the following disclaimer at the top of their repo’s README file and all other public-facing documentation:
[!important] Maintained Project This project is in maintenance being run inside the Green Software Foundation. Releases are maintained but not improved. This project may be retired, or reactivated back into incubation.
Benefits of a Maintained project
Maintained projects:
- remain under the GSF umbrella
- can re-enter incubation stage and become active again
Moving to Incubation
Approving body: Working Group Chairs
A project moves back from Maintained to Incubation when the Project team notifies the GSF PM they can begin actively contributing to the project once more.
‣
Approval process
- Project lead(s) submit an issue to the Working Group Chairs repo.
- Working Group Chairs approve via consensus.
Moving to Archived
Approving body: Working Group Chairs
A project moves to Archived when the Project team notifies the GSF PM they can no longer commit to maintaining the project.
‣
Approval process
- Project lead(s) submit an issue to the Working Group Chairs repo.
- Working Group Chairs approve via consensus.
5. Archived
The project is considered dormant and any releases are no longer being maintained.
Features of an Archived project
Archived projects:
- are not maintained by their community.
- cannot be moved back to any other stage: if contributors want to restart the project, they must raise a New Project Proposal issue.
- must contain the following disclaimer at the top of their repo’s README file and all other public-facing documentation:
[!important] Archived Project This project is archived and is no longer being run inside the Green Software Foundation. Releases are *NOT* maintained or improved. This project cannot be reactivated.