Your SCA checks for CVEs. It doesn't check whether anyone is still maintaining the software. That's a different question, and until now, no tool answered it well. We track lifecycle status across 12M+ package versions using official EOL declarations and ML-based detection of maintainer abandonment. Upload a package.json, pom.xml, requirements.txt, or any SBOM and see exactly what's still maintained and what isn't. Direct and transitive deps. Every major ecosystem. Free of charge.
Last year, our engineering team ran 200+ dependency analyses by hand. Same job every time: a customer would come to us and say, "We need to know what's end-of-life in our stack." We'd dig through their dependency tree manually, cross-reference what we could find online, and deliver a report.
Over 200 times we did this. And over 200 times we ran into the same problem.
There is no complete source of lifecycle data for open source software. Not from NVD. Not from your SCA vendor. Not from the registries themselves. The best public source we could find covers about 7,000 package versions. The actual number of EOL package versions in the wild is in the millions.
So we asked the obvious question: if nobody has mapped which open source packages are dead, why don't we do it?
That was 14 months ago. Here's where we are now.
The dataset tracks 12M+ package versions across npm, Maven, PyPI, NuGet, Go, Cargo, and others. Two data sources feed it. First, official EOL declarations from maintainers and foundations. Second, and this is the part that took the most work, ML-based detection of maintainer abandonment. Because most open source doesn't get a formal end-of-life announcement. The commits just stop. The issues pile up. And the package sits on the registry looking perfectly healthy while nobody is home.
We found 81,000+ package versions in exactly that state: known CVEs, zero remediation path, no maintainer coming to fix them. And here's the detail that surprised even us: 93% of that risk sits in transitive dependencies. Packages your team never chose, never reviewed, and probably doesn't know exist.
The scanner isfree. Upload a package.json, pom.xml, requirements.txt, go.mod, or any CycloneDX/SPDX SBOM. We resolve the full tree and show you what's dead, what's dying, and what's fine. Takes about five minutes.
No credit card. No agents. No code changes.
Two things I'd genuinely love from this community:
Coverage gaps. If you scan your stack and find a package or ecosystem we're not tracking, tell us. We're actively expanding and your feedback goes straight into the backlog.
Honest reactions. Does this actually save you time? Is the output useful? What's missing? We built this because we needed it ourselves 200+ times last year. I want to know if it solves the problem for you too.
No comment highlights available yet. Please check back later!
About EOL Dataset on Product Hunt
“Find every EOL dependency in your stack. Free. In 5 minutes.”
EOL Dataset launched on Product Hunt on April 22nd, 2026 and earned 65 upvotes and 1 comments, placing #35 on the daily leaderboard. Your SCA checks for CVEs. It doesn't check whether anyone is still maintaining the software. That's a different question, and until now, no tool answered it well. We track lifecycle status across 12M+ package versions using official EOL declarations and ML-based detection of maintainer abandonment. Upload a package.json, pom.xml, requirements.txt, or any SBOM and see exactly what's still maintained and what isn't. Direct and transitive deps. Every major ecosystem. Free of charge.
EOL Dataset was featured in Open Source (68.4k followers), Developer Tools (511.7k followers) and Security (2.6k followers) on Product Hunt. Together, these topics include over 82.6k products, making this a competitive space to launch in.
Who hunted EOL Dataset?
EOL Dataset was hunted by Mat Parker. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how EOL Dataset stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Mat Parker
Last year, our engineering team ran 200+ dependency analyses by hand. Same job every time: a customer would come to us and say, "We need to know what's end-of-life in our stack." We'd dig through their dependency tree manually, cross-reference what we could find online, and deliver a report.
Over 200 times we did this. And over 200 times we ran into the same problem.
There is no complete source of lifecycle data for open source software. Not from NVD. Not from your SCA vendor. Not from the registries themselves. The best public source we could find covers about 7,000 package versions. The actual number of EOL package versions in the wild is in the millions.
So we asked the obvious question: if nobody has mapped which open source packages are dead, why don't we do it?
That was 14 months ago. Here's where we are now.
The dataset tracks 12M+ package versions across npm, Maven, PyPI, NuGet, Go, Cargo, and others. Two data sources feed it. First, official EOL declarations from maintainers and foundations. Second, and this is the part that took the most work, ML-based detection of maintainer abandonment. Because most open source doesn't get a formal end-of-life announcement. The commits just stop. The issues pile up. And the package sits on the registry looking perfectly healthy while nobody is home.
We found 81,000+ package versions in exactly that state: known CVEs, zero remediation path, no maintainer coming to fix them. And here's the detail that surprised even us: 93% of that risk sits in transitive dependencies. Packages your team never chose, never reviewed, and probably doesn't know exist.
The scanner is free. Upload a package.json, pom.xml, requirements.txt, go.mod, or any CycloneDX/SPDX SBOM. We resolve the full tree and show you what's dead, what's dying, and what's fine. Takes about five minutes.
No credit card. No agents. No code changes.
Two things I'd genuinely love from this community:
Coverage gaps. If you scan your stack and find a package or ecosystem we're not tracking, tell us. We're actively expanding and your feedback goes straight into the backlog.
Honest reactions. Does this actually save you time? Is the output useful? What's missing? We built this because we needed it ourselves 200+ times last year. I want to know if it solves the problem for you too.