It’s okay for your project to end

Nothing lasts forever, particularly in technology. Some notable projects have been around for 30–40 years, but most don’t last that long. A 2014 study (PDF) found that 46% of projects are inactive over the last six months. Sonatype’s 2023 study (PDF) found that only 11% of projects are actively maintained. So it’s time to come to terms with the fact that our projects won’t live forever.

A project ending doesn’t have to be a bad thing. In fact, the end of a project can be a sign of success. Or at least partial success. So why might a project end?

A larger project absorbs the functionality. When I first started using the TTYtter client for Twitter, it did not have support for replying to all users. What it did have was an extension architecture that allowed me to write ttytter-r2a. Eventually, @doctorlinguist incorporated similar functionality in mainline TTYtter, which made my plugin obsolete. That’s success, in my opinion.

The ecosystem no longer exists. When Twitter shut off free API access, it no longer made sense to continue work on oysttyer (the fork of TTYtter). I’m not sure you can call this success, but it’s out of your control.

You don’t feel like working on it anymore. Let’s be honest: if you’re working on an open source project for fun, eventually it will stop being fun. Or at least your priorities will change such that you don’t have the time to contribute like you used to. If you’re the sole maintainer, then at some point you may decide to end the project instead of pretending that you’ll get back to it “real soon now”. Of course, you could also find other maintainers to take it on. But if no one steps up, you’re not obligated to maintain it forever.

The company that sponsored it doesn’t see value in it anymore. A company I used to work for had a few small tools that they published under an open license. The tools mostly implemented support for easier interactions with the HTCondor scheduler in some way. Over time, the company’s revenue shifted from HTCondor support and consulting to broader cloud-based high-performance computing. The projects still worked, but they were essentially abandonware. The only mistake there was not being more honest with ourselves about it (but also, we didn’t have a lot of (any?) external contributors, so it probably didn’t matter).

It’s just not going to work. Sometimes, for whatever reason, the project is not going to work. It’s better to admit that and stop working than to continue throwing effort at it. Kaylea Champion had a great writeup about the end of the IEEE Open Source Project Governance Standard Working Group. The group voted to dissolve itself because “because the framework under which IEEE standards are developed was ultimately not compatible with the way that participants wanted to proceed.” With that kind of unresolvable incompatibility, giving up was the most successful outcome.

This post’s featured photo by Dim Hou on Unsplash.