When an Apache project moves to the Attic, it has reached end of life. The Attic provides oversight of the code and its resources but is not intended to fix bugs or make releases. If you depend on a retired project, plan to fork it, adopt a successor, or replace it.
What the Attic is
The Apache Software Foundation created the Attic in November 2008 to make it clear when a project has reached its end of life. It oversees projects that would otherwise have no oversight. Its own description says it is not authorized to actively develop and release the projects under its care.
The stated goals are modest: be non-impacting to users, provide restricted oversight for the codebases, and look after active user lists for projects that no longer have a Project Management Committee (PMC). The stated non-goals matter more to you: it is not meant to rebuild a community, make bugfixes, or make releases.
How a project ends up there
There are two routes. The project's PMC decides to move it, or the foundation's board dissolves the PMC and moves the project. The Attic's guidance lists typical candidates: a PMC that cannot muster three votes for a release, a project with no active committers, or one that cannot meet its reporting duties to the board.
The retirement process includes informing users, updating project metadata, and asking the foundation's infrastructure team to lock down project resources. In practice that means the repository and downloads stay visible, but the project stops moving.
What it means for you
| Situation | Practical meaning |
|---|---|
| You use a retired project | No new releases or fixes should be expected from the project |
| A vulnerability is published later | Do not wait for an upstream patch |
| You need the code to keep working | You carry the maintenance, or you move |
| Someone forks it | That fork is a separate project with its own maintainers |
The Attic does describe ways a project can come back: a fork outside the foundation, a restart through the Incubator, a recreated PMC, or a transfer to an existing PMC willing to take on all the responsibilities of running it. Retired Incubator projects stay under Incubator oversight instead.
Steps to take
- Find every place the project is used, including indirect use through another library.
- Record the retirement date from the project's Attic page.
- Check whether a named successor or an active fork exists, and read the fork license obligations checklist before adopting one.
- Decide: replace, fork internally, or accept the risk with an owner and a review date.
- Set an alert so that a new advisory against the retired project reaches you.
For the general case outside Apache, see what to do with an archived GitHub dependency.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a single component appears across several projects, which is the view you need when a dependency is retired.
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
Does the Attic fix security bugs in retired projects?
Its own description says it is not intended to make bugfixes or releases. Treat a retired project as unmaintained.
Can a retired Apache project be revived?
Yes. The Attic lists forking outside the foundation, restarting through the Incubator, recreating a PMC, or transferring to an existing PMC.
Sources
Last reviewed: 19 October 2026.
