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 !

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.

Read More:   Intel Pushes Cross-Architecture Support in oneAPI Toolkits – InApps 2022

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.

Read More:   Realm’s Mobile Development Platform Links to PostgreSQL to Tie into Enterprise Data – InApps 2022

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.

Read More:   Top 24 Game Engines for C++ Developers and Startups Love

“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.

Paul Fenwick

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

Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download

      Success. Downloading...