- Home
- >
- Software Development
- >
- How to Avoid Burnout Managing an Open Source Project – InApps Technology 2025
How to Avoid Burnout Managing an Open Source Project – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn How to Avoid Burnout Managing an Open Source Project – InApps Technology in today’s post !
Key Summary
Managing open source projects can lead to burnout due to overwhelming demands and information overload. Insights from OSCON Europe talks by Katrina Owen, Jo Pearce, and Paul Fenwick provide strategies to mitigate this. Key points include:
- Katrina Owen (Exercism.io Creator):
- Challenge: Rapid growth of Exercism.io led to a flood of bug reports and pull requests, consuming all free time and turning the project into a “soul-sucking slog.”
- Solutions:
- Prioritization: Identified core problems by grouping issues into categories, and addressing root causes, not symptoms.
- Contributor Management: Be kind but firm to avoid being overwhelmed; encourage contributors’ energy rather than expending personal effort to recruit.
- Energy Management: Rejects work-life balance as time-based, advocating for managing energy over tasks.
- Lessons: Hiring a productivity coach and batching tasks failed; delegation wasn’t viable without a team, but strategic prioritization restored control.
- Jo Pearce (Information Overload):
- Problem: Information overload in open source projects causes anxiety, stress, and burnout, as described in Alvin Toffler’s “Future Shock.”
- Strategies:
- Manage Information: Use visual cues (e.g., bullets, paragraphs) and schemas to present digestible information.
- Cognitive Limits: Acknowledge learning limits to avoid information fatigue syndrome, which impairs concentration and health.
- Application: Software development’s constant learning demands make structured information management critical to prevent burnout.
- Paul Fenwick (Kerbal Space Program Contributor):
- Experience: Leading an installer project for Kerbal Space Program caused significant stress, particularly over licensing disputes, leading to burnout and his eventual step-down.
- Recommendations:
- Code of Conduct: Adopt one early (copy existing ones) to ensure a safe, inclusive community and attract quality contributors; avoid “thick skin” rhetoric.
- Accept Imperfection: Use the rule “Is it better than before, including technical debt?” to accept good-enough contributions, boosting morale and participation.
- Plan for Issues: Anticipate defects and inappropriate behavior; establish community norms from the start.
- Self-Care: Acknowledge mistakes, take breaks, and prioritize mental health, even if it means stepping away.
- InApps Insight: Open source project leaders can avoid burnout by prioritizing strategically, managing information effectively, fostering healthy communities with clear conduct codes, and practicing self-care, ensuring sustainable project growth and personal well-being.
Read more about How to Avoid Burnout Managing an Open Source Project – InApps Technology at Wikipedia
You can find content about How to Avoid Burnout Managing an Open Source Project – InApps Technology from the Wikipedia website
Regardless of where you work in the stack, if you work with open source software, there’s likely been a time when you faced burnout and other unhealthy side effects related to your work on open source projects. A few of the talks at OSCON Europe addressed this darker side of working in open source head-on.
Katrina Owen is a developer advocate on the open source team at GitHub, but she is also the creator of Exercism.io, which was the focus of her talk, “The bait and switch of open source.”
Within a few weeks of launching Exercism.io, a couple thousand people were using it, and they started submitting bug reports and pull requests, which was awesome, but it kept her very busy. She was working on it during all of her free time, which became a chore, and it felt like she was working endlessly.
First step was to hire a productivity coach, who was horrified by how Owen was doing everything sequentially. The coach suggested batching activities, but it didn’t help, and she could never get to the end of the task list. Delegation was another suggestion, but there was no one to delegate to. Just dropping a few things was another suggestion, but she didn’t know what to drop.
The real tipping point came when a journalist called her to write an article, which appeared on the front page of Wired. She described what happened next as a “scaling disaster” that generated a huge pile of GitHub issues, and “they all looked equally important.”
Dealing with these issues became a “soul-sucking slog,” causing her to think: “I hate my life, I hate my project.” Someone sat her down to talk to her about prioritization and strategy, which is when she realized that she didn’t really have thousands of problems. There were many symptoms, but fewer problems, which allowed her to began categorizing them into piles and naming those piles to come up with just a few core problems.
Owen said that “contributors are amazing. I’m always so grateful … even when it kind of hurts, it’s still amazing.” Working with contributors is hard, and you worry about hurting people’s feelings. While she wants to be nice, there is a fine line between nice and letting people walk all over you. But you do want to be kind while discussing something the other person might not want to hear.
She also talked about being careful not to expend too much of your own energy to get new contributors, since “it just doesn’t scale; the energy has to come from them.” You can make it easier for people to contribute and take some of those first steps without expending too much of your energy.
“People wonder how do you do it all? … The truth is I don’t. Something always suffers,” said Owen, who admits that she doesn’t think work / life balance really exists when people are trying to balance time. She says that you need to manage your energy, not your time.
Noise Noise Noise
This information overload experienced by Owen and many other open source project leaders has been a common topic of study in cognitive psychology. In another OSCON presentation, “Hacking your head: Managing information overload,” Jo Pearce talks about the idea from Alvin Toffler’s 1970 book “Future Shock” that there are discoverable limits to the amount of change that the human organism can absorb.” Without determining these limits, we may be setting unreasonable demands on ourselves and others.
Such information overload can lead to anxiety, hostility, physical illness, apathy, and depression while leading to stress. There is a never-ending stream of information that we cannot hope to consume within our lifetimes, which leads to information fatigue syndrome along with poor concentration, pervasive hostility, burnout, lowered immune response, and more.
Pearce talked about how “information overload is a learning problem,” which can be addressed by managing the information when we display it for others using visual cues (bullets, paragraphs, and other visual indicators), collecting information into more digestible chunks, and creating schemas.
Information fatigue syndrome is a clear and present danger in software development, Pearce noted. We constantly need to learn. Cognitive psychology can tell us how we learn, and also alerts us that there are limits to how much we can learn.
Another OSCON talk about leading open source projects while looking after your mental health came from Paul Fenwick, managing director of Perl Training Australia. Fenwick spoke about his contributions to the space flight simulation game, Kerbal Space Program. While he is one of the authors of “The Kerbal Player’s Guide,” the talk is about the installer that he wrote, which he describes as “apt-get for Kerbal.”
Fenwick stresses that if you have an open source project, you will have defects, and you will have inappropriate behavior, so you need to plan for this type of behavior. Changing an existing community is really hard, so you want to get this right from the start.
He recommends selecting a code of conduct before you even select a license. Having a good code of conduct says that you care about the safety of your contributors, and it attracts better contributors, but don’t write your own, copy someone else’s. Don’t forget to put a link to your code of conduct in the IRC topic and the contributing.MD file. “Need a thick skin” is code for “our community is toxic” and should be avoided.
“Releasing code is scary, admitting that you are wrong is scary, and accepting code that you don’t like is scary,” Fenwick said. It is also “easy to be over-controlling,” which is “terrible for contributors.” Fenwick has a rule: “Is it better than it was before? Including technical debt?” A pretty good solution, for now, should be accepted. This rule makes people feel appreciated, which has resulted in more contributors.
Initially, Fenwick didn’t realize that leadership would be such a big deal, but that turned out to be the case. He became the leader by default, and when there were some major policy issues around licensing that were causing huge issues for the project, it was very stressful. This was his “biggest stress over the past year,” and as a result, he ended up with a lot of burnout, which meant that he was spending less time on the project. Eventually, he made the difficult decision to step down, but he says that his mental health is better after handing it over.
Fenwick ended with, “Don’t beat yourself up. You’ll make mistakes. You’ll need a break. It’s OK. Look after yourself.”
Feature image: Katrina Owen at OSCON. Photo by Dawn Foster.
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.