How to abandon a FLOSS project

Published 2018-12-04 on Drew DeVault's blog

It’s no secret that maintaining free and open source software is often a burdensome and thankless job. I empathise with maintainers who lost interest in a project, became demotivated by the endless demands of users, or are no longer blessed with enough free time. Whatever the reason, FLOSS work is volunteer work, and you’re free to stop volunteering at any time.

In my opinion, there are two good ways to abandon a project: the fork it option and the hand-off option. The former is faster and easier, and you can pick this if you want to wash your hands of the project ASAP, but has a larger effect on the community. The latter is not always possible, requires more work on your part, and takes longer, but it has a minimal impact on the community.

Let’s talk about the easy way first. Start by adding a notice to your README that your software is now unmaintained. If you have the patience, give a few weeks notice before you really stop paying attention to it. Inform interested parties that they should consider forking the software and maintaining it themselves under another name. Once a fork gains traction, update the README again to direct would-be users to the fork. If no one forks it, you could consider directing users to similar alternatives to your software.

This approach allows you to quickly absolve yourself of responsibility. Your software is no worse than it was yesterday, which allows users a grace period to collect themselves and start up a fork. If you revisit your work later, you can also become a contributor to the fork yourself, which removes the stress of being a maintainer while still providing value to the project. Or, you can just wash your hands of it entirely and move on to bigger and better things. This “fork it” approach is safer than giving control of your project to passerby, because it requires your users to acknowledge the transfer of power, instead of being surprised by a new maintainer in a trusted package.

The “fork it” approach is well suited when the maintainer wants out ASAP, or for smaller projects with little activity. But, for active projects with a patient maintainer, the hand-off approach is less disruptive. Start talking with some of your major contributors about increasing their involvement in the administrative side of the projects. Mentor them on doing code reviews, ticket triage, sysadmin stuff, marketing - all the stuff you have to do - and gradually share these responsibilities with them. These people eventually become productive co-maintainers, and once established you can step away from the project with little fanfare.

Taking this approach can also help you find healthier ways to be involved in your own project. This can allow you to focus on the work you enjoy and spend less time on the work you don’t enjoy, which might even restore your enthusiasm for the project outright! This is also a good idea even if you aren’t planning on stepping down - it encourages your contributors to take personal stake in the project, which makes them more productive and engaged. This also makes your community more resilient to author existence failure, so that when circumstance forces you to step down the project continues to be healthy.

It’s important to always be happy in your work, and especially in your volunteer work. If it’s not working, then change it. For me, this happens in different ways. I’ve abandoned projects outright and sent users off to make their own fork before. I’ve also handed projects over to their major contributors. In some projects I’ve appointed new maintainers and scaled back my role to a mere contributor, and in other projects I’ve moved towards roles in marketing, outreach, management, and stepped away from development. There’s no shame in any of these changes - you still deserve pride in your accomplishments, and seeking constructive solutions to burnout would do your community a great service.

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/ [mailing list etiquette]

Are you a free software maintainer who is struggling with stress, demanding users, overwork, or any other social problems in the course of your work? Please email me — I know how you feel, and I can lend a sympathetic ear and share some veteran advice.

Articles from blogs I follow around the net

Allocator Designs

This post explains how to implement heap allocators from scratch. It presents and discusses different allocator designs, including bump allocation, linked list allocation, and fixed-size block allocation. For each of the three designs, we will create a ba…

via Writing an OS in Rust January 20, 2020

Status update, January 2020

This month's status update will be a little lighter than usual due to Christmas holidays. I've still got the chance to send a patches to quite a few projects, and… do a lot of releases! Weston, Wayland, Sway, mako and grim all have or will get a r…

via emersion January 16, 2020


Inspired by Peter Watts’ The Freeze-Frame Revolution and The Island. Each birth is violent in the same way. I erupt into the void, my mirrored surface riotous with gamma radiation, parafluid sheeting from my forced extremities, ripped away by gravitational sh…

via Aphyr: Posts January 15, 2020

Generated by openring