- What it feels like to be an open-source maintainer
- Original author: Nolan Lawson
- What is it like to be the author of open source software?
- Translator: Square root of three
There are hundreds of people lining up outside your door. They patiently wait for you to answer their questions, complaints, pull requests, and feature requests.
You wanted to help them, but now you’re shutting them down. Maybe you’ve been working hard all day, or you’re tired, or you just want to enjoy a weekend with your family and friends.
But if you go to github.com/notificatio… It’s a constant reminder of how many people are waiting for you:
After you’ve managed to find some free time, you open the door and receive the first person. They are very kind. They try to use your project, but run into some confusion over the API. They pasted their code into the GitHub comment area, but they forgot or didn’t know how to format it, so their code was messy and hard to read.
You enthusiastically put their code into a block of code, so they have a friendly format. But you still need to read a lot of code.
And their descriptions of the problem are difficult to understand. Maybe the person is not a native English speaker, or they have a disability that makes it difficult for them to communicate through writing. You’re not sure. Anyway, it’s hard to understand the paragraph they posted.
You’re tired. You look at the hundreds of other people in line behind him. You can spend half an hour trying to understand this person’s code, or you can choose to skip him and just give him links to tutorials and documentation that will help solve their problem. You can also kindly suggest that they try Stack Overflow or Slack Channel instead.
The next man in line frowned. They complain that your project wasted two hours of their time because a specific API didn’t work as advertised. Their caustic remarks make you feel uncomfortable.
You don’t want to waste too much time with this person. You simply replied: “This is an open source project and maintained by volunteers”. If there are some bugs in your code, submit a reproducible test code or a PR.
The next person encountered a very common error, but there was an easy solution. You know you’ve seen this mistake before, but can’t remember where the solution was written. Stack Overflow? wiki? The mail? After a few minutes of Googling, you paste a link and close the problem.
The next person is a long-term contributor. You recognize their names from various community forums and buddy projects. They encountered a very deep problem and came up with a pull Request to solve it. Unfortunately, the issue is so complex that their PR includes several paragraphs explaining it.
Once again, your eyes dart to the hundreds of people still lining up outside. You know this person did a lot of work on their solution. And that may be a reasonable solution. Travis has passed the test. So you want To reply with “LGTM” and merge it.
However, you have suffered this kind of loss before. You once merged a PR without fully evaluating it. And in the end it gives you a headache because you didn’t anticipate the problems it caused. It might pass the test, but the performance drops by a tenth. Or a memory leak. Or maybe the API that led to the project was so complex that it was confusing to new users.
If you merge this PR now, you may have more problems tomorrow because you broke someone else’s workflow by solving this person’s (very marginal) problem. So you decide to put it off and deal with it later when you have more time.
The next person finds a new bug, but you know it’s actually a bug in a sibling project. They say the problem prevents them from running the app. You know it’s a big problem, but it’s only one of many. You don’t have time to fix it right now.
You reply that this seems like a real problem, but it would be more appropriate to report the problem in another REPO. So you close the problem and copy it into another REPO. Then add a comment suggesting where in the code to start fixing it. Though you doubt they will. (Rarely).
The next person simply said “What is this state?” . You’re not sure exactly what they’re talking about, so you check the context. Their comments about a long-standing bug in a project resulted in a lengthy GitHub comment board. Many people disagreed with the original solution to the problem, so it generated a lot of discussion.
There are over 20 comments on this question and it would take you a long time to read and understand all of them. So you just replied, “Sorry, this issue has been open for a while, but no one has solved it yet. We are still trying to understand the scope of the problem. A pull request might be a good place to start.”
The next person is just a GreenKeeper bot. This is easy to handle. Except that this particular repository has fairly fragile tests, and the tests fail for a reason that doesn’t seem real, so you have to restart it in order to pass the tests. You restart the test and try to remind yourself to check later when Travis can run it.
The next person opened a pull request, but on a fairly active repository, so another maintainer has already provided feedback. You glance at the general process, and you trust the maintainer to handle the problem. So you mark it as read and continue.
The next person has a big problem at runtime that you’ve never seen before. Unfortunately, they didn’t provide any details about when the problem actually happened. What browser did you use? Which version of Node? Which version of the project? What code can be used to reproduce it? You ask them to come back with some details and close the page.
The constant stream
After a while, you’ve dealt with a dozen of these situations. But there are still hundreds of people waiting. But now you’re exhausted. Everyone has their own complaint, problem, or new need.
In a sense, these GitHub notifications are a constant stream of negativity about your project. No one will open an issue or pull request because they are happy with what you have done. They only do this when they find something missing. Even if you spend very little time reading their notices, they can still leave you mentally and emotionally exhausted.
Your partner observes that you tend to be grumpy after doing these things. Maybe you find yourself laughing at her for no reason, just because you’re in a bad mood. “If working on open source makes you so angry, why are you doing it?” She asked. You don’t have a good answer either.
You can take a break. In fact, you can already try. There was a time when you took a week or two off from GitHub just for your mental health. But you know the reason you end it is because there are hundreds of people waiting patiently for you.
If you stay tuned and deal with your GitHub notifications. Maybe only 20-30 messages a day is easier to deal with. But you let them pile up there, so now there are hundreds of them. You feel guilty.
Before, for some reason, you really let these problems pile up there. You may have seen a question that hasn’t been answered in months. Often, when you go back and deal with a question like this, the person who opened the question never got back to you. Or they reply, “I abandoned your project and used another one, so the problem is solved.” It makes you feel bad. But you understand their disappointment.
You’ve learned from experience that a more practical response to an old question is to simply say, “I closed the old question, and please reopen it if it still exists or you can provide more details.” Usually no one replies. Sometimes people reply, only to angrily complain that you made them wait so long.
Now you try to follow your notifications more frequently. The queues of hundreds of people were too long. You long for the myth of a queue that’s down to a hundred, or a dozen, or even an empty inbox. So you go on.
Recruit a new contributor
After dealing with a lot of issues like the above, even if you finally empty your inbox, you’ll still end up with a backlog of bugs and pull requests. Labels can help — for example, you can mark a problem as “need to reproduce,” “Test cases exist,” or “Good First Patch.” Good First Patches are especially helpful because they often attract new contributors.
However, as you’ve noticed, the problems that usually attract new contributors are the easy ones — it’s more important for those problems to try to document and explain how to fix it than to just fix it yourself. You create these questions because you know it’s worth getting new people involved in an open source project, and you feel good when the author of the Pull Request tells you, “This is my first time contributing to an open source project.”
But you know they’re unlikely to come back. Often these people do not become long-term contributors or maintainers. You want to know if you’re doing something wrong, and if there’s more you can do to lead new contributors and help lighten your load.
One of your projects is almost self-sustaining. You haven’t touched it in years, but there’s a maintenance team answering every question and PR so you don’t have to pay attention to it. You are extremely grateful to these maintainers. But you don’t know what you did to get so many maintainers on that project, while other projects end up with you alone.
Looking to the future
You are reluctant to create new projects because you know it will only add to your maintenance burden. In fact, there’s a counterpoint: The more successful you are, the more “punishment” you’ll get from GitHub notifications.
You can still recall the creative passion, the joy of writing a new project from scratch that solves a previously unsolved problem. But now you don’t like the joy, because any new project steals time from the old one. You wonder if it’s time to officially discard some of your old projects or mark them as no longer being maintained.
You wonder how long you can hold out before you crash. You considered making open source your day job. But after talking to people who actually make open source their life, you know that this usually means making a specific open source project your daily routine. But that doesn’t help you because you have dozens of projects across multiple domains competing for your time.
What you want most is to have more projects that are self-sustaining. You try to follow all the best practices: you have a CONTRIBUTING. Md and a code of conduct, and you enthusiastically issue owner permissions to all who submit quality PR. Doing these things for every project is hard work, so you’re not as diligent as you think you are.
Since you know that open source is often seen as an exclusive club for privileged white people (just like you), you’re guilty of this too. So you’re anxious that you’re not putting enough effort into fixing these problems.
In any case, you feel guilty: You know you can help someone to solve their problems but instead let them rot for several months and then close it and guilt, or because you know that someone in your warehouse launched their first pull request but you don’t have time to reply to it and guilt, and you may also so that they feel discouraged for open source for a long time. You feel guilty for what you did, for what you failed to do, and don’t want to recruit more people to share your unfortunate experience of guilt.
Putting it all together
What I have said above is based on my own experience. I can’t claim to speak for everyone in the open source business, but that’s how I feel.
I’ve been working on open source for a long time (about seven years) and I’ve always hated complaining about these things because I’m afraid they’ll come across as exaggerated whining by people who should know better. After all, hadn’t I brought this on myself? I can leave GitHub whenever I want, and I have no obligation to anyone.
And shouldn’t I be grateful? My work on open source has helped me make a name for myself in the community. I’ve been invited to speak at conferences. I have thousands of followers on Twitter who listen to what I have to say and highly respect my opinions. I can say I got the job at Microsoft because of my experience in open source. Who should I complain about?
And I know a lot of people like me have given up. Those people were actively merging pull requests, fixing problems, and writing blog posts about their projects before they disappeared without a trace. For some of them, I won’t even open the issue on their repo because I know they won’t reply. I’m not going to complain about these things, but I’m afraid I’m going to follow in their footsteps.
I’ve taken a lot of steps to protect myself. I don’t use GitHub’s notification interface anymore. I use email for filtering. So I can categorize my notifications based on items (those that are not maintained are ignored) or the type of notifications (those that mention me and those I comment on are usually higher priority). Since notifications are by mail, it also helps me to work offline and do everything in one place.
I often get blue-level emails asking me to support a project that I have stopped maintaining (for example, I get at least one a month about this project, and usually I don’t respond to them. I also tend to ignore comments in my blog posts, responses to Stack Overflow answers, and questions in emails. I also mostly stopped paying attention to repo’s that I felt other maintainers were doing well.
One of the reasons this is so frustrating is that I increasingly feel that dealing with problems takes far more time than actually maintaining a project. In other words, I often only have time to read a question and say, “Sorry, I don’t have time for this right now.” This response alone has taken up most of the time I had reserved for open source.
Issue Templates, GreenKeeper, Travis, Travis_Retry, Coveralls, Sauce Labs… There are so many technical solutions to open source maintenance problems. I’m very grateful to them. I wouldn’t be able to stay focused without so many automated tools. But at some point, you have more of a social problem than a technical one. One man can’t be big. I’m not even in the top 100 CONTRIBUTORS to NPM and I’m already feeling the pressure. I can’t imagine what those 100 people must have felt like.
I’ve told my partner that when we decide to start having a child, it’s probably better for me to quit open source. I don’t know how I can balance my time between raising a family and working on open source. I expect that ultimately this will solve my problem: the nuclear option. I just want it to come in a positive way, like a new chapter in my life, not a negative way.
At the end of the word
If you’ve read this far and are interested in the problems and potential solutions of the open source community, you might want to check out “Roads and Bridges” by Nadia Eghbal, which is probably the clearest and most thorough analysis of the problem.
I’m open to suggestions, too, but keep in mind that I’m very reluctant to mix money and effort (for silly idealistic reasons) in my open source projects. But I’ve seen it handled well on other projects.
Note that while all of this is negative, I still feel that open source has become a valuable addition to my life. But I hope this is a useful window into how you can become a victim of your own success and feel pressured to leave work unfinished.
If there’s one thing I’ve learned in open source, it’s this: The more work you do, the more work you need. I know there is no solution to this problem.
This article is based on What It Feels Like To Be an Open-Source Maintainer by Nolan Lawson, with my own interpretation and ideas. If you want to reprint this translation, it is necessary to indicate the English reference: nolanlawson.com/2017/03/05/…
For more articles, stay tuned: github.com/sqrthree/sq… .