Fuel the Future of Open Source
Grab your slice of our $20 million Open Source Sustainability Fund
Funding Maintainers.
Backed by Experience.
At HeroDevs, we’ve spent years helping teams navigate the challenges of deprecated open source software. Through our Never-Ending Support (NES) products, we’ve worked with everyone from startups to Fortune 100 companies to keep legacy code secure, stable, and compliant—long after official support ends.
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.
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
Releases
- 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.
Versioning
- 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.
Announcement Comms and Clarity
- 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.
Deprecation
Documentation
- There is a definition of deprecation
- How it is treated
- If it receives bug fixes / patches
- How vulnerabilities affect these versions
- Tagging is used in all official documents to notate versions that have been deprecated.
- When a new version release occurs that impacts the status of a prior version, there is documentation about which version(s) become deprecated and/or end of life.
- A time frame is specifically mentioned as to when a deprecated version will be removed completely and/or will no longer be supported at all.
- If applicable, project will leverage ecosystem-specific tools to report deprecations.
Support
- There is a recommended timeline for the community to follow for:
- Adoption of new features, and
- Removal of deprecated features.
- There is structure for support of deprecated features. Example:
- Introduced in minor releases
- Removed in next major release
- Critical vulnerabilities are backported in LTS only.
- Deprecations must be non-breaking.
Warnings
- Runtime warnings are added into logs / console while being used.
- Deprecation events show in change logs and release notes.
Support Policies
Process
- 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.
Support Tiers & Documentation
- 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.
- EOL: If critical, security vulnerabilities.
- Example 2
- Latest (or Supported)
- Unsupported
- 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.
Encouragement for Support
- When a version goes EOL, users are encouraged to either migrate OR establish a support solution of migration is currently not an option
- Note: This may be through HeroDevs services so that migration timelines may be established or identified remaining supported on older versions.
Frequently Asked Questions
Get answers to some of our most commonly asked questions.
Of course, if you can't find the answer you're looking for, feel free to contact us.
Of course, if you can't find the answer you're looking for, feel free to contact us.
What is the purpose of this program?
How do I qualify to apply?
How do I apply?
What happens when I apply?
What is the funding amount?
What does the program require? What are the things I need to do to receive a grant?
Will I have support when completing the program activities?
I’m excited to work on the future of my project, but what about versions that are no longer supported? Does the Fund do anything for those?