Retiring an Open Source Project Gracefully
Running an open source project can be demanding—but that commitment isn't a lifetime sentence. Usage may dry up as superior alternatives emerge, ecosystems may shift until maintenance feels like a treadmill, or your own interests may simply move elsewhere. When those moments come, a clean exit protects both your reputation and your users. Maintainers who have been through it offer clear guidance on what to do—and what to avoid.
Don't cling to a project past its time
Holding on too long is a common regret. Computational biologist Olga Botvinnik says her one piece of advice to her younger self would have been to sunset prettyplotlib, her Python data-visualization package, sooner than she did. The project had grown out of her PhD work, migrating it to Python 3 felt like an overwhelming chore, and its luster had faded next to the increasingly polished and popular Seaborn library.
Botvinnik ultimately decided the better move was to deprecate her project and redirect her efforts into contributing to Seaborn. A mentor's words eased the transition: knowing when to end a project counts just as much as finishing one.
Do look for a successor before walking away
Deprecation isn't necessarily the first option. Brett Terpstra, a front-end developer who maintains over a hundred GitHub repositories, has retired many projects—but he first makes an effort to find a new maintainer. There are degrees to sunsetting, he notes: some projects are simple enough to need little upkeep, in which case a simple note saying you rarely update it, while leaving the door open for contributions, may suffice.
Passing the torch doesn't always fit, though. When Ben Johnson decided to retire BoltDB, he chose instead to send users to the BBolt fork rather than hand his project to another person. "My name and reputation were pretty closely tied to the project at the time," he says. "I didn't want to put my reputation in the hands of someone else."
Don't disappear without warning
When a project is truly ending, its users deserve time to adapt. Terpstra gives at least a month's notice before retiring anything. "Even if I'm immediately done working on a project, I leave the 30-day window open to take care of issues and help users transition," he says.
A public announcement with an alternative is part of the process. For her part, Botvinnik says she wrote a blog post and tweeted that she would no longer actively fix bugs, pointing people toward Seaborn as the replacement.
Do archive the repository, don't delete it
Archiving a repository is almost always better than deleting it. Archiving makes the project read-only, rendering issues, pull requests, milestones, and permissions read-only as well—clear communication that maintenance has ceased. It's also reversible: you can unarchive and resume work at any time.
Deleting code can have side effects you didn't intend. "Anyone thinking about taking their software offline should consider whether they might be creating reproducibility problems for people in science and academia," Botvinnik warns. Keeping the code public also means someone else might still take a useful idea from it later, even if no one stepped up to fork it before you shelved it.
The exception is code that's genuinely dangerous—software carrying security vulnerabilities that put its users at risk, for instance. In such cases, taking it offline may be the responsible move.
