Fuel the Future of Open Source
Grab your slice of our $20 million Open Source Sustainability Fund
Funding Maintainers.
Backed by Experience.
We’ve written patches for unmaintained codebases, tracked down vulnerabilities where no one else was looking, and kept critical systems running safely without rushed rewrites. This fund builds on that work, so maintainers can keep doing what they do best, with real backing behind them.
Our Criteria and Commitment
Our program criteria focuses on ecosystem hygiene and security to guide and support open-source best practices. We partner with teams to help them meet these standards and provide funding to further strengthen and sustain their impact in the open-source community.
Releases & Versioning
Use predictable, documented versioning (SemVer/PEP 440), announce new releases through all official channels, and clearly mark CVE-related fixes.
Communication & Transparency
Clearly state which versions are supported, deprecated, or EOL, and provide advance notice of changes with timelines appropriate to project size.
Documentation
Define deprecation policies, tag deprecated versions, specify support timelines, and indicate when versions will be entirely removed.
Support & Deprecation Handling
Provide clear adoption/removal timelines, backport critical fixes to LTS only, keep deprecations non-breaking, and surface warnings in changelogs and runtime.
Processes & Tiers
Maintain clear processes for reporting issues and security concerns, define support tiers (Current, LTS, EOL), and encourage migration or alternate support solutions when versions reach EOL.
Select to view by criteria:
Version End-of-Life
- Community is notified of a release when it occurs.
- Should be communicated via all official channels (X/Twitter, GitHub Repo, Website docs, etc).
- Clear definition of what happens when a new version is released.
- Defines impact of major, minor, or patch release.
- When a new version is released, the community knows the up-to-date support status of previous releases.
- Releases that address CVEs are identified as such
- Inform community as to whether or not backport patches mitigate known vulnerabilities.
- It is recommended a project uses an industry standard versioning (eg Semantic Versioning or for PyPi packages, PEP 440).
- If project is not currently following SemVer, versioning structure is predictable, intuitive, and documented for the community.
- Documentation clearly dictates which versions are end-of-life versus supported.
- Announcing releases
- Many small project tend to release a new major version with little to no warning, immediately drop support for older majors; Larger projects tend to forecast new release lines in advance and explicitly indicate a long-term support period for the now-previous release line.
- Announcements for EOL events are made in a timely manner.
- Benchmark timeframes to consider:
- Widely adopted foundational libraries/frameworks: 12-18 months
- Moderately adopted projects (10k+ users): 6-12 months
- Small and/or niche projects: 3-6 months
- If applicable, there is a support period for now-previous release lines to allow time for transitioning or migration.
- Benchmark timeframes to consider:
- End of life events are posted to the official channels of the project.
Migration
- Maintainer-created and community-created migration guides should be provided to users.
- The migration guides should be easy to find on the main site.
- Widely used features that have been deprecated are documented.
- Support options for users desiring assistance are documented when applicable.
- Third party providers of services are referenced in a manner that does not violate any project or foundation guidelines. Requirements for being listed as a provider are appropriate to the project. When listed, providers should have both history and reputation as competent providers of the services listed.
Support Policies
- There is a process in place for the community to report issues.
- There is a process in place to respond to reported issues.
- There is a process in place to report security violations.
- Define version support tiers so that it is clear to the community.
- Example 1:
- Current: Full security vulnerabilities and bug support.
- LTS: Security vulnerabilities only.
- End of Life: No fixes.
- Example 2
- Supported
- End of Life
- Example 1:
- It is clear via documentation to developers which versions are supported versus unsupported.
- Expectations are set as to which versions are recommended for use by developers (supported) versus which are intended as pre-release or development versions.
- Prior to an EOL event, users are encouraged to either migrate OR establish a support solution if migration is currently not an option.
Frequently Asked Questions
Of course, if you can't find the answer you're looking for, feel free to contact us.