Oliver Roick

Retiring a project

Open-source projects have a life-cycle. They are born because a problem needs to be solved. You start building an initial solution, improve it, fix bugs, and incorporate feedback. Some projects become successful. Their use case is broad enough to attract a large user base and a sufficient number of maintainers that keep the software going.

Others don’t. They never gain traction, and eventually, they die. The reasons for a project to fail are manifold. They address a problem space that is too narrow in scope, the solution does not apply to the problem, or they are just not built very well.

Admitting that a project should be retired is hard. Hours of work go into a project during its early days. Retiring a software project often feels a bit like giving up on your child. Finding the right time to sunset a project seems hard as well – after all, it’s out there, and someone might be using it – but the signals are easy to spot:

Sad Visitor Graph

In that light, it’s time for me to sunset django-skivvy. I wrote the library a few years back during my stint at Cadasta to simplify how we write tests for Django views and to remove repeated boilerplate code. The only project that ever used the library is the Cadasta Platform, which has been on its way out for a while now. The only people who ever filed tickets where Cadasta employees at the time. No-one is visiting the repo, no-one, who hasn’t worked at Cadasta, is watching it, and I can’t even remember the last time someone starred the project. django-skivvy is not in use and investing more time to provide even the most basic maintenance, such as making sure it still works with newer versions of Django, is not worth it.