When an Open Source project reaches the end of active maintenance, the issue tracker can become confusing fast. Users keep reporting bugs. Contributors ask whether pull requests are welcome. Old issues contain valuable workarounds, but new issues create false hope.
Ending a project well does not mean deleting everything or pretending the work never mattered. For public benefit software, especially in education, accessibility, security, and civic tools, the issue tracker may be one of the most useful records you leave behind. It shows what worked, what broke, who depended on the project, and what a future maintainer or fork should know.
Here is a practical way to close or freeze an issue tracker without losing its value.
Why This Stage Matters
Open Source projects often outlive their original maintainers. That is part of the strength of open work, but only if the project leaves clear signals behind.
A messy issue tracker can harm users after maintenance ends. People may spend hours writing bug reports that no one will answer. A school may assume an education app is still supported. An accessibility tool user may depend on a workaround buried in a closed thread. A security-conscious developer may not know whether vulnerability reports are still being reviewed.
Software for Progress Foundation supports Open Source developers because useful software should reach the people who need it. Sunset work supports that mission too. A well-closed issue tracker helps people make informed choices instead of guessing.
Step 1: Decide Whether to Close, Freeze, or Leave Open
Before changing settings, choose the right end state. Different projects need different levels of closure.
- Close new issues: Best when no one is available to review reports and you want to avoid false expectations.
- Freeze existing issues: Best when old issues contain useful research, but you do not want new comments to create confusion.
- Leave issues open with a warning: Best only if someone is still lightly watching the project or a new maintainer may appear soon.
- Move discussion elsewhere: Best if a fork or successor project is active and users should report problems there instead.
The key is not the exact setting. The key is that users can tell what will and will not happen next.
Step 2: Add a Clear Tracker Status Message
Your repository may already have a sunset notice, but the issue tracker needs its own message where users file reports. Put the status in the issue template, pinned issue, discussion banner, or contributing file.
Use plain language. Avoid vague phrases like inactive for now if you already know the project is ending.
A useful message can say:
- Project status: This project is no longer actively maintained.
- Issue status: New bug reports are not being reviewed.
- Security status: Security reports are not guaranteed to receive a response.
- Useful links: Final release, documentation, export guide, known forks, or migration notes.
- Respectful thanks: Acknowledge users and contributors who helped the project.
This is not just administrative cleanup. It is a way to respect people’s time.
Step 3: Label the Issues That Still Have Legacy Value
You do not need to perfectly triage every issue before stepping away. But a small amount of labeling can make the archive much more useful.
Focus on labels that help future readers understand what they are seeing:
- Known bug: The problem is real and reproducible.
- Workaround available: The thread contains a usable temporary fix.
- Documentation needed: The issue explains a common confusion.
- Breaking change: The issue explains a behavior people depended on.
- Good fork candidate: The issue could guide future maintainers.
- Won’t fix: project sunset: The issue is valid, but no maintainer is available.
Do not overdo it. Ten carefully labeled issues are often more helpful than two hundred untouched ones.
Step 4: Close Issues With a Reusable, Honest Response
If you are closing many issues, use a short saved response. This prevents burnout and keeps the tone consistent.
For example:
Thank you for reporting this. This project is no longer actively maintained, so we are closing open issues as part of the sunset process. We are leaving this thread visible because it may help future users, maintainers, or forks. If you have found a maintained alternative or fork, you are welcome to mention it in the project’s designated migration discussion.
This response does a few important things. It thanks the reporter, names the real reason for closure, preserves the public record, and avoids promising future work.
Avoid closing issues with only stale, invalid, or no activity labels. Those may be technically accurate, but they can feel dismissive when the real reason is that the project has ended.
Step 5: Preserve High-Value Threads Before Locking
Some issues are more than bug reports. They contain user research, accessibility feedback, deployment notes, translations, or security context. Before locking the tracker, identify the threads that future users are most likely to need.
For each high-value issue, consider adding one final maintainer comment:
- Summarize the confirmed problem.
- Link to the final known workaround, if one exists.
- Name the affected versions.
- Clarify whether the issue is unresolved.
- Point to migration or export instructions if relevant.
For example, imagine an Open Source screen reader training app used by volunteer tutors. An issue thread explains that audio prompts fail in one browser, but several users found that a specific browser setting fixes it. If the project is ending, that thread still has public benefit. A final summary comment can save future tutors from digging through fifty replies.
Step 6: Handle Security Issues Separately
Security reports should not be treated like ordinary bug reports. If no one will monitor vulnerabilities, say so clearly.
At minimum, update the security policy or repository notice to explain:
- Whether security reports are still accepted.
- Whether anyone is available to release fixes.
- Which versions, if any, should no longer be used.
- Whether users should migrate away for sensitive use cases.
This can feel uncomfortable, but silence is worse. A project that is no longer safe for certain uses should say that plainly so communities can protect themselves.
Step 7: Leave One Place for Legacy Updates
After closing or freezing the issue tracker, you may still want one controlled place for important legacy information. This could be a pinned discussion, a migration issue, or a maintained readme section.
Use it only for information that helps users move forward:
- Known active forks.
- Maintained alternatives.
- Final release notes.
- Data export instructions.
- Important warnings about unsupported use.
Do not create a new support channel unless someone is ready to support it. The goal is to reduce confusion, not move the same problem to a new location.
TL;DR
A project’s issue tracker is part of its legacy. When active maintenance ends, do not let it become a place where users ask for help that will never come.
- Choose whether to close, freeze, or leave issues open with a clear warning.
- Add a visible tracker status message.
- Label the issues that still have value.
- Close issues with an honest, respectful response.
- Summarize high-value threads before locking them.
- Handle security expectations separately.
- Keep one controlled place for legacy updates.
Ending an Open Source project well is not failure. It is a final act of care for the people who used your work, learned from it, and may carry it forward.