A maintainer who needs to step away should pick a successor they trust, hand over access on purpose, document the project's vision, and say publicly what is happening. The Open Source Guides say there is no shame in asking someone else to take over, either for a hiatus or permanently.
Why handoffs are a security event
Control of a project is control of what users install. A handoff done in a hurry, to someone nobody vetted, is a known path to trouble: see the event-stream handover. A careful handoff is the opposite: planned, visible and reversible.
What the guidance says
The Open Source Guides suggest:
- If you need to step away, on hiatus or for good, ask someone else to take over.
- If other people are enthusiastic about the direction, give them commit access or formally hand over control.
- If someone forked the project and is maintaining it, consider linking to the fork from the original.
- Document your vision. The guide quotes the Dokku founder, who wrote a wiki page about what he wanted and why, and found maintainers moved the project in that direction after he left.
- Ground rules and shared ownership reduce the load while you are still around. The guide encourages documenting how others can grow into leadership roles.
A safer handoff checklist
| Step | Why |
|---|---|
| Choose a candidate with a visible record in the project | You can judge their work |
| Start with limited access, then widen | Trust builds over time |
| Add them as co-maintainer before you leave | See add a co-maintainer safely |
| Move the repository to an organization with two owners | See two organization owners |
| Transfer registry ownership deliberately | See npm ownership transfer steps |
| Remove your own access when done | See offboarding checklist |
| Announce it in the README and release notes | Users can see who is responsible |
What to say publicly
A short note is enough: who is taking over, from what date, how to reach them, and where the vision and governance files live. If no successor exists, say so and say what users should do. The guide's advice to be honest about available time applies here too.
If nobody is ready
You can mark the project as unmaintained, archive the repository, or point to an active fork. See archive, transfer or delete when retiring a repository. Silence is the worst option, because users keep depending on a project with no one behind it.
What users can do
If you depend on a project whose maintainer announces they are leaving, offer help, ask who is taking over, and start a contingency plan in parallel. See how to help maintainers without money. 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 hand over to the first volunteer?
Not without checking their record in the project. Start with limited access and widen it as trust builds.
What if someone already maintains a fork?
The guide suggests considering a link to the fork from the original project.
Sources
Last reviewed: 19 October 2026.
