As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.

To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.

So, what is personal ecology? As described by the Rockwood Leadership Institute, it involves “maintaining balance, pacing, and efficiency to sustain our energy over a lifetime.” This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as defined by the WHO, is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.

By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.

Tips for Self-Care and Avoiding Burnout as a Maintainer:

Identify your motivations for working in open source

Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it’s the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.

Reflect on what causes you to get out of balance and stressed out

It’s important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:

  • Lack of positive feedback: Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
  • Not saying ‘no’: It can be easy to take on more responsibilities than you should on an open source project. Whether it’s from users, contributors, or other maintainers – we can’t always live up to their expectations.
  • Working alone: Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
  • Not enough time or resources: This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
  • Conflicting demands: Open source is full of groups with different motivations, which can be difficult to navigate. If you’re paid to do open source, your employer’s interests can sometimes be at odds with the community.

Watch out for signs of burnout

Can you keep up your pace for 10 weeks? 10 months? 10 years?

There are tools like the Burnout Checklist from @shaunagm that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).

What would you need to continue sustaining yourself and your community?

This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:

  • Lean on the community: Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the Maintainer Community. This can be a great resource for peer support and learning.

    You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.

  • Explore funding: Whether you’re looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on GitHub Sponsors to allow others to sponsor your open source work. If you’re thinking about making the jump to full-time, apply for the next round of GitHub Accelerator.

  • Use tools: Explore tools like GitHub Copilot and GitHub Actions to automate mundane tasks and free up your time for more meaningful contributions.

  • Rest and recharge: Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your GitHub status to reflect your availability! A good night’s sleep can make a big difference in your ability to sustain your efforts long-term.

    If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.

  • Set boundaries: You can’t say yes to every request. This can be as simple as saying, “I can’t get to that right now and I do not have plans to in the future,” or listing out what you’re interested in doing and not doing in the README. For instance, you could say: “I only merge PRs which have clearly listed reasons why they were made,” or, “I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.

Learn to be firm in shutting down toxic behavior and negative interactions. It’s okay to not give energy to things you don’t care about.

Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.

Additional Resources

Contributors

Many thanks to all the maintainers who shared their experiences and tips with us for this guide!

This guide was written by @abbycabs with contributions from:

@agnostic-apollo @AndreaGriffiths11 @antfu @anthonyronda @CBID2 @Cli4d @confused-Techie @danielroe @Dexters-Hub @eddiejaoude @Eugeny @ferki @gabek @geromegrignon @hynek @IvanSanchez @karasowles @KoolTheba @leereilly @ljharb @nightlark @plarson3427 @Pradumnasaraf @RichardLitt @rrousselGit @sansyrox @schlessera @shyim @smashah @ssalbdivad @The-Compiler @thehale @thisisnic @tudoramariei @UlisesGascon @waldyrious + many others!