DEV Community

Cover image for How to sunset your OSS Project with Grace
Joe Mainwaring
Joe Mainwaring

Posted on

How to sunset your OSS Project with Grace

Participating in the open source community is often a thankless job. What starts out as a productive use of excess time can quickly spiral out of control if a project becomes popular. Maintainers can become overwhelmed by the pressures of maintenance, feature requests, and dealing with expectations from the community. Some even come to resent their work being used by for-profit entities.

Recently, the OSS maintainer Marak decided to withdraw from popular npm packages colors and faker.js. While I can't speak much to his reasoning behind the decision, his execution created chaos, confusion, and broke thousands of dependent packages. The move was akin to quitting a job without providing two-weeks notice, and setting the office on fire as you walked out the door.

When it comes to walking away from an OSS project, the simplest path is not always the correct one, especially if that path burns bridges and makes enemies. Here are some suggestions on how to sunset your open source project with grace:

Transfer Ownership

In some situations, it may be possible to pass the baton for another to carry. This could be a fellow contributor on the project who is willing to accept the burden of ownership. It could also be a company, as there's a growing number of businesses who are interested in maintaining and securing OSS projects. Depending on the popularity of your project, you may even be in a position to sell the ownership rights instead of giving them away.

Publish a Final Release

Similar to putting in a two-weeks notice at your job, it's important to communicate the final state you're leaving the OSS project in. Even if you don't plan to address outstanding maintenance or feature requests, you should still publish one final release where you update the project README and communicate that the project is no longer being maintained. If you're feeling generous, you can suggest alternative projects, but it's not a necessary component to a sunset communication.

Disable Github Issues

Given that not everyone will read the notice at first, I also encourage maintainers to go into the repository settings in Github and disable the Issues feature. This will prevent users from filing new issues, creating less noise in your inbox. A user who goes to file an issue and can't will either stumble their way onto the sunset notice or give up on the package and seek one that is actively maintained.

Archive Project

Similar to Disabling the issues feature in Github, you can go into the repository settings for your project and Archive the repository. This will make the project read-only and Github will display a banner notice at the top of the page to inform those who happen across your abandoned project.

Image description

Have you sunset an OSS project before? What did you try that did or did not work? Share your experiences below in the comments.

Top comments (2)

shinigami92 profile image

I did exactly what you suggested e.g. with:

And today I'm working at 🙌

booleanhunter profile image
Ashwin Hariharan

I agree with your thought process, something I wish I did when I sunset my OSS project few years ago. It was an early React-based admin dashboard project:

GitHub logo booleanhunter / ReactJS-AdminLTE

ReactJS version of the original AdminLTE dashboard (EXPERIMENTAL)-



ReactJS version of the original AdminLTE dashboard - This project consists of widgets, charts and other components written in ReactJS. Stylesheets are borrowed from the AdminLTE project.


Thank you kindly for the and forks. When I first started working on this project in 2015, I had just graduated from college and had no prior exposure to web-development or open source. I was very new to the open-source world, and did not fully grasp the challenges in maintaining an open-source project sustainably.

For few months while I was working in a fast-paced startup, I moved my focus away from ReactJS to focus on other technologies. But by the time I once again tried to resume work on this project, the ReactJS core library, tooling and ecosystem had changed so rapidly that this repository practically needed a rewrite from scratch. As evident from the number of issues

I've outlined my reasons for it in the project README, but to summarize it here, it was mainly due to the following:

  1. After an early release, I went about with my regular job as I wasn't doing great financially. A few months later when I thought of working on it again, React (the library) had changed quite a bit.
  2. Issues on the Github repository kept coming, and I didn't know whether to make a quick fix, or just restart from scratch (because of the library updates).

So for a while I was pretty much playing a game of catch-up with React, until I no longer could, at-least not when I still had a regular job. I also tried to pitch the project in local programming meetups (in the hopes that someone might take the lead in maintaining it), but they were also in the same bucket as I. Like me, they also had full-time jobs and family commitments so they simply didn't have the time to code outside of their work.

So finally made the sad decision to sunset it. 😞