Anyway, as we get to the end of the day, our next speaker is going to cover burnout in open
source, particularly burnout as a systems issue and what we can actually change.
Please welcome Miranda Heath.
Thank you so much for hearing me okay, it's the microphone, great.
Has everyone's energy, it's second to last talk, it's really warm in here, give me a shout.
It's okay, it was okay, I would ask if this sounds familiar to anyone.
My open source success went from a major blessing to a great curse, it was one of the darkest
times of my life, something that started out with hope and such light ended up being
about just getting thousands of emails.
So these words, the words of Mark Grabansky, a friend, ten masters, speak to the issue of burnout
in open source software, I'm Miranda Heath, I study the psychology and the philosophy about
tourism, if I'm not a programmer, and I've been researching what's been causing open
source developer to burn out.
So what this psychology tells us about burnout, burnout is a work related to the exhaustion
of both our physical and our mental energy, and it affects us in three different ways.
It affects firstly our motivation, so if we're fatigued, we can't force ourselves to exert
effort, our work becomes lower quality and it's a really big predictor of quitting.
It affects our cognition, so it affects our thought processes.
We might start thinking about things in a more cynical or a negative way, it affects
our self-worth and our self-esteem.
We can become obsessive over issues at work and unable to drop them.
We can also feel like we've lost that sense of direction, both in work, and our sense
of meaning and what we're doing in our life generally, and we might also indulge in
dark humor and escapism, and in the worst cases this can even need to behave like addiction.
And finally, it affects our emotions, so burnout makes us feel drained emotionally.
It also makes it harder for us to regulate our own emotions, so we might be quick to overreact
or to anger or to panic, and it makes it harder to do with emotions in other people as well.
We have like compassion for tea, and these two factors can make it hard to, you can affect
your relationships outside of work and inside work as well, so it can affect your life
in a broader way.
We also might feel guilty or experienced depression.
In fact, mental and physical health really suffer with burnout.
So if you're wondering why we should care about burnout in open source, you can see that
it's putting developers at risk of real harm, and it's an ethical issue.
Now, there are some things that drain our energy, so things like having a high workload,
really complicated work, and also a lot of responsibility, having unclear expectations,
what our role is supposed to be, conflict with our colleagues, or feeling like we're being
treated unfairly at work, and some of these you might recognize from working in open source.
And there is something that's a thinner energy, so things like having good social support,
having opportunity to use to grow and develop and learn new things, fair pay, or autonomy,
so having freedom and control over what you're working on and how, having joy and meaning
in the work you do and feeling competent at it.
Now, burnout is caused by an imbalance in the things that drain us and the things that sustain us,
so it is also an issue of fairness and injustice.
Now, burnout in open source is also a significant problem, so 73% of software developers
in open and closed source worldwide have experienced burnout at some point in their career.
In fact, they wonder how many people in the room put your hand up if you feel like you've experienced
burnout or working in open source, oh my goodness, that's worse than I thought, that's more than 72%.
60% of over 400 open source developers considered quitting open source in 2024,
and they've been at least four globally significant security incidents where burnout has played a role,
so burnout in open source is also an issue of sustainability, the dreaded word, and security.
Now, I wanted to better understand what it is about open source in particular that's putting people at risk of burnout,
and I wanted to understand this in developers' own words.
So I analyzed more than 50 articles, blogbows, podcasts, videos, and online discussions on burnout
by people working in and around open source software. You'll hear their quotes throughout if talk.
I also spoke to eight developers. I start feedback from the community, and then I wrote it all together
into a report on the causes and possible solutions to burnout in open source software.
So what are these causes? What is it about working in open source and makes it dream more than
it sustains? Well firstly, it's difficult to get paid, so many developers felt it's unrealistic
to expect sufficient and reliable payment for the work that they do. This is also backed up by the numbers,
so according to research by the sovereign tech agency and by tide lift, about 60% of open source
developers don't receive any payment at all for that open source, and a further 16% of them are paid,
but it's not enough for them to earn a living. Now, if we feel like we're being treated unfairly,
then this is likely to lead to burnout, and developers feel like that they're being unfairly exploited,
that they're being pressured into free labor for an industry that could actually afford to pay them.
In the words of David Alma Kiever, we've concluded that we'd much rather make people work for free
in their spare time to produce adequate software, and then shame them into supporting it,
then fairly compensate them for their labor and get good software out of it.
Another thing that makes open source training is the workload and the time that it takes
to high workload zero, so associated with burnout, and developers describe open source work as
kind of like a stealth shift, so because it starts out as a hobby, you might not recognize it,
it's also so work, but a labor of love is a labor nonetheless, especially once it becomes more
popular and there's more work to be done, and because it's hard to get paid, many developers also
have full-time jobs alongside their open source, effectively doing this double shift and incredibly
long hours in order to be able to make a living while doing their open source work.
In the words of Jacob Kaplan Moss, I wasn't getting paid to do the work I felt like I had to do,
and I had to do the work that I was getting paid to do because of mortgages and builders and car payments.
On top of that, developers are increasingly overloaded with issues and requests and bug reports,
and this is often a problem when they're particularly low effort, because low effort reports mean
that it takes a higher effort in order to review them, and this needs developers feeling like their
time is worth less than other people's, and remember this feeling of unfairness is also associated with burnout.
It's is also seen to be getting worse with the rise of AI coding, as AI lowers the effort required
to make the poor request, leading to a greater volume of requests and of a worse quality than if they're
written by a human who understands the code base. In more time we spend working, the last time we have
our friends, our family, for relationships, for interests outside of work, and the psychology
literature tells us that both loneliness and having work as the only meaningful thing in your life
is likely to lead to burnout. Developers are being left, making really painful, existential choices,
as an older loss and puts it, I just can't see how I'll be able to make the time for both
raising a family and doing open source. Another cause of burnout, all of that maintenance work
that developers are doing isn't always rewarding to do. So in psychology we tend to distinguish
between two types of reward, intrinsic reward, which are things that we do for their unsafe,
for the joy of it, and then extrinsic reward, which are things we do for some external good,
like money recognition and job prospects. As we've seen, maintenance is not sufficiently
extrinsically rewarded, for developers are rarely paid, they're rarely recognized or thanked for
doing maintenance in a market society that favors extraction rather than sustaining things.
And developers don't always find maintenance intrinsically rewarding either. So doing triars,
code review, managing people's expectations is not the kind of creative expression or intellectual
challenge that got a lot of us involved in coding in the first place. And this is also being
exacerbated by the rise of AI coding, because in some cases it feels like we have intentionless
machines doing the creative part of writing code, and then people end up doing the machine
like work of looking for hard to spot errors in this deceptively competent looking code.
And if you want work to be intrinsically motivating, this is totally the wrong way around.
I'm pushing ourselves to do work with neither extrinsically nor intrinsically rewarding,
it drains our energy and puts it at risk of burnout. And T. Red sums this up well.
I would rather be remembered as a bad artist than a good programmer,
but now I'm asked more and more to express myself less and to maintain the project more.
Now a big cause of burnout that came up in the research I was doing was that the community
can be toxic. I don't know what the overlap is between open source developers and
Brittany fans, but there she is. I talked about social pressure earlier,
the people act entitled to developers' time, and they demand their help for features and
for fixes, and sometimes resort to anger or insults or shaming when their needs aren't there.
Even if it's for a really specific use case, it's not generally helpful.
And developers also experience rudeness from other collaborators, or sometimes described
becoming rude themselves. And remember when we're burnt out, our emotion regulations were,
so we feel worthless, we have low self esteem, so it's easier to lash out if we stretch
them and try to defend the very last bit of our ego. And the fact that a lot of this toxic behavior
happens in public is particularly bad for burnout. It can make us feel powerless or humiliated or
feeding to those feelings of guilt and inadequacy, which makes it a lot worse. All of this makes
it very hard to want to carry on doing maintenance work. As Jamie Kyle puts it, every single day
and reading someone else rant about how awful of a job we're doing. It's been hard to stay motivated.
I've practically stopped looking at issues and at poor requests. Now community toxicity can
lead to what I've delicately called the burnout death spiral. So in communities of toxic,
maintainers will light a burnout that's harder to regulate their emotions and are more likely
to get into conflict. And technologies with toxic communities are seen as riskier investments,
which might mean that businesses and governments are less likely to want to get involved in
investing and open-source, which makes it harder to get paid. And then issues where people
are rude to each other have been shown to take longer to solve and rudeness in a community
to deter as newcomers from getting involved, all of which contributes to having a greater workload.
And the more conflict there is, the harder it is to get paid, the greater the workload,
the more likely we are to burn out. And then the more likely we are to engage in toxic behavior
and further spiral goings on and on. And finally, developers are carrying a tremendous amount
of responsibility. So the majority work either alone or in small teams. This is research from
the sovereign tech agency. And many of them also feel irreplaceable. So I feel like if I stop doing this
so I don't keep doing it who will. And when we have too much responsibility and when we feel like
we can't be replaced, we're less likely to recognize the meaning to slow down and we're much more
likely to burn out. There are three sources of responsibility in particular that we're weighing
on developers. So firstly, responsibility towards the project, the people, the factors that depend
on it. So caring about it, that it's being good quality, it can use to be usable, it continues
to exist at all. And then there is responsibility towards other collaborators on the project
to employ youths. And then responsibility towards the open-source community into uphold open-source
values. And this can come into conflict. Let me illustrate this with an example. So who's been
following what happened at Tailwind, CSS, can you note? People. So in what I thought was a really
admirably candid recording, the creator Adam Weithen described how revenues were down. So he
had to lay off 70% of his staff. He explained how he wasn't going to implement a request that would
make documentation easier for LLM's to read because the documentation helps Tailwind sell premium
features, which would help keep the revenue streams up. And then in response to this post,
some people got angry with him and said he was betraying open source values or just being in it
for the money. Now this was a lose-new situation. It's not possible to juggle these competing
responsibilities. Yet this podcast culminates in and saying that he feels personally like a failure
and like a fucking idiot for making something so popular, but not being able to figure out how to
make enough money to keep people working on it. And it's made me think of this art installation.
I thought about not putting this in because it makes me want to cry every time. So it's a robot
that slowly leaks this blood-like hydraulic fluid and it's programmed when too much of it leaks
out to stop and scoop it back in. And at first it can stay on top of this scooping and it uses
its downtime to do a little happy on waving dances. But the more that it leaks out, the more time
it's then scooping, the less time it spends doing it's happy dancing until eventually it's
all blood out and switched off completely. And I can really see parallels between this and some of
the developers that I've researched descriptions of what it can feel like working in open source software.
So congratulations, we made it to the low point of my talk.
So now I'm going to try and let a little bit of light locked in with them in.
So the open source community excels at recognizing the importance of collaboration that the value
of your work can't be attributed to you and you alone and that we can do better things if we
work together out in the open. But it's not so good at applying this same logic to burnout.
So individuals are being left to meet these impossible sacrifices to keep working in open source.
And individuals are left trying to cope with conditions that according to psychology really create
the perfect storm for burnout. The burnout already affects our self-worth. And if the only fix is
available to burnout are individual fixes, then the risk that people will like Adam feel like they
failed personally when things fall apart. And I don't know about you, but I don't feel like that's
an individual burden for us to bear. So in order to solve burnout for good, we need system level fixes
and system level fixes require us to do what open source does best and to collaborate. So before
we wrap up, I'm going to argue for three such system fixes and I'm going to argue against
the position that we should keep treating burnout as an individual issue only and then highlight
some things that are important to consider from the perspective of psychology if you're someone
who's working on implementing them. So firstly, we made it a bit taboo to talk about money in the
room. I'm going to say that we need to make it easier to get paid. So the fact that developers aren't
getting paid is making everything else worse. It's making the workload greater. It's making
maintenance less rewarding, extrinsically, and it's leaving individuals juggling impossible competing
responsibilities. I've heard people say it is a conference that open source isn't about money,
it's about people, but I don't think there's a dichotomy here. I think that if we're leaving
people struggling to cope, to make a living just because they've decided to work to maintain
the comments and that's not respecting the people of open source. Now if we approach burnout as an
individual issue, it might be tempting to say, well, didn't you sign up for this when you made
your code open source? Why do you feel like you're being treated unfairly? But I don't think this
is true. I think the psychology tells us that social behavior is organized by group norms, which
are kind of like unwritten rules for the group. There's a norm in the open source community that
yes, we give away code for free, but in return, we expect the community to collaborate and then
everyone shares in the benefits and we produce something good. So it starts with developers
sharing code with other developers, but then when your open source becomes more popular,
more people outside the group come to depend on it, and this also creates more work, and these
people who are further from the middle of the group don't always abide by those group norms,
and these aren't the terms that a lot of developers signed up for when they made the code available
open source. Plus, while making money is a taboo topic in open source, I think leaving the
videos on their own figure out how to make a living while doing open source is arguably putting
open source values at greater risk. So individual developers don't have much power to make a living
out of their open source beyond restricting access to participate or making free immune features,
which limits the possibilities for open collaboration. If we work together, we don't need to
sacrifice those open source values, so together we have the influence to encourage, for example,
companies that rely on open source to subscribe to those group norms and to give something back
to maintain it. Now I did this research long with centuries open source pledged team, and I think
this is a great example of trying to get companies to give something back to the community,
so companies can become members if they pledge at least £2,000, sorry, $2,000 per year,
put a developer at the company, and this aligns with what psychological research tells us about
the organizing power of group norms, so encouraging companies to make their commitment to open
source norms public makes them accountable to the group, so they're more likely to stick to them,
and in turn these companies have then recognized and celebrated by the community for the
part of playing in it, and they've raised over $3 million to maintainers in the last year alone,
in fact they have to keep updating this slide because I look on the website and it's snuck up
since last time. Secondly, we need to share the responsibility that's associated with open source
software, so I think it might be tempting to apply this individual fix of learning to say no
to taking on more responsibility than you can cope with, and this is really important, we should
know how to draw boundaries, there are some things that were pressured to doing that we should feel
no qualms about saying no to, but I think we also need more people who are willing and able to
share in the responsibilities that can't be avoided, so we need to be able to grow the maintenance
community, so we sometimes talk about this in terms of the bus factor, I don't know if anyone
if there's overlap between the Mean Girls fan community and I'm just a developers, but there it is.
I have a word of caution about the bus factor, which we used to talk about how to increase the
number of people working on a project so that it's less likely to fail if someone played the
methodically and gets hit by a bus. The bus factor treats developers as if they're interchangeable,
which misses out an important qualitative information about those individuals and about team dynamics,
so the team might have many people who have the skills to step up, but one person still ends
up doing all of the work because they're the expert that the senior is the path of least resistance
to leave it to them, or they might have difficulty trusting junior people to step up, and these
individuals are at risk of burnout. So what's the solution? We've talked a lot in this room today
in a really good way about mentoring relationships, so these help collaborators build the confidence
that they need to contribute and help senior developers build the trust that they need to pass on the
reins. And secondly, larger projects could benefit from governance than the next everyone's roles
and responsibilities clear, so unclear expectations lead to a diffusion of responsibility and they
are themselves associated with burnout. But this is also something of a balancing act. We don't want
roles and responsibilities to be too rigid either because you remember that autonomy, so freedom and
control over how we work protects us against burnout. So here's a really useful thing from the
psychology literature to bear in mind. When work has hardly any autonomy and lots of responsibility,
or it has lots of autonomy and vital responsibilities, so the pink danger zones in this graph here,
then there's a risk of burnout. Open source maintenance just is a big responsibility, so we need to
balance it out by making sure we preserve autonomy. We want to be here. So if you're working on
models of governance or if you're working on different models for funding, then it's important
to make sure the model you're working on doesn't prevent developers from having freedom and
control over how they work. I think this is a risk if you have a model that's like a BDFL or
if you're too reliant on one source of funding so they have power over the direction of the project.
And finally, I'm getting close to any out of time, we need a kind of community dynamic,
and I think this will get better, the more better paid and the less overwork developers are
remembering the burnout spiral. However, I think they're still an underlying culture and open source
that's permissive or rudeness in public under the guise of Frank and Open Dialogue.
If we take an individual approach to this problem, we might say, well, you need to develop
thick skin in order to work in open source, you need to be resilient. And I think this is important,
but also it's somewhat fatalistic because it's asking us to adapt rather than believing that
changes possible. And secondly, I think this would mean asking some people to develop thicker skin
than others because groups that are already marginalized in open source are already bearing the
brunt of more of this toxic community behavior. So I don't think this way of thinking encourages
diverse participation in open source. Sorry, so I've clicked on those earlier. So a less individual
solution would be one where we build a sense of community that helps us feel solidarity with one another,
and where we respect each other rather than disrespecting each other because we've become
used to being treated with this respect. This is an easy thing to say, a harder thing to do,
but psychology tells us that there's a role that community leaders can play in this. So if you
or someone people in the community look up to, you can model the sort of behavior that you'd like to see
in open source. So you could be like Adam Wathon and be courageous and candid about your experiences,
talk about your feelings. Secondly, it's important to have kind of grassroots community spaces
where people can come together and talk about the problems in open source. So, oh dear. And
I'm going to go over by like one minute if that's okay just so I can finish up. Thanks. So this gives us a
greater opportunity to build a sense of community and build solidarity with each other rather than
fighting because we're all suffering by lack of funding and burnout. And to sum up, we should care about
burnout because it's an ethical issue and issue of fairness and justice and an issue of sustainability
and security. Open source culture is built on recognizing the value of collaboration and there are
many actions we can take the last year get to the root causes of burnout that can only be
achieved by us working together. So thinking back to that leaky robot, we need to stop leaving
individuals to try and cope as all the energy drains out of them and we need to get back to whatever
our equivalent to happy waving dancing is. So get back to that creative coding that gives us life.
I thank you so much for listening quickly before we go to the Q&A because there's a sort of
been a call to action. I've started making a list of people working on system fixes to burn out
in open source. That's the top QR code here. So please take a look. Tell me if there's anything
I could add and see if you can help any of these people out. And secondly, this was just a bit of
research I didn't my own free time alongside my PhD and I'd love to be able to expand it. So if you'd
like to talk to me about your experiences of burnout or if you'd like to collaborate with me on
similar work in the future or if you know someone who's willing to fund this kind of research,
you can come talk to me at my website at the fewa here. Thank you so much.
We might have to have for one question. Does anyone have a question from a rander?
Thank you, Miranda. It's a really important subject address. I think actually it even applies to
people who work commercially in software as well. One thing you talked about responsibility
house really important, but people are made differently and you can't turn people into what they are.
I wonder if there's a specific role in communities for if you like the salesperson,
the marketing person, just like in my company, my engineers get beaten up, they come to me
because I can put on my salesman hat and beat the customer back up again. And there are people who
look good at that and whether you need that or that's the sort of champion you need. Someone who's
not just setting a role model but is actively keeping people off other people's backs who aren't
so good at that stuff. I do think that would be incredibly useful and I don't think everyone who
is involved in maintenance has those kind of skills or finds that something that's easy to do
or that they enjoy doing. Somehow if we could bring in more people who are good at that
people management side of open stores, even if they're not so strong on the coding,
bringing in people who aren't just programmers to help out. We had a little bit of talking
about at the end of the book. I think that would be really helpful. I think that's what I
meant by like being careful not to treat programmers as interchangeable, like we will have the same
kind of skills set or find the same things motivating, such as isn't true. Thank you, Miranda.