Maintainer Burnout is a Problem. So, What Are We Going to Do About It?

author-image

By

If you’ve ever served as a maintainer for an open source project, you know the struggle is real. Maintainers work tirelessly behind the scenes, facing immense pressure to keep projects afloat and secure, address issues, and push through the challenges that come with prolonged dedication to a project—often with little to no pay or support. The emotional toll, coupled with the burden of responsibility, can lead to burnout, creating significant implications both for the maintainers themselves and the projects they oversee. In Intel’s annual open source community survey, the majority of survey respondents (45%) cited maintainer burnout as their top challenge. 

Stories from the Community

At the Open Source Summit in Seattle, we asked community leaders to share their experiences with maintainer burnout in an attempt to shed light on the issues they’re facing and start a conversation on how to better support maintainers. Everyone we spoke with emphasized the need for better tooling, additional support, and a shift toward respecting and uplifting the unsung heroes of open source. 

That Lone Developer in Nebraska

Craig McLuckie, co-founder and CEO of Stacklok, emphasized the criticality of open source projects as a contributing factor to the constant pressure applied to maintainers and their communities—something he understands well as a co-founder of Kubernetes. He suggested that threats to open source represent a “substantial and existential threat to the way that we consume technology.” McLuckie encouraged reaching out to people who are under undue strain to get them proper tooling and support. 
 

"First of all, we need to develop a way to recognize and respect and ultimately support individuals that are under strain,” said McLuckie. “We need to find that lone developer in Nebraska and bring them the support that they need. And that doesn't mean just paying them money; it means bringing them the things they're really asking for — better tooling and additional individuals that might participate and carry some of the load for them.” 

Start with Empathy

Matt Butcher, co-founder and CEO of Fermyon, recounted the challenges he faced working on the Helm project, where collective burnout prompted a shift toward team support and balanced workloads. He described how the project evolved from the energized startup phase to the stress of being in production at other people’s companies. 
 

 “I think at one point a bunch of us just started to feel the drag effect of that and it had gotten to the point where, for a little while, it wasn't so much that we weren't motivated to work on new features,” said Butcher, “It was really like, how do we just keep the lights on right now and feel OK? Getting over emotions like that can be a hard thing to do.” 
 

Butcher said acknowledging emotions, rotating team members to prevent overload, and fostering a sense of community helped them combat burnout. He also emphasized the importance of detecting burnout early on, fostering open discussions about mental health, and building a diverse contributor base to share the work and bring fresh perspectives to projects. 
 

"And then the other thing we did that actually was a small thing, but made a huge difference...,” said Butcher, “we sat down and we said, ‘we're going to write up how to handle an issue where we're going to say, when a new PR comes in or a new issue comes in, here's a pattern we're all going to follow.’” Butcher added that the team always started from a place of empathy by acknowledging the user’s emotions when they submitted an issue or pull request. 
 

“The first line of the PR review would always be, ‘thank you so much for contributing this’ and start by acknowledging and being gracious about it,” said Butcher. “And then you could go into the PR and say, ‘you know, we can't accept it while this part is looking this way.’ But what it did for the people on the other side, is it deescalated their emotions, which then in turn meant we had less to absorb.” 
 

Butcher and his team established processes rooted in empathy and enabled team members to talk openly about their feelings, which helped them identify when people needed a break — before they reached burnout.  

Maintainer Burnout is a Security Threat

Burnout is not just bad for a team’s mental and physical health, it’s also a security risk. “We had some issues recently with open source projects where, it's like, if your maintainers are burned out, they can't be protecting the code base like they're going to need to be,” said Google Developer Advocate and Kubernetes contributor Kaslin Fields. “It's one of the major risk factors, honestly, with using open source that the maintainers will be burned out and not be able to accept new feature requests that you need.” 
 

Fields highlighted the value of teamwork and implementing processes that distribute workload effectively to stave off burnout. “I think an important tactic that we can employ ourselves is to build teams and put processes in place where we're working together and we have those kind of checks and balances where we can keep each other from taking on too much,” added Fields. “Beyond that, of course, there's a lot of conversations going on about how we pay open source contributors, how we convince companies to pay more open source contributors, and that's an important part of it too.” 
 

Frederick Kautz, director of research and development at TestifySec and co-creator of open source projects such as GitBom and NSM, believes that taking care of developer health is a key factor in ensuring software security. “We need to make sure that the people who are doing the work have sustainable lifestyles, that they’re able to be happy with what they're working on,” he said. “And if they're not, then how can we set up the environment so that they can get help if they need it?” 
 

In addition to increasing financial support from companies, Kautz added that it’s also important for people in the community to look after one another. “If I see that a colleague or a friend of mine in the open source community is starting to burn out, even just going in and talking with them, saying, 'hey, are things OK?’ or, ‘how are you feeling?’ Even if there's nothing that you could actually do, even just that conversation can get that person to start thinking about their health and maybe start to enable change in those areas.” 
 

Adolfo García Veytia, a staff software engineer at Stacklok and creator of open source projects including OpenVEX and Protobom, shared insights into the challenges maintainers face when balancing critical security work, like promptly responding to CVEs (Common Vulnerabilities and Exposures), with the demands of life, underscoring the pressure and stress that can lead to burnout. 
 

“For example, when a CVE hits your project, you need to respond quickly because you know you have potentially thousands of users that could be affected,” he said.  
 

But building more security into your project takes extra work, which also adds to the stress that can lead to burnout. “It's work that’s not necessarily related to features; it's not necessarily related to your usual bug fixes; it's additional work that you have to take on,” Veytia lamented. 

Moving Forward Together

After talking to maintainers and contributors about the daily stresses that lead to burnout, one thing’s clear—any solution will require a multi-faceted approach with support from corporations as well as community members. There’s no one-size-fits-all solution, but rather a culture shift that needs to occur emphasizing both financial and emotional support and recognition for the people making the software that literally powers the world.   
 

Join us to advance this critical conversation and drive positive change in the open source ecosystem. Follow us on LinkedIn, and X, engage in the dialogue, and let's work together on a future where maintainers thrive, and open source continues to flourish. 

Watch the Full Video
 

About the Author

Katherine Druckman, Open Source Security Evangelist, Intel 

Katherine Druckman, an Intel open source evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she’s a longtime champion of open source and open standards.