logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

How-to-abandon-a-FLOSS-project.md (4242B)

    

  1. ---
  2. date: 2018-12-04
  3. layout: post
  4. title: How to abandon a FLOSS project
  5. tags: ["free software", "maintainership"]
  6. ---
  8. It's no secret that maintaining free and open source software is often
  9. a burdensome and thankless job. I empathise with maintainers who lost interest
  10. in a project, became demotivated by the endless demands of users, or are no
  11. longer blessed with enough free time. Whatever the reason, FLOSS work is
  12. volunteer work, and you're free to stop volunteering at any time.
  14. In my opinion, there are two good ways to abandon a project: the *fork it*
  15. option and the *hand-off* option. The former is faster and easier, and you can
  16. pick this if you want to wash your hands of the project ASAP, but has a larger
  17. effect on the community. The latter is not always possible, requires more work
  18. on your part, and takes longer, but it has a minimal impact on the community.
  20. Let's talk about the easy way first. Start by adding a notice to your README
  21. that your software is now unmaintained. If you have the patience, give a few
  22. weeks notice before you really stop paying attention to it. Inform interested
  23. parties that they should consider forking the software and maintaining it
  24. themselves under another name. Once a fork gains traction, update the README
  25. again to direct would-be users to the fork. If no one forks it, you could
  26. consider directing users to similar alternatives to your software.
  28. This approach allows you to quickly absolve yourself of responsibility. Your
  29. software is no worse than it was yesterday, which allows users a grace period to
  30. collect themselves and start up a fork. If you revisit your work later, you can
  31. also become a contributor to the fork yourself, which removes the stress of
  32. being a maintainer while still providing value to the project. Or, you can just
  33. wash your hands of it entirely and move on to bigger and better things. This
  34. "fork it" approach is safer than giving control of your project to passerby,
  35. because it requires your users to acknowledge the transfer of power, instead of
  36. being surprised by a new maintainer in a trusted package.
  38. The "fork it" approach is well suited when the maintainer wants out ASAP, or for
  39. smaller projects with little activity. But, for active projects with a patient
  40. maintainer, the hand-off approach is less disruptive. Start talking with some of
  41. your major contributors about [increasing their involvement][relevant article]
  42. in the administrative side of the projects. Mentor them on doing code reviews,
  43. ticket triage, sysadmin stuff, marketing - all the stuff you have to do - and
  44. gradually share these responsibilities with them.  These people eventually
  45. become productive co-maintainers, and once established you can step away from
  46. the project with little fanfare.
  48. [relevant article]: /2018/06/01/How-I-maintain-FOSS-projects.html
  50. Taking this approach can also help you find healthier ways to be involved in
  51. your own project. This can allow you to focus on the work you enjoy and spend
  52. less time on the work you don't enjoy, which might even restore your enthusiasm
  53. for the project outright! This is also a good idea even if you aren't planning
  54. on stepping down - it encourages your contributors to take personal stake in the
  55. project, which makes them more productive and engaged. This also makes your
  56. community more resilient to [author existence failure][existence failure], so
  57. that when circumstance forces you to step down the project continues to be
  58. healthy.
  60. [existence failure]: https://tvtropes.org/pmwiki/pmwiki.php/Main/AuthorExistenceFailure
  62. It's important to always be happy in your work, and especially in your volunteer
  63. work. If it's not working, then change it. For me, this happens in different
  64. ways. I've abandoned projects outright and sent users off to make their own fork
  65. before.  I've also handed projects over to their major contributors. In some
  66. projects I've appointed new maintainers and scaled back my role to a mere
  67. contributor, and in other projects I've moved towards roles in marketing,
  68. outreach, management, and stepped away from development. There's no shame in
  69. any of these changes - you still deserve pride in your accomplishments, and
  70. seeking constructive solutions to burnout would do your community a great
  71. service.