Subscribe to my newsletter if you enjoyed this article.
GitHub published a curious article on avoiding burnout for open source maintainers. It’s an important topic that should be discussed more widely, and I appreciate that GitHub published it.
The article has a good overview of possible burnout reasons, and gives some suggestions on how to avoid it. However, I feel that the main goal of the article is to convince maintainers to keep doing what they are doing for as long as possible, meaning to keep working for free. The article briefly mentions sponsoring but for most maintainers it’s unrealistic to rely on sponsoring or donations.
I think the most healthy solution for avoiding maintainer burnout is quitting open source entirely, at least it was a solution that worked for me. Unfortunately, I had to reach the state of burnout myself to understand that, and then it took me long time to recover (or replace maintainer burnout with a burnout in other areas of my life).
I’ve talked before on why open source was attractive to me, and a bit on why I was contributing less, and eventually quit open source.
In this article I want to talk more about the reasons that led me to maintainer burnout, and to quitting open source after about ten years of contributing regularly, and publishing many projects.
So what are the reasons?
Entitlement and toxicity of users
Somehow people expect you to solve their issues or implement features they need. They’ll complain that the bug you introduced in the last version broke their build, or that they need this obscure feature for their current project at work, and that if you don’t add it quickly, their boss will go berserk because the deadline is already on the nose.
Folks seem to miss that you’re working on these projects in your free time, after a long day at your full-time job, and without any compensation. They demand that you work on whatever is, in their opinion, broken or missing, and then they get angry when you’re not doing it or not doing it fast enough.
They miss that you might be the only person working on the project, that you’re not a part of a large team that’s paid to work full-time on maintaining the project and solving issues of its users.
Somehow, open source became a synonym of free labor, not just free code, and it’s harmful for the whole community but mostly it’s harmful for maintainers of open source projects.
And then, there are all the toxic comments (see just a few examples) that tell you that your software is garbage and you should just kill yourself quit programming, all the plus-ones (“I have the same issue”), all the pings (“any update on this?”), and other spam comments that don’t add any value…
Low quality of contributions
I often felt like managing contributions takes more time than implementing the same features myself.
The overall code quality of pull request to open source projects is usually very low, and each pull request requires a lot of time and mental effort to review, requires many comments and many iterations to bring it to somewhat an acceptable quality.
It often takes several months to merge a single pull request, many get abandoned, or their authors get frustrated and angry. Often someone submits a pull request, and never comes back to it again, so you waste time and energy reviewing their code for nothing (I call such pull requests hit and run pull requests).
People often submit features they want but it doesn’t always match the project’s vision or is outside of its intended scope. They also believe that accepting their work is free for you, not thinking that you first need to review the pull request (likely multiple times), and then maintain the feature once it’s merged (likely forever).
And the darkest time for an open source maintainer is October, when during the Hacktoberfest people around the world spam maintainers with total nonsense just to get a free t-shirt.
Lack of community
Most of my projects never got popular despite all my efforts to make them useful and to market them. If nobody is using your project, why bother fixing bugs, writing documentation, making a nice site, and so on?
My last project, Squirrelsong color theme is a good example here. I’ve invested a lot of time on making this theme, and I think it’s better and different enough than many existing themes, and yet, it seems that I’m the only user.
My most popular open source project, React Styleguidist, has over 10K stars on GitHub, and yet, I couldn’t manage to build a community around it, and to make it self-sufficient. The project is too big for one person to build it, and to manage issues and pull requests.
I had some good contributions over the years on various projects, but most of the time they require a lot of collaboration from my side. A few people were interested in maintaining some of my projects but, again, they needed a lot of guidance from my side, so it never felt like it’s saving me any time and effort.
There should be enough people actively working on a project to respond to issues, review pull requests, and work on new features, so even if some of them get hit by a bus can’t work on a project right now, it’ll continue. In reality, however, if I wasn’t doing everything, the projects would stop completely, and the issues would start to pile up.
Lack of compensation
Maintaining an open source project is a hard and demanding job, as any other job. The difference is that we usually get paid to do other jobs but not for open source. Few developers could make a living (or at least any significant money) doing open source, for the majority of us it’s nothing but frustration.
The most money I got for my open source work was for React Styleguidist via Open Collective. And it was barely enough to buy a pack of stickers once in a while. The current monthly budget of the project is $8.
I’ve tried GitHub sponsors, with zero results, apart from one-time $550 contribution from GitHub itself that was mysteriously cancelled the same day.
I have a Buy me a coffee button on every project’s readme but I don’t think I ever got a single cup from there. (I got some coffees from Unsplash though, which is also nothing for over 1,5 million downloads of my photos there.)
Lack of tooling
There are two problems with tooling that open source maintainers have to deal with.
First, the complexity of tooling involved in development of a typical open source project:
- Publishing JavaScript code (can’t speak about other languages — most of my work is JavaScript and TypeScript) in a way that it could be used by many people is very complex, and it’s getting worse.
- Dependency upgrades often take ages, and if you have multiple projects, it could turn into a year-long adventure (I even made a tool to help with that).
- Generally, the amount of configuration (TypeScript, linters, bundlers, releases, dependencies, testing, continues integration, changelog generation, and more, and more, and more…) is quickly getting out of hand.
Second, GitHub could do so much more (more than nothing) to protect its users from toxic people. For example, GitHub could:
- Detect toxic comments, and either remove them automatically, or mark them for manual review.
- Remove spam comments, and convert plus-ones to thumbs up reactions.
- Educate users posting such comments by teaching them better behaviors, or banning them if they don’t want to change.
- Make project status clear: make it clear whether a project is backed by a company or maintained by someone in their free time.
I had to ignore any activity on many projects on GitHub just to avoid people at-mentioning me all the time.
Conclusion
Something has to change to make open source healthy but for now I don’t want to be part of it. I don’t want to help corporations make millions on free code, and receive rude comments instead of any kind of recognition.
The worst part is that it’s getting worse, not better.
Now I consider my open source projects as personal projects whose code happened to be open. It’s convenient to keep code on GitHub and use npm to share code among several projects. I only add features that I need myself, and when I need them. I don’t receive notifications on any activity on these projects. I rarely look at the issues or pull requests, and I almost never respond to them.
Perhaps, I should either disable the issues entirely, or add a note explaining that they will likely be ignored and they may be more successful by forking the code. I guess, I still want projects to have a place for users to report bugs so that other users could suggest workarounds.
I’ve written about possible solution to these issues.
Subscribe to my newsletter if you enjoyed this article.
Latest comments (43)
I have been writing dozens of open source code and it's all about your point of view. |
I see it as a responsibility, the moment I release something, I am obligated to assist others and see it as bring shame upon myself if I neglect my duty.
Money doesn't matter at all, as the "payment" is psychological of "good feeling" my creations helping as many as possible.
creating open source is like volunteering your self to a greater cause.
This is how I see it.
Imagine having 10+ open source projects and having people opening issues all the time on GitHub sometimes I just want to run away and hide from all the stress this brings but I still feel shame, and shame wins so I sacrifice my time and deal with issues.
Currently I am so burnt out that I quit programming completely for months (after coding for over 20 years)
Interesting read, I saw this take from DHH a few days ago on the same topic, world.hey.com/dhh/the-open-source-...
it might be interesting for you as well.
Thanks! I agree with him that open source is a gift and that clear contract is a good thing. I don't like his shaming tone though ;-/
I'm going to be devil's advocate: You are deliberately confusing open source and free software.
Open source makes money: see Redhat, see MySQL..
Exhaustion, toxicity? AI is here for you
Lack of community? There is something in law called "contract", if it does not go against your interests and those of your clients, that it is fair, you can ask, if they want to participate. .
At some point, we will have to stop insulting everyone and moving forward, we now know who not to count
While I can't say I support your decision, I respect it. Let me clarify the first part of that statement.
I've used various pieces of Open Source Software over the years, and have been on the receiving end of decisions like yours, where something that looked like a valuable and useful tool, that I've started to use, has been abandoned. I have contributed to a few OSS projects over the years, initially GNU Emacs, and in to others in including Eclipse and K9 Mail (Android), because I feel it's the right thing to do, to try to give something back to 'the community' for the help I've had from it.
I would be much happier if my company would make real (perhaps financial, perhaps effort) contributions towards the maintenance, support and development of the OSS code we use, but getting them to is easier said than done. As a result, when I choose to use OSS for work purposes, I now tend to try to find packages with multiple contributors, or some organised commercial support infrastructure, and a certain level of maturity so that I feel the risk of abandonment is reduced.
However I still, if I'm able to, try to provide useful descriptions on issues and, if I have time and the right test infrastructure, will try to track down causes of the bug or problem I'm seeing. As others have suggested, though, especially on large projects (e.g. OpenDDS and Eclipse), I suspect the regular maintainers would make a much better job of fixing these problems than I would.
Unfortunately, I feel that OSS suffers due to the egos of some developers. I've seen time and time again that a relatively mature OSS package is forked because someone wanted something slightly different and didn't get their way (think XEmacs from decades ago, for example). It dilutes things, and makes life difficult for people who do want to try to make positive contributions to the packages they're using.
Another OSS package I'd made a start on trying to contribute to was abandoned by its main developer because he spotted another, similar, package he thought fitted better with what he wanted!
Over the years this has really put me off using OSS and, if I could find the same stuff available on a commercial basis, I'd be inclined to consider going down that route. Unfortunately, a lot of commercial offerings bundle loads of features I don't need, with an associated high price tag that's hard to persuade my management to pay, when you they know we don't need much of it. Saying that, cost-effectiveness does come into it; we looked into using RTI DDS instead of OpenDDS but the initial cost, given the circumstances of our organisation at the time, were prohibitive.
What I'd really like to see is more OSS with more restrictive licensing for commercial use, but with price structures that aren't stupid.
Just my thoughts, and I wish you all the best.
This is great!
Good job, it's a pretty perfect and detailed article about OSS maintainers!
I'm also a maintainer of many projects on Github and I have the same feelings. I don't plan to quit from it, but I spend less time on maintaining them.
🤗
Agree with most of the points yet there're always upsides that put people in the place of OS contributor/maintainer. It is just a question of the balance that is ever changing.
My pros for doing OS:
These are good points but to achieve these I don’t need to accept pull requests, look at the issues, or be a target of entitlement and toxicity.
I can feel the pain you described... Looking through someones PR, poorly formatted, buggy, without any tests or docs, solving some problem which the author of PR didn't bother to describe... At the moment I treat it as occupational hazard)
This winter I had a huge PR that was almost 1y old which I procrastinated to merge as it required a lot of mental capacity. Not because it was bad, but because it was a lot of good work done by one of the contributors, adding a nice feature. I event tried to engage ChatGPT as CoPilot to review and merge it (expecting to copy/paste sources and explaining there structure of the solution) - https://www.dropbox.com/scl/fi/d2dmxnm017swefp3nonla/ChatGPT-PR.jpeg?rlkey=qz0uqzv9gbj7j3328q641ie2a&dl=0
Some times it is the other way, contributors do decent job and invest a lot of effort. While maintainers (for many reasons, such as you described) fail to support them.
Btw, I think PR merging is a real pain and it can now be effectively solved with LLMs. Already tried doing some AI coding (see VSCode extension called cptX), now I'm thinking of creating something to solve the PR hell and publish it to GH Marketplace. We can chat separately on the subj, if you wish
Sad to hear the story. But it's actually the way it is. And I see that it's getting worse with years.
Anyway dude, I like your projects very much. I hope these stories won't fully demotivate you from being a good software craftsman. This industry needs such folks.
And I like you color themes, they look so neat and well thought-out 👍 Not my option unfortunately, my poor old eyes need more contrast for day-to-day work, but I really like the look and feel, and the support for such huge range of tools, that's rare. (The project link here is broken btw, but I'd found it on your GitHub)
And your blog is really cool, added it to my inspiration list.
All in all, chear up man, you're such an example of a dedicated professional. Don't just leave everything, save something for practice and pleasure. Burnout is not eternal (been there for couple of times, and now very close to it). You have a lot to create and a lot to teach others to. Just give less f*cks to toxic people and get used to having more rest.
Thanks a lot! Well, I’m not going to change career anytime soon — everything else seems to be worse… Well, unless I find a way to have a nice life raising chickens in my (future) garden ;-)
And I’m sure I’ll need a hi-contrast version of my low-contrast theme in some 10 years…
P. S. Fixed the links ;-)
Yeah you're right, enough is enough ... relax, go out, get some fresh air, there's more in the world than software development, that's my big #1 principle as a dev!
Thamks! ;-)
Somewhere in the last decade, the corporate world discovered the wealth of free labour embedded in FOSS and has capitalized heavily on it. It's no longer devs sharing code with each other.
A lot of these panicked demands for more free labour come from users in corporate context. Either putting pressure on maintainers at the direct request of their boss... or trickle-down pressure to finish job X which needs open source project Y.
I've scaled my own open-source work waaay back because I have no interest in writing code for companies for free.
Yup! I'm also now using open source purely as a way of storing and reusing my own code.
I wonder if part of the problem is GitHub?
I have been fortunate and have not seen any of the toxicity that you saw. I took over developing the Roundup Issue Tracker as the 4th I guess release manager/developer after the original developer got tired of it.
However, we don't use github issues. I mean we are developing an issue tracker. We probably should use it 8-). We also don't use a forum, preferring an email list or IRC.
I wonder if this additional friction drives away the "hit and run" people. It probably also reduces uptake, although being used for 15+ years as the tracker for Python was good advertising.
Patches do take reworking, but the ones that have come in while I was primary developer have been good. The significant code allowing Roundup to support Python 2 to Python 3 was high quality and done by others. I have reworked a few patches here and there however. Having to create test cases for the code is where the tedium comes in.
Tooling is an issue, but fortunately, Roundup can run using just standard Python library modules. However recently some of the standard modules used have been removed. I was able to vendor the code successfully. Also the pytest ecosystem, sphinx documentation and other tools make development easier than in javascript.
You’re probably right — I’m sure GitHub makes it too easy to “contribute”, until people realize that it require actual work and that most projects won’t merge any code just because it appears in pull request.
It’s probably also worse for JavaScript since it’s so popular now, and everyone seems to “know” it now.
Some comments have been hidden by the post's author - find out more