At PyCon US 2023, David Lord facilitated an open space discussion of "maintainer burnout, how to survive it, and maybe how to prevent it." Here are some notes (incorporating his; thanks, David!), my analysis, and useful links.

The first thing I'll share: my guide for maintainers, "Handling Burnout and Career Planning", which I published last year in the Open Source Collective guides collection. Its sections "Start with the end," "Concrete steps towards maintainer succession", and "Perfectionism, procrastination, and burnout" address a lot that we discussed in the Open Space.

1. Noticing that you're burning out
2. Work approaches that can help
3. Succession, sustainability, and new folks
4. Maintainer as parent
5. Deprecating components, and closing a project
6. Further resources

Noticing that you're burning out: We discussed trying to notice early or subtle warning signs that you're burning out, such as if saying "no" to someone causes you anxiety, or when you feel resentment when you get an email notification from GitHub. I wrote about this a few years ago in "On Noticing that Your Project is Draining Your Soul". This week, Shauna Gordon-McKeon wrote a "Burnout Checklist": a list of questions for contributors and maintainers to ask ourselves.

Some participants reported a cyclical burnout feeling -- they get fatigued, aversive, and bored with their projects every so often, and simply need to wait it out to regain their motivation. That oscillation is likely pretty normal:

Wellness is not a state of mind, but a state of action. It is the freedom to move through the innate cycles and oscillations of being human - from effort to rest and back, from connection to autonomy and back, from adventure to homecoming and back. But we have been lied to our whole lives about what wellness 'should' look like, and rejecting that lie, all those myths about 'having it all' and 'finally achieving lasting peace' is how we create space in our lives for that free action through the cycle of being human. -- Emily Nagoski and Amelia Nagoski, Burnout.

The website for the Nagoskis' book Burnout includes, in the therapists' guide to using the book, a few thought-provoking questions:

Work approaches that can help: As a maintainer, you have choices about how you run your project. And changing some of your project's structures and expectations can help with the availability expectations, toil, and bruised feelings that contribute to burnout.

We as an industry ought to normalize that different projects might have different levels of openness to contribution.

As an analogy: we sometimes use the "No Maintenance Intended" badge to indicate that we're just sharing a codebase for public reuse but aren't expecting to update it, respond to bug reports, or integrate patches. Similarly, we ought to recognize that sometimes an open source project with an OSI-compliant license is "open source" on a legal sense but is not culturally, socially open source in its workflow -- and that it's okay for some projects to intentionally choose that approach, as long as they are clear and kind in setting and explaining expectations!

I say "some projects" because I feel different when Android does this compared to when SQLite does this. For one thing, I hear SQLite is clearer in laying down guidelines about what will and won't be accepted, from whom, and why. Here it's worth considering the ten project archetypes that Mozilla and Open Tech Strategies described (source), where some project types (such as Trusted Vendor, Bathwater, and Rocket Ship to Mars) simply are not interested in welcoming contributions from users. More recently, Nadia Eghbal's 4 quadrants divided by high-to-low contributor growth and user growth help us consider "stadium" and "toy" projects using different expectations for openness to contribution.

Maintainers, and maintainer teams, should also actively take vacations. For instance, one open space participant pointed to GoToSocial, which takes several weeks off every December and January. The team shuts down all of its incoming communications and doesn't read issues at that time, and announces that ahead of time so people can have clear expectations. Open space participants agreed, I think, on the idea that maintainers should take at least one month off per year.

Another timing suggestion from a participant: delay releasing a new version until a bit after putting all the work in for the release. I believe the reasoning is: rest a little bit, and enjoy the feeling of accomplishment. Then get mentally prepared for the new questions, support requests, and bug reports you'll get after publishing the new version, including invalid bug reports and unfair criticism. And then hit Publish.

Unfair criticism is a hazard maintainers often deal with. One participant suggested avoiding reading feedback that comes from drive-by critics on Reddit and similar sites, since even those who aren't being intentionally malicious often lack context and so their criticisms are nearly useless. (In fact, I'd argue that such complaints are not feedback at all! Feedback is when output from a system is directed back into it, and when we use it in an interpersonal sense, we mean that the giver of the feedback is intentionally offering it to the system in the hopes of improving how the system works. If the person complaining is writing to be read by other users, and their goal is to advise them or to vent their spleens rather than to improve the project in question, then it might be informative and relevant, but it's not feedback.)

I suggest maintainers do what people who face online harassment frequently do: use the buddy system. Ask a colleague from another project to go read the rants people have written about you over on various social media platforms, and report back with a summary of any genuine threats or useful bug reports, and then return the favor for them sometime.

Reducing how personal these things feel is partly an interior, mental skill, but as one participant pointed out, bureaucracy can take pressure off individuals too. If a release comes from The Release Team, or a report's supposed to go through a formal procedure, then any one maintainer is perceived to have less personal responsibility for any particular unpopular decision or backlogged task.

Succession, sustainability, and new folks: Folks come and go. How do we find, keep, and train new folks so we can eventually turn a project over to them and leave?

I've written a guide to recruiting, retaining, and nurturing contributors. For example:

Create structured opportunities for new contributors to interact with you and come aboard. You can join well-known apprenticeship programs like Google Summer of Code and Outreachy, or run courses like Drupal Ladder, but even if you don't have the dedicated mentorship time for those efforts, you can try smaller initiatives. For example, to improve communication and grow relationships, run regular "PR test Fridays" -- every Friday, make experts available who will help newcomers walk through how to test pull requests and help with the code review load.

To help you with succession planning, I've also written a guide to choosing and promoting co-maintainers, with sections including "assess contributor retention," "patterns in your promising contributors," "approaches to retain and upskill existing contributors," "Approaches to attract new maintainer-track contributors," and "Exercise: make a draft plan to promote someone." And for some additional thoughts, I have a 2015 post, "How to improve bus factor in your open source project."

Participants reported wanting guidance on balancing growing contributors with getting things done efficiently. They write contributor guides but find that new volunteers do not read long, detailed contribution guides, so they would like help nailing down how detailed to make them, and designing those documents to be appealing and legible to their particular audiences. It can help to ask new contributors explicitly, one-on-one, about their goals: "do you want to be a long-term member of this project? Are you only here to get this one thing fixed? Do you need help that I can provide?"

It takes a lot of time to put in that one-on-one relationship-building work. Sometimes it doesn't pay off, because the volunteer's skills grow very slowly, or they don't seem to be able to level up the way they're aiming to. I wrote a few years ago about how to teach and include volunteers who write poor patches; one way is to encourage them to use their enthusiasm in other ways, such as by being cheerleaders to newcomers. When I mentioned this in the open space, we discussed one pitfall of that approach: enthusiastic volunteers, serving as project ambassadors, can make promises beyond your ability to keep them. That's addressable if you have a direct conversation with them, as a manager would, but of course that's an additional headache for the maintainer!

And all that volunteer nurturing work also can feel like a treadmill, especially when volunteers leave, and in particular when they disappear without a farewell and don't respond to your messages. We can do retention work and try to keep up with our current and past contributors by consistently keeping in touch with liminally active contributors, but that work is also a source of stress and an additional responsibility. A maintainer has so many roles to take on, so many hats to wear! And so much of that work is ongoing, chore-like work reacting to others' needs, or checking up after others' omissions and mistakes, or threading through tangled-up piles of neglect.

Maintainer as janitor or parent: What do we mean when we say "maintainer"? What expectations do we have about what work they're supposed to do?

In a separate conversation at PyCon, I spoke with a maintainer of a very widely-used project about the difficulty of finding co-maintainers. At first I thought we were both using "maintainer" as meaning "person with the privilege of committing to the main branch and publishing a release." Which means you can seek, train, and promote contributors who demonstrate engineering judgment and integrity; even if they can't co-lead the technical development of the project right now, at least you have another person who can perform many necessary tasks: review code, mentor new contributors, respond to feedback, develop the roadmap, and so on. But, in further conversation, it emerged that this particular project sometimes needs to respond quickly to certain kinds of bug reports, such as reports of security vulnerabilities, which means that my colleague wishes he could find a few more people who, like him, could be consistently on-call.

I mulled over our conversation after PyCon, and realized: for this project, it's not enough to add more janitors, who are trusted to clean up messes and hold the keys. This project needs more maintainers who act like parents for this project. A parent is consistent, on-call, and reactive, and watches out for new threats. The role requires not just engineering judgment and integrity, but also the temperament, attention, and capacity to respond immediately and make good-enough decisions immediately.

Thinking about this helped me articulate part of what burns out maintainers, especially solo maintainers and especially volunteers. They're on-call, usually without any formal expectations (such as a Service Level Agreement), with few or no colleagues to help them in those moments of crisis -- even to just confer and get a second opinion, much less get skilled assistance in assessing the situation, drafting a response, and replying to follow-up questions. Maintainers often expect themselves to be attentive to every need, and every potential need, their project develops, and the over-entitled subsection of their user bases perpetuate that; it's easy for the observation "you could do this" to seamlessly transform into the demand "I should do this." And it reminded me of an observation from a book I love, Pat Barker's World War I novel Regeneration, about the exhaustion inherent in certain kinds of leadership positions where power and responsibility are all out of balance. A mental health professional is thinking about the military officers he's treating:

Okay, yeah, it's over the top to compare open source maintainers to officers fighting a war. But. If that last line resonates with you anyway, it's ok to want rest and help. (Hey Shauna, maybe something about this can go in the burnout assessment checklist?)

One approach that might help, for projects that have or can raise some money: hire a contractor, part-time, with the expectation that part of what you're paying for is on-call availability. Train them in your project, get their domain knowledge up to the same level as yours, and pay them for a few hours per month of code review. And specify in your contract that if an issue comes up that needs a quick response, they'll be on it within 2 hours. I don't know of any projects that have done this, but it seems like it would work.

Deprecating components, and closing a project: Everything ends. How can you responsibly end bits of a project, or all of it?

Maintainers in the open space mentioned that they'd like better guidance on how to deprecate and close a project, or how to deprecate a feature. They want help figuring out the technical aspects of communicating changes, and setting support expectations in their documentation. For a few sample policies on deprecation, check out pip's general deprecation policy and the deprecation timeline for the new resolver introduced in 2020. I've also found it's very useful to set up a very low-traffic email list that only carries deprecation notices and announcements at a similar level of importance, such as pypi-announce. For more on setting up a good communications system in general, check out my guide "Marketing, Publicity, Roadmaps, and Comms."

We all agreed that you can leave. You can quit! There is always an escape hatch; you can close your project, and that's okay. Maintainers sometimes resist thinking about taking a break or leaving because we perceive ourselves to have made an unbreakable commitment, an obligation that nothing else can supersede, even our own mental health. (I talk about this more in my burnout handling guide.) But when I talk with maintainers about that perception, and ask them what specific promises they have made, that often helps them reconsider their assumptions, and review their options.

You can leave responsibly. One participant reported that a sudden departure -- "smokebomb and disappear" -- can feel great in the moment, but leaves him feeling guilty afterwards. I started Volunteer Responsibility Amnesty Day to help maintainers and similar folks regularly review our commitments and then publicly set expectations for reducing them. You can update a README, blog, mailing list, and other communication channels to indicate that you are sunsetting a project, seeking a new maintainer, etc., or that you will be doing so, say, one month later. For examples, see how Jacob Kaplan-Moss, Will Kahn-Greene, and Joey Hess have used the Amnesty Day to review or set down a few things. The next Volunteer Responsibility Amnesty Day is on June 21st; mark your calendar.

Further resources

The most comprehensive resource on maintaining open source projects is Karl Fogel's Producing Open Source Software, which you can read for free online.

I've described several other books, guide collections, and other maintainer resources in this list from 2021, which I have updated since then.

And another participant recommended Gabriella (Biella) Coleman's book Coding Freedom: The Ethics and Aesthetics of Hacking.

I'm working on a book on how you can improve your existing open source project, and I'm grateful to the participants in the open space for questions and thoughts that I want to address in that book. You can read three sample chapters by signing up for my newsletter.

Finally: I run Changeset Consulting, and anyone reading this is eligible for a short free 30-minute consultation call about maintainer burnout. Email me or message me on Mastodon.