Opinionated summary of the Burnout in Open Source Software Communities Report
Originally posted on forum.fossunited.org
This is an opinionated summary of the report on Burnout in Open Source Software Communities by Miranda Heath. Read the full report here and Miranda's guest blog post on the Open Source Pledge blog here. The report is sponsored by Sentry.
Summary
The report is based on interviews with various FOSS maintainers, academic literature review and an analysis of 50+ pieces written by FOSS maintainers.
What is burnout
The author mentions three key components that lead to burnout, which is basically an exhaustion of physical and mental energy. I've mapped them to some examples I could think of from a FOSS project's lens.
- Motivational - an intolerance of effort. // Continuous inflow of issues/PRs/bug reports?
- Affective component - feeling emotionally drained and a reduced ability to regulate emotions // Toxic forum discussions?
- Cognitive component - a change in how one thinks about work // Maintainers stepping down from projects
The risk of burnout is thought to increase with job demandingness and decrease with job resources
Method
- Rapid literature review - Analysis of articles on burnout in OSS/software
- Rapid thematic analysis - Analysis of non-research articles (blogs by maintainers etc.)
- Community consultation - Interviews with maintainers
Evidence of burnout in OSS
a 2023 comprehensive survey of 26,348 developers around the world working across both closed and open source found that 73% had experienced burnout at some point in their career
2024 survey of over 400 open source maintainers found that 60% had considered leaving open source
See relevant discussion on the 2024 Tidelift report here
In my analysis of OSS community discussion, it was clear that OSS developers were experiencing the three components of burnout
OSS developers showed a change in affect, describing a shift from love for the OSS community to anger and ruder and more perfunctory responses to OSS users and contributors. Feelings of guilt, low self-worth and depressed mood were also cited.
It also appeared that burnout was causing real harm, impacting developers’ physical and mental health.
Causes of Burnout in OSS
The author identified 6 factors that play a role in burnout -
- Difficulty getting paid
- Workload and time commitment
- Maintenance work as unrewarding
- Toxic community behaviour
- Hyper-responsibility
- Pressure to prove oneself
I broadly agree with the list (except 6?) and I would also rank these factors in the same order - not sure if the author intended that.
Difficulty getting paid
I've only broadly skimmed through the "Open Source maintainers don't get paid" part since we have had discussions around this multiple times in this forum and outside - with no possible solution in sight. The author has come to two conclusions as to why maintainers don't get paid -
- Identity, community norms and values motivate participation in OSS. Introducing payment for OSS might be seen as a move away from the original values of open source. These values can be an important part of developers’ identity and sense of belonging, making it harder for them to talk publicly about payment.
As open source becomes more and more prominent (which it will), our reliance on FOSS will only increase. I think things are much better than a few years ago, when asking for money used to be seen as taboo. We (both FOSS creators and users) still need a fundamental shift in our worldviews because these "values" only cause more harm to the ecosystem. The usual responses like "nobody asked them to make a FOSS project", "you signed up for this" etc. are unkind. Open Source (or Free Software, FOSS, FLOSS or anything for that matter) means that the code is open and not much beyond that. We need to understand that the software is free, but maintenance is not.
Open Source Maintenance Fee is trying to create some discourse around these lines. Chad Whitacre's perspective on OSS being a gift economy is also relevant here.
- Developers that do manage to get sufficient and reliable payment for OSS work often feel privileged and like they ought not to complain, which can make it uncomfortable for them to weigh in on the topic of payment.
That is interesting and not something I have heard from a maintainer before.
Workload and time commitment
While most projects in their initial stages may not require huge time commitments (beyond what the maintainer wants to commit), as a project starts getting traction, things can become difficult. As you get more users, entitled bug fixes/feature requests keep piling up before you have the time to rethink your priorities.
Maintainers of popular packages described being swamped with requests and emails from users for support, bug-fixes, updates and features. This was compounded by the fact that many were the sole maintainer on a project, and found it difficult to attract new contributors capable of high quality work. Moreover, reviewing poor quality contributions was described as taking a great deal of time and effort. ‘Email overload’ has been singled out specifically in the academic literature for its role in burnout.
An interesting point here is that while doing outreach for floss.fund, it usually takes me anywhere between 3 days to a few weeks to get a response on email, if at all. Doing the same via Github issues gives me almost immediate responses (even at odd hours). That just shows how swamped maintainers' emails are (or that they spend most of their time on the project's repositories itself!)
Maintenance work as unrewarding
Academic research has shown that software engineers are highly intrinsically motivated (Rubin and Hernandez, 1988), and a love of the creative process of coding was clearly apparent in OSS community discussion.
However, OSS developers noted that software maintenance is a very different kind of work to building software, requiring less creative coding, more repetition and drudgery, and more communication and people management skills—skills not all OSS developers possess or enjoy exercising.
Work that is not intrinsically motivating needs to be extrinsically rewarded; when there is an imbalance, such that the magnitude of effort put in is far greater than the reward received, the risk of burnout increase.
This is an important point for "FOSS funders" to keep in mind while creating reward mechanisms. Is your program geared towards factors which are actually of interest to the maintainers? Most of these programs are in fact overall net-positives for the project, but my point is that they may not do much to drive sustainability.
Another extreme end to this is how most Open Source Foundations function today. I have interacted with many maintainers who've told me their project is governed by a foundation that manages and governs their funding. Even if said organisations have a good balance in the bank, they only use it towards maintenance work (bug fixes) and public engagements (conferences etc.). A very small portion actually goes towards directly paying maintainers or feature additions.
Toxic Community Behaviour
Some relevant thoughts here
Hyper-responsibility
While intrinsically motivating work is generally associated with a decreased risk of burnout, it is more likely to lead to burnout under conditions of high stress, since when one really cares to get the job done well, one might willfully miss signals that they are overstretched and need to slow down
https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good ? :wink:
‘My open source success went from a major blessing to a great curse. It was one of the darkest times in my life. Something that started out with such hope and light ended up just being about getting thousands of emails. People told me their whole life stories and how it’s all been leading up to this one feature they really need me to add.’—Grabanski, 2019
I’m the only person holding this together, if I leave who will do this?’—Rogers, 2017
Pressure to prove oneself
I have not thought about burnout from this lens so this section was very interesting.
They also felt pressure to show their worth both as a developer and to the OSS community through their contributions. Some called out GitHub for playing a role in this with features like achievements and badges that were taken to gamify contributions.
‘It’s all in the numbers — followers, contributions, comments, stars.’—Szczur, 2015
‘it becomes your identity, you rub shoulders with really influential people in the in- dustry, and I don’t want to get kicked out of the github organisation so I gotta keep going—that’s how bad it gets … one day I was like, ‘I can’t do this anymore’— Stacoviak and Santo, 2018
Recommendations
There is an upside to the causes of burnout in OSS being inter-related and mutually reinforcing: addressing burnout on one front could go some way towards addressing it on others, leading to improvements that cascade throughout the system.
Pay OSS developers
with emphasis on
Routine, reliable payment for OSS work
It is well known that most projects prefer regular donations compared to large one time payouts.
It is important to note that some developers fear the wrong model of payment could create pressure to act in the best interests of funders, rather their own interests or the interests of the community. This could in fact make burnout worse–research suggests software developers are at greater risk of burnout when they lack autonomy over their work.
This could be achieved through a decentralised funding model, in which projects are not reliant on a single source of industry funding for survival. Collective governance may also have a role to play by ensuring everyone involved project has a say in its direction.
It is also important that payment be predictable and regular; it is hard to plan effectively plan one’s life and time around sporadic tips and donations. It is for this reason that some of the developers I spoke to favoured salaried jobs with time set aside specifically for open source, or some version of a universal basic income.
Foster a culture of recognition and respect
Institutions like GitHub are well-positioned to educate users about the nature of open source, and their Maintainer Month initiative shows they are willing to engage in this kind of work.
On that note, check out forklore and FOSS United Maintainer Programs :)
Several OSS community members suggested GitHub could also introduce features that help manage user expectations, for example, by highlighting when a project is maintained by one person in their free time.
Companies and foundations wishing to give thanks to OSS developers could facilitate access to coaching, mental health support, and training resources that enable developers to feel socially supported and equipped to deal with conflict with users and within developer teams.
Advocate for developers
This section mentions some excellent recommendations for platforms like GitHub. While I've personally lost hope, I do wish platforms take this issue more seriously.
Conclusion
Burnout is not just a problem for OSS developers, it is a problem for all of us. It is also a problem that can be most effectively addressed by working collaboratively to achieve system-wide change.