Klint: How did you know when it was time to sunset a project, as opposed to handing it off to new maintainers?

Ben: By the time I decided to sunset BoltDB, the CoreOS team had already created a fork called BBolt. I didn't want to just hand the project over to someone else and the fact that a fork existed made me more comfortable saying I wasn't going to update Bolt anymore. My name and reputation were pretty closely tied to the project at the time. I was the BoltDB guy. I didn’t want to put my reputation in the hands of someone else. It made more sense to me to make a clean break and point people at a fork.

Olga: First of all, maintaining a project takes a lot of work. When I sunset prettyplotlib, I was in graduate school, dealing with research, publishing, and everything else that was going on with my life. I didn't feel like I had time to keep pushing prettyplotlib forward. I was still using Python 2.7 because I had used it throughout grad school. I wasn't sure how much work it would be to migrate prettyplotlib to Python 3. It was a big unknown. I was feeling guilty about stopping work on prettyplotlib since so many people were using it, but one of my mentors told me that knowing when to end a project is just as good as finishing it. That made me feel a lot better about letting it go.

By that time, another Python visualization library called Seaborn was becoming more popular. In my opinion, the design was better in many cases. prettyplotlib was my first big Python library, so it was rough around the edges in places. I didn't know a lot about packaging at the time. Seaborn seemed more polished. It made more sense to me to use and contribute to Seaborn, and point other people to that, rather than trying to keep prettyplotlib going.

Brett: I always have multiple projects going at once, so projects that require little maintenance tend to fall off my radar. If I start getting bug reports for something I no longer have an interest in developing, I have to make a judgment call as to whether I want to invest in the update. I usually make the decision based on its adoption rate, but also my level of motivation. If I have evidence that more than 50 people are actively using the project, it's probably worth a bug fix, assuming it's not an inordinate amount of work. If I've lost interest, it's a rewrite, and/or less than 50 people are using it, it's probably time to retire it or find someone from the community willing to take it over. Projects that rely on APIs and other outside applications often require more work than is worthwhile once things start to break. Historically, those are the projects that get retired the fastest. Also, there are different degrees of sunsetting. In some cases, I might not actively maintain something, but I still accept pull requests from other people.

The case of nvALT is a little different. I just couldn’t justify the amount of unpaid work that went into nvALT, so I decided to develop a new, commercial version called nvULTRA, rebuilt from the ground up with all-new code. The nvALT source code will still be available, but unmaintained.

Klint: Once you’ve made the decision, what are the early steps of deprecating a project? How did you communicate with users about the end?

Brett: I try to give at least 30 days notice when retiring a project, and offer alternatives early, if possible. 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. Most of my utilities are distributed through package managers, so end-of-life statements are sent through there. I always make a blog announcement, and if I know I’m not touching it anymore, I'll update the README and archive the repository.

Olga: I spread word through a blog post and a tweet announcing that I wasn't going to actively fix bugs anymore and pointed people to Seaborn instead. prettyplotlib wasn't a huge project with zillions of contributors or users, it was a small community. People were pretty supportive of my decision, which was a relief.

Ben: I got the info out there by making an announcement in the BoltDB README. I had already announced that the project was feature-complete, so I don't think it came as a big surprise to people. I tweeted it out and word spread quickly. It was on Reddit, it was on Hacker News. If anyone wanted a replacement I pointed them to the BBolt fork.

Klint: It looks like for the most part you’ve all kept your code online, as opposed to deleting the repos. Why is that? Is there a scenario where you'd suggest taking code offline, as opposed to just archiving it?

Olga: I didn't see any reason not to leave the code up. It was used for research and needs to be able to be shared so people can reproduce their results, so it really didn't make sense to take the code away from people, so long as they know that it's not still being maintained. Anyone thinking about taking their software offline should consider whether they might be creating reproducibility problems for people in science and academia.

Ben: The only reason I can think of to take code down is if it's somehow bad or dangerous. For example, if you realized that you made something that was actually morally wrong. But I think most code is morally ambiguous, neither good nor bad.

Brett: I generally keep code available unless it presents an active security risk. If people want to fork and improve it, I'll ask that they keep me updated and I’ll link to their work. A lot of my utilities include techniques and methods that I think could be valuable to someone trying to solve a related problem. I often use GitHub similar to the way folks use StackOverflow: to look for a solution to a particular problem buried in a repository's code. I want my solutions to be available for that purpose, even if the bulk of the code is no longer maintained, or possibly doesn't function anymore. And it’s obviously much easier for someone to fork an unmaintained project if I keep the code online.

Klint: Is there anything you'd do differently if you could go back? Or are there any common mistakes you'd warn other people about?

Olga: I don't know if I would do anything differently, but if there was one thing I would tell my younger self, it would be that people will find alternatives. You'll be fine, the world will be fine. You should be proud of what you did. The guilt doesn't help anyone.

Ben: I agree. I would have deprecated BoltDB a good year or two earlier. Many people feel obligated to keep maintaining things, especially if it's the first time you've had an open source project take off. It gets easier to let go as time goes on. As far as mistakes other people have made: I don't think it's helpful to throw a fit and just take your code offline. I understand being frustrated by open source and needing to walk away from projects for mental health reasons, but taking your work offline has negative consequences for others.

Brett: These days I make sure from the very beginning that I have a built-in way to notify users of end-of-life. That way I can effectively notify everyone actively using a tool with the sunset announcement and recommended alternatives. I wish I could go back and do this for all of my old projects as well.