When maintainers retire a dependency, you have three paths: adopt an active fork or successor that someone else maintains, fork it and maintain it yourself, or replace it with a different library. Pick by how deeply the code is embedded, who is already maintaining a fork, and how much maintenance work your team can carry.
Why the choice is yours
Retirement means the original team stops releasing fixes. The Apache Attic, for one, states it is not intended to make bugfixes or releases. Open Source Guides add that maintainers who step away can hand control to someone else, and that if someone is actively maintaining a fork, they should consider linking to it from the original project. So a successor may exist. Do not assume it does.
The three paths
| Path | When it fits | What you take on |
|---|---|---|
| Adopt an active fork or successor | A fork has recent releases, several maintainers and a clear license | Vetting the new maintainers, tracking their governance |
| Fork and maintain it yourself | Code is small, stable and deeply embedded, and no good successor exists | Security fixes, builds, releases, license duties |
| Replace | A maintained alternative offers the same job, and migration cost is acceptable | Migration work and retesting |
Questions that decide it
- How much code depends on it? A utility used in two places is easy to replace. A framework core is not.
- Is there a maintained fork? Check dates, authors and whether the fork is linked from the original. Verify that it is the real continuation, not an impostor: see verify authenticity.
- Is the license clear? Forking brings duties. See the fork license checklist.
- Can your team patch it? An internal fork needs people who can read and fix the code. See internal fork rules.
- Is the risk high? A retired parser that handles untrusted input matters more than a retired formatter.
Steps
- Inventory every use, direct and indirect.
- Rate each use by exposure to untrusted input.
- Pick a path per use, not one for the whole company.
- Set an owner and a date for the decision.
- Define exit criteria. See when to retire your fork.
What not to do
- Do not leave the dependency in place with no owner.
- Do not switch to a fork because it has more stars. Check who runs it.
- Do not copy code out of a project without reading its license.
Retirement is a normal event in open source, not a failure to punish. What matters is that you notice and act in a defined time. For the broader picture, see archived GitHub dependency guidance.
Try it yourself
Click through it at your own pace, or open it full screen. Find a component and see how many places depend on it, which tells you how hard a replacement would be.
Safeguard can help with the inventory part. Its SBOM and dependency scanning lists what your projects actually pull in, so you can see which components you depend on and decide where to look closer. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should I always replace a retired dependency?
No. A small, stable, well understood library can be forked internally. Weigh embedding, exposure and team capacity.
How do I know a fork is the real continuation?
Check whether the original project links to it, who maintains it, and its release history. Do not rely on popularity alone.
Sources
Last reviewed: 19 October 2026.
