Latest PostLatest: Burnout in Open Source: A Structural Problem We Can Fix Together

Burnout in Open Source: A Structural Problem We Can Fix Together

Miranda Heath
A title saying “Burnout in Open Source: A Structural Problem We Can Fix Together” next to the hand of a person buried under a pile of bug reports and pull requests reaches out, trying to escape from the pile

Imagine this: you build something to address a need that you have. It works — and it works well! Realising it might be useful to others, you decide to share it as Open Source.

To your surprise, it quickly becomes popular. Your work is valuable to others. It feels like a dream!

Then the requests for features and fixes come pouring in. Some feel more like demands. You care deeply about what you have made, so you try your best to respond.

You do this in your free time, but it starts to feel like a second job. Your working days get longer and longer — some nights you barely sleep. You know your work is valuable; massive companies are using it under the hood! It’s a rare day when anyone stops to say thanks for the hours you put in — but for them to offer any sort of financial support? Almost never.

A pull request comes in. Someone earnestly trying to help? Nope — it’s clearly something they threw AI at without understanding the code.

It carries on like this for months. The project you made for you, once a source of joy, is now a source of stress and anxiety. You feel profoundly unseen. Reluctantly, you begin to wonder: is it time to give up on the dream?


I’m a psychologist, and I’ve been compiling a report on the problem of burnout in Open Source Software (OSS).

Over the past 5 months I have interviewed OSS developers, read dozens of academic articles, and analysed 50 pieces written by members of the OSS community to try to identify the causes, and possible solutions, to OSS developer burnout.

I have been struck to learn how much the software infrastructure we rely on every day is made possible by developers choosing to make their projects available Open Source, with over 96% of all companies depending on Open Source software. Even more striking, I discovered that choosing to make and maintain software as Open Source is putting developers at risk of the very real psychological harm of burnout.

Burnout is an exhaustion of physical and mental energy, typically associated with work. Burnout leaves us feeling drained, that we have no fuel left in the tank, that we are running on fumes. When we are burnt out, it is hard to motivate ourselves, to control our emotions, or to think positively about our work.

It is a huge predictor of quitting.

The risk of burnout increases when there is an imbalance between the energy our work demands of us, and the resources available to replenish it. For example, if we are expected to work long hours under higher pressure, yet the work is unrewarding, we aren’t supported by our colleagues, and we are not fairly paid or recognised for our efforts, there is a good chance we will end up burning out.

Unfortunately, conditions such as these are common in OSS, 73% of software developers around the world experience burnout at some point in their careers, and more and more (and more!) often, conversations about Open Source sustainability are turning to the topic of burnout.

The consequences of developer burnout are system-wide. When the team — or, shockingly often, single person — maintaining a project is running on fumes, exploits get missed and malicious collaborators go undetected, putting the security of a frightening proportion of our global software infrastructure at risk.

Clearly, burnout in OSS is a critical issue in need of an urgent solution. I want to tell you about two issues my research has identified that are pushing developers to the brink:

  1. Developers are struggling to make a living
  2. Toxic behavior from community members is wearing developers down.

Dissecting these issues, we will see that burnout in Open Source is not an individual problem — it’s a structural one. Hotfixes like teaching maintainers to be more resilient can only get us so far: it may be time for a substantial rewrite of some of our Open Source practices.

1. Developers are struggling to make a living

A hand reaching out for dollar bills which are getting swept away by the wind

Very few developers are able to sustain themselves financially through OSS alone, and many feel despondent about the very possibility of reliable payment for OSS.

A common theme in OSS community discussion was that of the ‘double-shift’. Many developers have full-time jobs outside of OSS in order to pay the bills. While OSS might start out as a hobby, once a project takes off, maintaining it takes multiple hours of work each day. Doing both a full-time paid job and a second ‘stealth job’ in OSS, developers face intense workloads, long hours, little sleep, and difficulty finding time for friends and family. This is unsustainable, and erodes their physical and mental health.

To add insult to injury, OSS developers often feel exploited by the beneficiaries of their work. Their code and the effort they put in to maintain it enables the software industry to be enormously profitable, and yet it is an uphill struggle to receive anything in return, leaving many feeling they are doing ‘free labour’ for software companies that have the resources to pay them and a market that is failing to recognise their contributions.

Psychological research shows that high demand, low reward and feelings of unfairness in work are all associated with an increased risk of burnout, and many OSS developer testimonials highlighted the amount of time and effort they were putting into their OSS, only to receive little-to-nothing in recognition of their efforts, as instrumental in causing their burnout.

There was a long time where I was doing Open Source almost more time than my full time job, and getting paid nothing. I just burnt out. I stopped writing and contributing to Open Source.’ – Marc Grabanski, Open Collective Case Studies

If it were easier for OSS developers to get regular, reliable and sufficient compensation for their OSS work, they wouldn’t need to rely on additional full-time employment to pay their way while contributing to OSS. They would be less likely to feel like they are being treated unfairly by the people that benefit from their labour. They would have more time to do the things that replenish our energy: full nights of sleep, full days with the people we love. This would greatly reduce the risk of burnout.

However, while payment for OSS is an important part of the solution to the problem of OSS developer burnout, working out how best to implement it in practice is a real challenge.

Some developers fear the wrong model of payment could pressure them to act in the best interests of their funders, rather than their own interests or the interests of the community. This could in fact make burnout in OSS worse; psychological research suggests the risk of burnout is higher when we lack autonomy at work.

This fear is also not unfounded: the recent Ruby Gems takeover fiasco highlights how the pressure to appease sources of funding can change the direction of an Open Source project, resulting in maintainers losing control over a project they stewarded for many years.

It will take hard work and productive community discussion to figure out the details. Perhaps we need decentralised funding, such that no project is reliant on a single source of income. Maybe funded OSS projects need collective governance, to protect maintainers from the whims of the fabled BDFL. Whatever precise shape it takes, the model of payment for OSS that is most protective against burnout will be one that allows maintainers to make a living while maintaining creative control over their work.

2. Toxic behavior from community members is wearing developers down

The hand of a person buried under a pile of bug reports and pull requests reaches out, trying to escape from the pile

It is more than just a lack of financial compensation that is making OSS developers feel exploited. In both the academic literature and OSS developer testimonials, one issue kept coming up time and time again; a vocal part of the userbase can be entitled, insulting, and downright toxic.

Psychological research tells us that hostile communication and pressure to be polite to antagonistic people increase the risk of burnout, and developers are struggling in the face of intense criticism and unreasonable demands for features and fixes.

It is not straightforward for developers to say no to unreasonable requests either. Open Source developers are strikingly conscientious. Many feel responsible towards the people that depend on their project and feel guilty for leaving requests unanswered. Coding is their craft, and it takes strength to separate comments about the quality of their code from their sense of worth and identity as a craftsman.

Combine this with the fact that, once a project is popular, responding to requests and reviewing code can take hours and hours every single day, and it is easy to see why many developers feel that maintenance work can be truly thankless.

‘[T]he angry response has been overwhelming. Every single day I'm reading someone else rant about how awful of a job we're doing. It's been hard to stay motivated - James Kyle, Dear JavaScript

Normally, when we receive something for free that is beneficial to us, we react with gratitude. However, it seems as if a portion of the Open Source userbase are acting as if OSS were a service provided by a company. This is the typical model of consumption in a market economy. But Open Source has always been different. Open Source is a common resource pool — people contribute for free, and the more people contribute, the more it benefits all of us.

If it were possible to shake users out of their default mode of consumption, to realise that Open Source is a gift not a service, provided by a small team or even single maintainer in their free time, they might be less inclined to be hostile and demanding. This would make maintenance work less thankless, and less likely to lead to burnout.

Changing group attitudes is hard. A good place to start could be with GitHub, who are well-positioned to educate users about the nature of Open Source. Leaders in the OSS community could also help raise awareness; psychological research tells us community leaders are particularly effective at shaping group practices.

While it is clear that toxic communities can break maintainers down, positive communities, where our interactions with others leave us feeling supported and give us a sense of belonging, are associated with a lower risk of burnout.

One way this could be achieved is by organising community-focused events. These serve as watering holes at which the OSS community can gather, support each other, talk about their feelings and frustrations, and find paths forward together. Unfortunately, community events are currently few and far between and can be expensive to attend.

Another way this could be achieved is by increasing access to resources like mentoring relationships, coaching, mental health support and communications training, so developers feel supported and better able to cope in the face of demanding users. But it is hard to know how to implement this in Open Source: who would offer it, and who would pay for it?

Perhaps companies that rely on Open Source and recognise the need to give thanks to the OSS community could sponsor community events that aim to build social and emotional support among maintainers, or advance principles of good governance. Alternatively, they could fund, organise or offer access to coaching and training resources that enable developers to feel socially supported, while they support the software infrastructure we rely on every day.


At its core, burnout is an utter depletion of motivational energy. It is a state of exhaustion, an inability to conjure any further effort, and it is brought about when our work takes more energy from us than it gives us in return.

Developers who manage to avoid burnout find ways to give in line with what they get. They don’t spend time responding to people who don’t provide minimal reproducible examples. They put as much effort into reviewing code as the author put into writing it. They learn, through great personal strength, to say no, even though they care deeply about the quality of their work.

But there is another way to rebalance the energy equation. What if instead of leaving developers to learn to refuse or burn out trying, we give something back? A move towards a community in which OSS developers are recognised as worthy of gratitude for the hugely beneficial work that they do, in which they have social support, are treated with respect, and enabled to afford to live comfortably, is a move towards a community without OSS burnout. It is time to recognise the humans behind Open Source.


You can read my finished report in full on my website here. I am really keen to get feedback from the Open Source community to ensure I am fairly representing their views. If you work in open source and can spare some of your precious time to read the report, I would love to hear from you! You can talk to me on Bluesky @mirandaheath.website, Mastodon @mirandah@mastodon.social or drop me an email at miranda@mirandaheath.website.

Illustrations by Harriet Boeing. Additional work by Vlad-Stefan Harbuz, Greg Kumparak and Michael Selvidge.