Maintainers of popular open source projects have it tough. Strangers who feel entitled will curse at you for not answering questions in time or not helping them search for the answers they want. Open source project maintainers often develop psychological issues. If you have open source projects, you may have already experienced this.
Nolan Lawson is a PM for the Web Platform on Microsoft’s Edge browser. He has participated in multiple open source projects, such as PouchDB, optimize-js, etc. What’s it like to be an open source project maintainer? Read his 7 years of personal experience.
Hundreds of people form a line, waiting outside your door. They patiently wait for you to answer questions, listen to their complaints, and respond to Pull Requests and Feature Requests.
You want to help them all, but you’ve been putting it off. Maybe you’ve worked hard all day, or you’re tired, or you just want to enjoy the weekend with family and friends.
But if you log into github.com/notifications, Notification will constantly remind you how many people are waiting for you:
screenshot showing 403 unread GitHub notifications
When you manage to find some free time, you open the door to greet the first person (i.e., handle the first issue, which may contain more than one person, same below). They’re kind enough; they want to use your project but are confused about the API. They paste code into a GitHub comment but forgot or don’t know how to format code, resulting in a mess.
Fortunately, you edit their comment to add code blocks and format the code. But there’s still a lot of code to read.
Also, their description of the problem is somewhat hard to understand. Maybe English isn’t their native language, or they lack written expression skills. Regardless, you try hard to understand the text paragraphs they submitted.
You glance tiredly at the other hundreds of people waiting in line behind. You could spend half an hour understanding this first person’s code, or you could just skim through and give them links to tutorials or documentation that might help solve their problem. You also pleasantly suggest they try Stack Overflow or Slack.
The second person frowns with displeasure. They keep complaining about how your project wasted two hours of their life because some API didn’t work as advertised. Their words are harsh and make you uncomfortable.
You don’t waste too much time on this person. You simply say, “This is an open source project maintained by volunteers. If there’s a bug in the code, please submit a reproducible test case or PR.”
The third person encounters a very common error with a simple solution. You’ve seen this error several times before but can’t remember where the solution is for a moment. Stack Overflow? Wiki? Mailing list? After searching Google for a few minutes, you paste a link and close the Issue.
The fourth person is a regular contributor. You recognize their name from various community discussions and sibling projects. They’re stuck on a very obscure Issue and submitted a Pull Request to solve it. Unfortunately, this Issue is complex, so their PR contains many dry paragraphs explaining the problem.
Once again, you glance at the hundreds of people still waiting in line. You know this fourth person spent a lot of effort on their solution, and the solution might be reasonable. Travis tests pass, so you plan to just comment “LGTM” and merge this Pull Request.
However, you’ve been burned by this kind of situation before. In the past, you merged a PR without sufficient review, and it caused new problems due to issues you didn’t foresee. Maybe tests passed, but performance dropped by 10%. Or it caused a memory leak. Or maybe this PR confused new users about the project because it made the API look overly complex.
If you merge this PR now, there might be more problems later because you interrupted another person’s workflow to solve this person’s problem. So you put it on the back burner, waiting for more time to handle it.
The fifth person found a new bug, but you know it’s actually a bug in a sibling project. They say this is blocking them from starting their App. You know this is a big problem, but just one of many, so you don’t have time to fix it right now.
You respond that this looks like a real issue, but it’s better opened in another Repo. So you close their Issue, copy it to another Repo, and add a comment hint about where in the code to start fixing it. Although you suspect they’ll actually do this. Few people do.
The sixth person just says “What’s the current status?” You don’t know what they’re talking about, so you look at the context. They commented on a lengthy GitHub thread about a long-standing bug in the project. Many people disagree with the current solution to this problem, so there’s a lot of discussion.
There are over 20 comments under this specific Issue, and it would take you a long time to read and remember them all. So you just respond, “Sorry, this Issue has been open for a while, but no one has solved it yet. We’re still trying to understand the scope of the problem. It would be best to open a Pull Request!”
The seventh person is just a GreenKeeper bot. Their problem is simple, except this particular Repo has quite fragmented tests, and the test failed for what seems like a false reason, so you have to retest to see if it passes. You restart the test and try to remind yourself to check again after Travis has a chance to run.
The eighth person opened a Pull Request, but the Repo is quite active, and another maintainer has already provided feedback. You glance at the thread, you trust the other maintainer will handle it, so you mark it as read and move on.
The ninth person seems to have encountered a bug you haven’t seen before. But unfortunately, they didn’t provide enough details about “how this problem actually occurred.” Which browser? Which Node version? Which version of the project? What code did they use to reproduce it? You ask them to clarify, then close this tab.
Issues Keep Pouring In
Before you know it, you’ve handled 10 to 20 such people. There are still over 100 waiting in line. But by now you feel exhausted; everyone is either complaining, has questions to answer, or has enhancement requests.
To some extent, these GitHub notifications constantly pour out the negative side of your project. When they’re satisfied with your work, no one creates an Issue or Pull Request. Only when they find something missing do they do so. Even if you only spend a little time reading these notifications, it’s mentally and emotionally draining.
Your wife observes that you’re always irritable after going through these routines. Maybe you find yourself snapping at her for no reason, just in a bad mood. She asks you, “If open source work makes you so angry, why do you do it?” You can’t find a good answer.
You could pause; in fact, you may have already experienced this. In the past, you took a week or two off from GitHub just for mental health. But eventually, you had to stop the vacation because hundreds of people were patiently waiting (for you to handle issues).
If you had kept up with GitHub notifications in the past, you might handle 20-30 per day. Instead, you let them pile up, so now there are hundreds. You feel guilty.
In the past, for one reason or another, you did let these Issues pile up. You might see an Issue that hasn’t been responded to for months. Usually, when you return to find that Issue, the person who raised it never responds. Or they respond, “We gave up on your project and used another one, which solved my problem.” This makes you feel bad, but you understand their frustration.
From experience, you know that for these old Issues, the most practical response is often to just say, “I’m going to close these old Issues. If this is still a problem for you, or you can provide more details, please reopen an Issue.” Usually, no one responds. Sometimes there is, but it’s just an angry comment complaining about making them wait so long.
So now you want to handle your notification inbox more diligently. Hundreds is too many. You yearn for this number to shrink to a hundred, dozens, or even the mythical zero. So you forge ahead.
Attracting New Contributors
After handling enough of these Issues, even if your inbox is eventually cleared, there may still be a backlog of many bugs and Pull Requests. Labels can help—for example, you can mark Issues as “needs reproduction” or “has test case” or “good first patch.” “Good first patch” is especially helpful because they can often attract new contributors.
However, the type of Issues you create that can attract new contributors are often the very simple ones to handle, and this type of Issue is more valuable when documented by new volunteers than when you do it yourself. You created some of these Issues because you know their value—getting newcomers to participate in open source. When the author of that Pull Request tells you “This is my first contribution to the open source community,” you feel great.
But you know the hope of them coming back is slim; usually, these friends won’t become regular contributors or maintainers. You suspect if you did something wrong, what aspects you could improve to attract new contributors to help share your burden.
You have a project that almost sustains itself. You haven’t touched it for years, but a group of maintainers respond to every Issue and PR, so you don’t have to personally. You’re very grateful to these maintainers. But you don’t know what you did to make so many contributors invest in this project, while other projects end up with just you, and only you responsible.
Looking Forward
You’re reluctant to create new projects because you know it will only increase your maintenance burden. In fact, there’s a reverse effect—the more successful you are, the more “punishment” you get in GitHub notifications.
You can still recall the thrill of creation, the joy of writing a new project from scratch and solving a previously unsolved problem. But now you start weighing this joy because any new project will inevitably take time away from old projects. You don’t know if it’s time to formally abandon one of your old Repos, or mark it as Unmaintained.
You don’t know how much longer this situation can continue before you burn out. You’ve considered making open source work your day job, but after talking to friends who actually do open source for a living, you know this usually means making a specific open source project your day job. This doesn’t help you because you have dozens of projects spanning multiple fields, all competing for your time.
What you want most is for more projects to be self-sustaining. You try to follow all the best practices: you have CONTRIBUTING.md and code of conduct, you enthusiastically hand over privileges to anyone who submits high-quality PRs. However, doing this for every project is also energy-consuming, so you’re not as diligent as you’d like to be.
You also feel guilty about this because you know open source is often seen as an exclusive club for privileged white males (like yourself). So you worry you’re not doing enough to solve that problem.
More importantly, you feel guilty: guilty because you know you could have helped some people solve their problems, but you let their Issues be ignored for months before closing, or someone opened their first Pull Request in your Repo, but you didn’t have time to respond, which might frustrate them enough to never want to participate in open source again. Your guilt is because of things you’ve done, and also because of things you haven’t done, and because you haven’t been able to recruit more people to share your unfortunate and guilt-ridden experience.
Bringing It All Together
Everything I’ve said above is based on my own experience. I can’t claim to represent all open source software workers; these are my own feelings.
I’ve been working in open source for quite a long time (about 7 years), and I’ve been reluctant to complain about any of these grievances because I worried it would be interpreted as a veteran who should know better exaggerating complaints here. After all, didn’t I create this situation myself? I can leave GitHub anytime; I didn’t sign a contract with anyone.
Also, shouldn’t I be grateful? The open source work I’ve done has helped me establish a position in the community. I’ve received invitations to speak at conferences. On Twitter, I have thousands of followers who listen to my thoughts and highly value my opinions. Arguably, I got my job at Microsoft because of my open source experience. What do I have to complain about?
However, I know many others in my position have already burned out. Partners who used to enthusiastically merge Pull Requests, handle Issues, write blogs showcasing their projects, then disappeared without a trace. For some of them, I don’t even want to open Issues in their Repos. Because I know they won’t respond. I don’t blame them, but I worry I’ll become like them.
I’ve taken many self-protection measures. I no longer use the GitHub notification interface—I use email filters so I can categorize notifications by project (Unmaintained ones can be ignored) or notification type (threads where I was mentioned or commented on usually get priority). Because it’s email, this also helps me work offline and manage things in one place.
I often unexpectedly receive emails requesting support on projects I stopped maintaining long ago (for example, this project, I still receive at least one email per month), and usually, I don’t respond. I also choose to ignore comments under my blog posts, not respond to Stack Overflow answers and mailing list questions. I also actively unfollow Repos I think others maintain well enough.
Another reason this situation is so frustrating is that you increasingly find handling Issues takes too much time away from actual project maintenance. In other words, I usually only have enough time to read Issues, then say “Sorry, I don’t have time to look at this right now.” Just the act of responding takes up most of the time I’ve reserved for open source.
Issue templates, GreenKeeper, Travis, travis_retry, Coveralls, Sauce Labs… There are so many technical tools to handle open source maintenance issues, and I’m very grateful for these tools. Without these automation tools, I couldn’t have kept my sanity. But at some point, you encounter many Issues where the social issues involved are more than technical issues. One person isn’t enough to explain. I haven’t even made it into the top 100 npm maintainers list, and I’m already tired of it; I can’t imagine what those 100 people experience.
I’ve told my wife that if we plan to have children, I’d better give up open source work. I feel I don’t have the ability to balance raising a family and maintaining open source projects. I anticipate that giving up open source will be the solution to my core problem. I just hope it comes in a positive form, like starting a new chapter in my life, rather than a negative form, like unceremoniously burning out.
A Final Thought
If you’ve read this far and are interested in the problems plaguing the open source community and potential solutions, you might want to study Nadia Eghbal’s “Roads and Bridges”. It’s probably the clearest and deepest analysis of this problem.
I’m also open to suggestions, although I keep in mind that I’m reluctant to mix money and labor in open source projects (perhaps out of naive idealism). But I’ve seen it work in other projects.
Please note that despite expressing the negative side of open source above, I still feel it’s a valuable addition to my life, and I have no regrets. But I hope this article is helpful for everyone, letting you see what it feels like to become a victim of your own success, and how you can feel burdened by unfinished work.
One thing I’ve learned from participating in open source is: the more you participate, the more is demanded of you. I realize this problem has no solution.
Reposted from: Developer Relations »
