Outside your door stands a line of a few hundred people. They are patiently waiting for you to answer their questions, complaints, pull requests, and feature requests.
You want to help all of them, but for now you’re putting it off. Maybe you had a hard day at work, or you’re tired, or you’re just trying to enjoy a weekend with your family and friends.
But if you go to github.com/notifications, there’s a constant reminder of how many people are waiting:
When you manage to find some spare time, you open the door to the first person. They’re well-meaning enough; they tried to use your project but ran into some confusion over the API. They’ve pasted their code into a GitHub comment, but they forgot or didn’t know how to format it, so their code is a big unreadable mess.
Helpfully, you edit their comment to add a code block, so that it’s nicely formatted. But it’s still a lot of code to read.
Also, their description of the problem is a bit hard to understand. Maybe this person doesn’t speak English as a first language, or maybe they have a disability that makes it difficult for them to communicate via writing. You’re not sure. Either way, you struggle to understand the paragraphs of text they’ve posted.
Wearily, you glance at the hundreds of other folks waiting in line behind them. You could spend a half-hour trying to understand this person’s code, or you could just skim through it and offer some links to tutorials and documentation, on the off-chance that it will help solve their problem. You also cheerfully suggest that they try Stack Overflow or the Slack channel instead.
The next person in line has a frown on their face. They spew out complaints about how your project wasted 2 hours of their life because a certain API didn’t work as advertised. Their vitriol gives you a bad feeling in the pit of your stomach.
You don’t waste a lot of time on this person. You simply say, “This is an open-source project, and it’s maintained by volunteers. If there’s a bug in the code, please submit a reproducible test case or a PR.”
The next person has run into a very common error, with an easy workaround. You know you’ve seen this error a few times before, but can’t quite recall where the solution was posted. Stack Overflow? The wiki? The mailing list? After a few minutes of Googling, you paste a link and close the issue.
The next person is a regular contributor. You recognize their name from various community forums and sibling projects. They’ve run into a very esoteric issue and have proposed a pull request to fix it. Unfortunately the issue is complicated, and so their PR contains many paragraphs of prose explaining it.
Again, your eye darts to the hundreds of people still waiting in line. You know that this person put a lot of work into their solution, and it’s probably a reasonable one. The Travis tests passed, and so you’re tempted to just say "LGTM" and merge the pull request.
However, you’ve been burned by that before. In the past, you’ve merged a PR without fully evaluating it, and in the end it led to new headaches because of problems you failed to foresee. Maybe the tests passed, but the performance degraded by a factor of ten. Or maybe it introduced a memory leak. Or maybe the PR made the project too confusing for new users, because it excessively complicated the API surface.
If you merge this PR now, you might wind up with even more issues tomorrow, because you broke someone else’s workflow by solving this one person’s (very edge-casey) problem. So you put it on the back burner. You’ll get to it later when you have more time.
The next person in line has found a new bug, but you know that it’s actually a bug in a sibling project. They’re saying that this is blocking them from shipping their app. You know it’s a big problem, but it’s one of many, and so you don’t have time to fix it right now.
You respond that this looks like a genuine issue, but it’s more appropriate to open in another repo. So you close their issue and copy it into the other repo, then add a comment suggesting where they might look in the code to start fixing it. You doubt they’ll actually do so, though. Very few do.
The next person just says “What’s the status on this?” You’re not sure what they’re talking about, so you look at the context. They’ve commented on a lengthy GitHub thread about a long-standing bug in the project. Many people disagreed on the proper solution to the problem, so it generated a lot of discussion.
There are more than 20 comments on this particular issue, and it would take you a long time to read through them all to jog your memory. So you merely respond, “Sorry, this issue has been open for a while, but nobody has tackled it yet. We’re still trying to understand the scope of the problem; a pull request could be a good start!”
The next person is just a GreenKeeper bot. These are easy. Except that this particular repo has fairly flaky tests, and the tests failed for what looks like a spurious reason, so you have to restart them to pass. You restart the tests and try to remind yourself to look into it later after Travis has had a chance to run.
The next person has opened a pull request, but it’s on a repo that’s fairly active, and so another maintainer is already providing feedback. You glance through the thread; you trust the other maintainer to handle this one. So you mark it as read and move on.
The next person has run into what appears to be a bug, and it’s not one you’ve ever seen before. But unfortunately they’ve provided scant details on how the problem actually occurred. What browser was it? What version of Node? What version of the project? What code did they use to reproduce it? You ask them for clarification and close the tab.
The constant stream
After a while, you’ve gone through ten or twenty people like this. There are still more than a hundred waiting in line. But by now you’re feeling exhausted; each person has either had a complaint, a question, or a request for enhancement.
In a sense, these GitHub notifications are a constant stream of negativity about your projects. Nobody opens an issue or a pull request when they’re satisfied with your work. They only do so when they’ve found something lacking. Even if you only spend a little bit of time reading through these notifications, it can be mentally and emotionally exhausting.
Your partner has observed that you’re always grumpy after going through this ritual. Maybe you found yourself snapping at her for no reason, just because you were put in a sour mood. “If doing open source makes you so angry, why do you even do it?” she asks. You don’t have a good answer.
You could take a break; in fact you’ve probably earned it by now. In the past, you’ve even taken vacations of a week or two from GitHub, just for your own mental health. But you know that that’s exactly how you ended up in this situation, with hundreds of people patiently waiting.
If you had just kept on top of your GitHub notifications, you’d probably have a more manageable 20-30 to deal with 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’ve really let issues pile up. You might have seen an issue that was left unanswered for months. Usually, when you go back to address such an issue, the person who opened it never responds. Or they respond by saying, “I fixed my problem by abandoning your project and using another one instead.” That makes you feel bad, but you understand their frustration.
You’ve learned from experience that the most pragmatic response to these stale issues is often just to say, “I’m closing old issues. Please reopen if this is still a problem for you or if you can provide more details.” Usually there is no response. Sometimes there is, but it’s just an angry comment about how they were made to wait for so long.
So nowadays you try to be more diligent about staying on top of your notifications. Hundreds of people waiting in line are far too many. You long for that line to get down to a hundred, or a dozen, or even the mythical inbox zero. So you press on.
Attracting new contributors
After triaging enough issues like this, even if you eventually reach inbox zero, you might still end up with a large backlog of open bugs and pull requests. Labeling can help – for instance, you might label issues as “needs reproducing” or “has test case” or “good first patch.” The “good first patch” ones can be especially helpful, since they often attract new contributors.
However, you’ve noticed that often the only issues that attract new contributors are the very easy ones, the ones where the effort to document the issue and explain how to fix it outweighs the effort to just fix it yourself. You create some of these issues, because you know it’s a worthy goal to get new people involved in open source, and you feel good when the pull request author tells you, “This was my first contribution to an open-source project.”
But you know it’s very unlikely that they’ll ever come back; usually these folks don’t become regular contributors or maintainers. You wonder if you did something wrong, if there’s something more you could have done to onboard new maintainers and help lighten your load.
One of your projects is nearly self-sustaining. You haven’t touched it in years, but there’s a group of maintainers who respond to every issue and PR, so you don’t have to. You’re enormously grateful to these maintainers. But you have no idea what you did to get so many contributors to this project, whereas other projects wind up as your responsibility and yours alone.
Looking ahead
You’re reluctant to create new projects, because you know it will just increase your maintenance burden. In fact, there’s a perverse effect where, the more successful you are, the more you get “punished” with 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 weigh that joy against the knowledge that any new project will necessarily steal time from old projects. You wonder if it it’s time to formally deprecate one of your old repos, or to mark it as unmaintained.
You wonder how much longer this can go on before you just burn out. You’ve considered doing open source as your day job, but from talking with folks who actually do open source for a living, you know that this usually means permission to work on a specific open-source project as your day job. That doesn’t help you much, because you have dozens of projects across various domains, which are all vying for your time.
What you want most of all is to have more projects that maintain themselves. You try to follow all the best practices: you have a CONTRIBUTING.md and a code of conduct, you enthusiastically hand out owner privileges to anyone who submits a high-quality PR. It’s exhausting to do this for every project, though, so you’re not as diligent as you wish you could be.
You feel guilty about that too, since you know open source is frequently regarded as an exclusive club for privileged white males, like yourself. So you worry that you’re not doing enough to help fix that problem.
More than anything, you feel the guilt: the guilt of knowing that you could have helped someone solve their problem, but instead you let their issue rot for months before closing it. Or the guilt of knowing that someone opened their first pull request ever on your repo, but you didn’t have time to respond to it, and because of that, you may have permanently discouraged them from open source. You feel guilty for the work that you do, for the work that you didn’t do, and for not recruiting more people to share in your unhappy guilt-ridden experience.
Putting it all together
Everything I’ve said above is based on my own experiences. I can’t claim to speak for all people who do open-source software, but this is what it feels like to me.
I’ve been doing open source for a long time (roughly seven years), and I’ve been reluctant to complain about any of this, because I worried it could be perceived as melodramatic whining from someone who ought to know better. After all, isn’t this situation one of my own making? I could walk away from GitHub whenever I want; I have no obligations to anyone.
Also, shouldn’t I be grateful? My work on open source has helped give me my standing in the community. I get invitations to speak at conferences. I have thousands of Twitter followers who listen to what I have to say and hold my opinion in high esteem. Arguably, I got my job at Microsoft because of my experience in open source. Who am I to complain?
And yet, I’ve known many others in positions similar to mine who have burned out. Folks who enthusiastically merged pull requests, fixed issues, and wrote blog posts about their projects, before vanishing without a trace. For some of these people, I don’t even bother opening issues on their repos, because I know they won’t respond. I don’t hold it against them, but I worry that I’ll share their fate.
I’ve already taken plenty of self-care measures. I don’t use the GitHub notification interface anymore – I use email filters, so that I can categorize my notifications based on project (unmaintained ones get ignored) or type of notification (at-mentions and threads I’ve commented on usually deserve higher priority). Since it’s email, this also helps me work offline and manage everything in one place.
Often I will get emails out of the blue asking for support on a project that I’ve long stopped maintaining (I still get at least one per month about this one, for instance), and usually I just don’t even respond to those. I also tend to ignore comments on my blog posts, responses to Stack Overflow answers, and mailing list questions. I aggressively un-watch repos that I feel someone else is doing a good enough job of maintaining.
One reason this situation is so frustrating is that, increasingly, I find that issue triage takes time away from the actual maintenance of a project. In other words, I often only have enough time to read through an issue and say, “Sorry, I don’t have time to look at this right now.” Just the mere act of responding can take up a majority of the time I’ve set aside for open source.
Issue templates, GreenKeeper, Travis, travis_retry, Coveralls, Sauce Labs… there are so many technical solutions to the problems of open-source maintenance, and I’m grateful to all of them. There’s no way I’d be able to keep my head on straight if I didn’t have these automated tools. But at some point you run up against issues that are more social problems than technical problems. One human being just doesn’t scale. I’m not even in the top 100 npm maintainers and I’m already feeling the squeeze; I can’t imagine how those hundred people must feel.
I’ve already told my partner that, if and when we decide to start having kids, I will probably quit open source for good. I just can’t see how I’ll be able to make the time for both raising a family and doing open source. I anticipate that ultimately this will be the solution to my problem: the nuclear option. I just hope it comes in a positive form, like starting a new chapter of my life, and not in a negative form, like unceremoniously burning out.
Closing thoughts
If you’ve read this far and are interested in the problems plaguing open-source communities and potential solutions, you may want to look into “Roads and Bridges” by Nadia Eghbal. It’s probably the clearest-eyed and most thorough analysis of the problem.
I’m also open to suggestions, although keep in mind that I’m very reluctant to mix money and labor in my open-source projects (for perhaps silly idealistic reasons). But I have seen it work well for other projects.
Note that despite all the negativity expressed above, I still feel that open source has been a valuable addition to my life, and I don’t regret any of it. But I hope this is a useful window into how it can feel to be a victim of your own success, and to feel weighed down by all the work left undone.
If there’s one thing I’ve learned in open source, it’s this: the more work you do, the more work gets asked of you. There is no solution to that problem that I’m aware of.
Please feel free to comment on Twitter and to read responses by Mikeal Rogers and Jan Lehnardt.
Read the Tea Leaves 
Posted by Gustavo Leon (@hpneo) on March 5, 2017 at 1:47 PM
Just to say I feel 100% what you feel. Today I checked the only open source I maintain and it was heartbreaking have to close about 100 issues because I didn’t read them on time and they had more than a year waiting for some reply.
Some were known issues (I even have a wiki page with “Tips” and solutions to know bugs), others were questions about “how I do X but with your library”.
As you say, there is no solution for this problem. I only hope to have more time because I really like to build open source software.
Posted by Nolan Lawson on March 5, 2017 at 3:20 PM
Yes, one problem I notice is that there’s a wide spectrum from StackOverflow-style questions, to documentation bugs, to bugs in the code, to pull requests, etc… and increasingly I find they all wind up in GitHub where you have to triage them all.
Posted by Jarrett Widman (@jrit) on March 6, 2017 at 8:06 AM
I’d like to see GitHub allow, or maybe require, anyone opening an issue to assign a label. That could help with triaging. Bug, Feature Request, and Question ought to have different priorities as soon as they are entered, and this could make that much more direct if used correctly.
Thanks for taking the time to write this post.
Posted by jctanner on March 6, 2017 at 9:18 AM
@jrit auto-labeling is a key element of how we approach triaging the volume of incoming issues to ansible/ansible. Submitters fill out the template, and a bot applies the labels. If the submitter doesn’t fill out the template, the bot tries to figure out what they want.
https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md
Posted by Sebastian on March 5, 2017 at 4:34 PM
For unmaintained projects you can go into project settings and disable issues. It’ll save time for both you as a maintainer and the person reporting an issue as they will not waste time creating one that will never be read.
Posted by Timothy Gu on March 5, 2017 at 5:38 PM
This does work for issues, but not for PRs. People have tried to everything from a dear-github petition to add this feature (https://github.com/dear-github/dear-github/issues/84) to flamboyant notices (https://github.com/FFmpeg/FFmpeg/pull/153), but still nothing changes: https://github.com/search?q=is%3Apr+org%3Amirror+-repo%3Amirror%2Fmirror&ref=searchresults&type=Issues&utf8=%E2%9C%93
Cannot agree more with this post.
Posted by Nolan Lawson on March 6, 2017 at 4:58 AM
Unfortunately I believe that also makes old issues unviewable? I think that’s the reason I’ve avoided doing that.
Posted by Richard Drake on March 6, 2017 at 5:12 AM
That needs to be fixed by GitHub and fast, if so. Desire to save people time now makes past efforts futile? Makes no sense.
Posted by dhood on March 6, 2017 at 4:01 PM
If we’re talking about github, as a workaround for closing the issue tracker also making old issues unviewable, you could add an ISSUE_TEMPLATE.md to an unmaintained repository that explains the situation to users that go to open issues.
Posted by Amila Welihinda (@amilajack) on March 5, 2017 at 8:47 PM
What if there was a feature where users can write tests cases that show that the library is broken for a specific use case. Maybe submitting this kind of test case could be a requirement for creating a GitHub issue? Test driven open source? 😂
Posted by Richard Black on March 5, 2017 at 10:12 PM
Have you considered not taking the internet so seriously? You’re creating stress where it doesn’t need to exist because you’re an incurable normie. An open source project you’re not doing on paid time is a hobby and should be treated as such. If you really feel you need help dealing with social triage, recruit some people to help with that. If you feel hounded by emails, use an account or inbox that doesn’t alert on your phone. If you get hundreds or thousands of github notifications behind, oh fucking well, shit happens. Learn not to care what random third world retarded github shitposters think.
Either that, or close the issues page on github and start charging people money for support so you have motivation to deal with this bullshit.
Posted by vzaidman on March 13, 2017 at 3:36 AM
Worst comment ever lol
There is an actual serious issue that GitHub maintainers who abandon their repositories as time goes by.
I have some important repositories for technologies my company no longer uses, and some are a little obsolete for us in this point but in use of others.
Posted by vzaidman on March 13, 2017 at 3:38 AM
with GitHub maintainers*
Posted by Minexew (@minexew) on May 9, 2017 at 1:51 AM
PREACH!
Posted by greggman on March 5, 2017 at 11:09 PM
I don’t know what to add except to say “thank you!” for all your contributions.
I have similar feelings of guilt and frustration when someone uses some code I wrote and it doesn’t work for them or when they effectively want several hours of free work to fix something.
So far the good (feeling of contributing, sharing, helping) outweighs the bad (feeling guilt or frustrated)
I suspect many volunteer workers in other fields also have similar feelings. I wonder what they do. Of course most of them probably don’t have an “unread” box.
Posted by Karsten Lehmann on March 5, 2017 at 11:18 PM
Same as Richard: Don’t take it too seriously. Most of the guys filing issues should take a deeper look into the code and try to solve the issues themselves. Many of them probably never come back to the issue after they create it.
I had really hoped that you already earn money from your open source work. It’s shocking to see that you don’t, because PouchDB is such a great project (don’t know your other projects yet).
If that’s something you like doing, maybe you could offer paid trainings for it or build commercial addon modules as project work.
Keep up the great work, it’s really appreciated!
Posted by bebraw on March 6, 2017 at 12:18 AM
The main point for me at least is managing expectations. Communicate well the amount of support you are willing to provide. As someone said earlier, if it’s a hobby, you should treat it as such. If it becomes something commercial and you can live off it while being happy, so be it.
If you don’t think about your limits, it’s easy to reach a dark place. But once you establish some, people (most at least :) ) will respect that. There is no one right way to manage open source projects. Especially when it comes to personal projects, it’s mostly about what you want. If/when they reach community level, the dynamics will change, but so should the way the project is managed.
Take care. Good post.
Posted by lornajane on March 6, 2017 at 1:00 AM
Thankyou! For the work that you do, for the difference that you make, for taking this seriously. And most of all: for sharing these feelings. Open source leadership can be lonely and you reached out to support a group that is changing the world and needs to hear your words.
Posted by caspii on March 6, 2017 at 1:58 AM
I can’t judge your coding but you’re certainly a good writer!
Posted by leplatrem on March 6, 2017 at 2:04 AM
It felt really good reading your lines. The feelings you described sound really familiar!
One of the most promising initiatives I’ve seen recently was https://jazzband.co I think it can really help to feel part of a band, rather than being headlined…
Posted by Mark Liversedge (@liversedge) on March 6, 2017 at 2:05 AM
BRAVO. Echoed in my own experiences.
FWIW. I strongly doubt those “idealistic reasons” are silly.
Posted by Natim (@Natim) on March 6, 2017 at 2:36 AM
Thank you for writing that, I have seen a lot of maintainers struggling with that specific problem.
My understanding is that you try to make other people problems, your problem while it should stay theirs.
When you create a new open-source project it is because you are fixing an issue you have that might also be useful to another projects or to other people.
Always make sure it is easy for people to build on top of your project but don’t try to fix their problems.
If they have an issue that can also be one for your projects just fix it and say thank you.
For the rest rely on a community. Give powers for people using the project to be autonomous in improving it.
Don’t make it your project but a project, don’t make it your responsibility but their responsibility.
Makes it easy for people to contribute and take responsability in the project but stop there.
People building cars sell them but don’t drive them and don’t fix them, they rely on other people to do so. And people buying a car know they need to pay to fix it if they don’t do it themselves.
Code is cheap, what matters are communities. If you focus on code rather than community. a.k.a if you fix people problems rather than empowering them to solve them then you are on your way to burn out.
Focus on your projects, let people work on their’s. Give them responsability.
Posted by hollowdoor on March 6, 2017 at 4:02 AM
I wouldn’t worry too much. But personally I think you should be getting paid for some of the work. There’s nothing wrong with getting money for hard work.
My preferred general solution would be mentors. Services like Github need a system where open source veterans can choose a willing person to show the ropes. My feeling is that many people that want to contribute have fears because the world of open source is an unknown beast to them. I think a much higher percentage would contribute if there were a mentor system in place.
Sure there’s tutorials, but nothing beats someone talking things through with you in the moment.
Posted by Phil (@deebeejay) on March 6, 2017 at 5:18 AM
Great article, thanks for sharing. I know exactly how you feel. Although I’m not and probably never will be an open source maintainer, I can relate from other, similar experiences in my past and the one thing I took away from those is this: Learn to let go. Try and get rid of the noise and focus on the things that are most important to you.
This sounds obvious in hindsight but it’s something that came as a bit of a revelation to me at the time. It’s difficult at first but always remember that you don’t owe anything to anyone and you can’t fix everything yourself. Don’t stretch yourself too thin. That’s something I’m at peace with now and I’m a much more relaxed person for it.
Posted by Dave on March 6, 2017 at 7:05 AM
Even though I’m not an open source author, maintainer or contributor – or even someone who opens issues – I found your post enlightening and it helped me better understand what people like you do for the community. It has motivated me to make sure I show my appreciation to authors and maintainers of open source projects that I use. For that, I thank you!
Posted by Matthew Reid (@nocarryr) on March 6, 2017 at 8:31 AM
Thank you! I’ve been feeling the guilt you described very much lately just from being a collaborator on one project.
It’s good to know that I’m not alone there. (Maybe someone should start a support group)
I will say though that being a maintainer for a project that other people actually use has (hopefully) made me a better collaborator on other projects. Knowing what mainteners go through forces me to put every bit of leg work I can into an issue beforehand (reading through closed issues, PRs, etc). So at least there’s another positive takeaway.
Posted by Taavi Tänavsuu on March 6, 2017 at 8:56 AM
Having kids could truly reset priorities. It did for me.
Posted by the bear on March 6, 2017 at 10:12 AM
Excellent article. I hope that writing it and reading the comments has made you feel valued and helped you find a good balance.
I have been involved in Open Source projects for ca 20 years, mainly in science. It’s even harder in subjects that are not mainstream software engineering. Also you/we are often challenging vested commercial interests.
Wherever possible – and it often isn’t, but try – try to spread the load. Don’t be possessive. I have helped create a disperse community in chemical software ( https://en.wikipedia.org/wiki/Blue_Obelisk ). Here each software module is independent and we aim to interoperate where possible.
One model I developed was the “Doctor Who” models of Open Source – where one project leader would hand over to the next one like the Doctor’s regeneration every few years…( https://tech.slashdot.org/story/09/06/19/1326254/the-doctor-who-model-of-open-source )
But there is probably something worse that having 200 unanswered issues: having no-one interested in your project at all. The simple message is that it takes time – often up to 10 years – before a project gets critical mass. I use the wonderful Apache PDFBox – but 8 years ago there were perhaps 1-2 mails per week – now there is a large Stackoverflow usage.
So we do it for love – but – like some of the other posters – it also helps us get know and get jobs or projects. The hardest and loneliest thing is program maintenance. It never ends and there is very little satisfaction at the end. I have spent a whole day reconciling version numbers in the Java POMs of my project and triaging the commented out code and obsolete tests.
Posted by Martin Konicek on March 6, 2017 at 11:07 AM
I went through all of this when maintaining React Native, feeling sick and burned out every time I tried to keep up with notifications.
Here’s what worked:
Completely ignore notifications. Disable email notifications and never open the notifications tab on GitHub.
When you have some time to spend on your project:
– Focus on reviewing the most useful pull requests. They help a lot of people, are high quality or from long-term contributors.
– If you still have energy left, look at some top issues: e.g. sort issues by likes.
Posted by esraymond on March 6, 2017 at 12:17 PM
I maintain over 40 open-source projects. I shipped two releases today.
This is all very good, so much so that the one howler struck me with greater force than it might have otherwise. Sadly, having a “code of conduct” is no longer a best practice, if it ever was. Instead, it’s usually an invitation for people to engage in “social-justice” ratfucking that at best does nothing for your project, and at worst poisons the atmosphere.
I think it’s better to advertise that you will be arbitrary and tyrannical about who you let in and who you kick out, invite anybody who doesn’t like that policy to pound sand, and then…behave like a reasonable and liberal-minded person. That’s what I do, anyway.
Posted by crocket on March 6, 2017 at 10:58 PM
I think C4.1 contract can solve manpower problem by not repelling new contributors. It is a good system for recruiting contributors.
C4.1 is documented on https://rfc.zeromq.org/spec:42/C4/
C4.1 is based on http://hintjens.com/blog:106
Posted by crhylove on March 7, 2017 at 2:39 AM
Ironically, this is almost exactly how I feel as a sysadmin merely trying to IMPLEMENT some form of open source for end users.
“Hey everybody! You know how you all need online file storage to collaborate on your vital projects X, Y, and Z? I made you an owncloud and a super easy to follow YouTube video about how to use it!”
Then follows weeks of explaining what versioning is, why and how other people screwed up your data, how to fix it and recover it, how to use some crazy device I’ve never heard of to access it, why owncloud might be a better use case than google docs, how to watch the YouTube video (Yes, seriously), why this helpful tool was not a personal attack on a team member with seniority, How to store the files online and offline simultaneously, without letting one or the other get out of date…..
“F*CK it. Just use Google Docs.”
Posted by Start Up: Facebook’s video and child problem, ZTE swallows huge fine, trolls dissected, and more | The Overspill: when there's more that I want to say on March 7, 2017 at 11:01 PM
[…] What it feels like to be an open-source maintainer • Nolan Lawson […]
Posted by Amit gupta on March 8, 2017 at 5:32 AM
True. I read a similar article some times back and it changed my mind towards reporting an issue to any open source or freely available applications. They really put their hard work, valuable time to maintain such applications. They compromise with their personal life. And many time they don’t even get paid by donations or other support.
And it’s not limited to open source projects but many tutorial videos as well. When I recorded my first video I realised how hard it is to record a video and ignoring the comments.
This is not always for resume.
Posted by chrissannelong on March 8, 2017 at 7:55 AM
This applies to much more than open-source @nolan!
I’m just a lowly community manager of a local business network in a local community on Facebook, with almost 5,000 carefully vetted real human beings and while it’s less technical, everything you mention here applies.
I appreciate you writing it out and expressing what I’m sure many other “maintainers” feel as well.
I especially connect to your last 2 paragraphs.
I wish there was a solution – I’d pay for a platform that worked with FB groups but allowed me more control… kind of like what they are rolling out with Workplace, but designed for communities instead of internal/coworkers/employees.
I know I don’t have anything to offer except that I feel and acknowledge your frustrations! Keep going, because the work you’re doing matters.
And I always remind myself of the story of the boy who walks along the shore throwing the starfish back into the ocean. When the “realist” stops him to tell him that he’ll never be able to make a difference, he replies, “I just made a difference to that one.”
Excelsior, my friend!
Have a great day.
Posted by wpkitty123 on March 8, 2017 at 7:36 PM
Reblogged this on WordPress Self-Hosted.
Posted by CouchDB Weekly News, March 9, 2017 – CouchDB Blog on March 9, 2017 at 7:11 AM
[…] What it feels like to be an open-source maintainer, Nolan […]
Posted by Rich on March 9, 2017 at 9:24 AM
I love FOSS, both in practice & the philosophy. I’ve been a developer for 14 years. I’ve wanted to be involved in it since I discovered Fire”fox” back around version 0.6.
But, except for a few (really) simple patches, and grammatical fixes for websites, I’ve never gotten around to it, still not sure why not.
There is an outstanding bug in TBird’s calendar — snoozing event notifications longer than 2 hrs causes them to intermittently get lost until you restart TBird. The issue has been there for a decade or more, and it has been on my ToDo list, for a decade now, to join the TBird project, learn the language(s) it’s written in, find/fix that damn bug, just for my own peace of mind.
I still haven’t done it. It always feels like too much trouble. For 10+ years now, I still just keep restarting TBird every day or 3, to find my lost notifications.
If anyone’s read this far, I’d love feedback on how to … I don’t even know … on how to stop thinking about contributing, and start actually doing so.
Posted by Beluga on March 9, 2017 at 11:35 AM
“Attracting new contributors” is the most important section in your post. It is true that there is no scientific explanation on why contributors choose to stay. I find this fascinating and I have explored the subject in practice for several years.
Something specific I’d like to note: GitHub is not the best for collaboration. You can’t have a QA/triaging team on GitHub because there are no user access controls. To compare, LibreOffice QA team has 20-30 people roaming around a Bugzilla instance, changing keywords, statuses and all sorts of fields at will. That would be impossible in a crippled system like GH issues.
On the surface GitHub is attractive as it reduces friction (no need to self-host stuff, everyone is on it already etc.), but apparently it’s a recipe for burnout due to how it limits collaboration.
I recommend:
– use a tool that enables collaboration and self-organization
– make it explicit why users need to turn to contributors, explain the different roles and their importance
– encourage everyone to start inventing recruitment strategies immediately upon joining
You have to create a fractal of recruiting and mentoring.
Posted by Hugh on March 9, 2017 at 5:48 PM
Nice post, I feel your pain. One thing I have worked out is to not try to “sell” your project to anyone. If they like it, they are welcome to use it. If they do not like it in its current form – because of missing feature or bug – that’s ok too. They are better off at least having the option of the project than they would be if you had not open-sourced it. So if you get a post that suggests your project is inadequate, the sanest response is “it looks like I have nothing to offer you then” rather than feel any obligation to improve things.
Your point about not taking money is also a good one for mental health. I’ve done some hourly work under the condition that all work gets released open-source back into the project. But even this condition is not enough to avoid the feelings of obligation and the extra burnout is very real.
Posted by 我所讨厌的那些开发者 | 代码家 on March 10, 2017 at 1:19 AM
[…] 前两天，看到湾区日报推荐了一篇文章，名为：「What it feels like to be an open-source maintainer」，做开源项目维护者是一种什么样的体验。里面作者提到一些让他非常不爽的开源体验，读过之后感同身受，也很想写一些自己的开源经历。 […]
Posted by montas on March 10, 2017 at 4:06 AM
I’m just a guy with no IT formation what so ever and many times i thought how do you guy’s can have a regular job and get home to work for free to people who just complain even when they are kind.
Everything i know today, that help me provide some to my family, is depending on people like you.
I’ve done some works on IT, and some website without having any knowledge or education, not even a friend who can teach me.
I rarely have made a post in a forum, just searching and reading questions and solutions from other people.
You guy’s are in reality changing the lives of some dumbs that can’t appreciate their luck.
Thank you to mantainers, moderators, contributors and everyone who cares and share their knowledge so we can improve.
Posted by Bill on March 10, 2017 at 6:50 AM
What is there to say but thank you for your service?
Posted by De Week: Het failliet van toestemming, Uber (houdt het dan nooit op) en Steve “The Hulk” Jobs « Bits of Freedom on March 10, 2017 at 8:54 AM
[…] Lawson schreef een hartverscheurende post over hoe het voelt (of dus kan voelen) om een maintainer te zijn van een succesvol stukje open […]
Posted by lukaseder on March 10, 2017 at 11:11 AM
It was like that for me in the past. In my case, the problem was that I was turning my “hobby” / passion in an unpaid day time job. My solution was to quit my “ordinary” day time job, switch licensing to a dual-licensed model, and start asking for money. I’m not looking back to those times when I did all this for free. And neither do my customers who love the product even more.
Good luck!
Posted by cron.weekly issue #71: CVE's, Memcache-top, Ctop, Choria, s2n, Dnsmasq, Bash, Strace, Systemd & more on March 11, 2017 at 6:00 PM
[…] What it feels like to be an open-source maintainer […]
Posted by How to use—and not use—event listeners in web pages – The Studio on March 12, 2017 at 4:03 PM
[…] maintainer (or are thinking about joining the open-source community), you definitely should read What it feels like to be an open-source maintainer in his personal blog, Read the Tea Leaves: Software and Other Dark […]
Posted by chrisgilbert42 on March 13, 2017 at 4:27 AM
Great article. I think it’s important to talk about these issues and think of ways to deal with them. Open Source is useful and important to the world, but actually, your mental health is much more important than all the abstract stuff like that.
Other people have said similar things, but I have learned is that everyone’s issue is the most important thing in the world. To them. Who cares if it blocked them for a week? Or a year? Other people’s problems are not your problems. They will fix it themselves, or they won’t, but it’s unlikely any fairies will die either way.
Your life and time does, and should matter more than someone else’s time. Do what you can, and don’t feel guilty for not being able to solve everyone else’s problems.
Posted by Anon on March 14, 2017 at 1:21 AM
What you’re explaining is not unique to OSS.
If you hold onto any productive endeavour on the net, you’ll be constantly bombarded with this indifference. You know you give your time and care to it, and are discouraged when other people don’t share the same sentiments. They just don’t care.
That interaction you provide might be invaluable for you (do you know how much people pay for an hour of my time?) but it doesn’t matter to those people if you disappeared tomorrow. Don’t fall into the hubris trap of thinking they need you.
Your work will never be enough, just don’t beat yourself over it. Even if you come up with a button that solves all world’s problems on a click, more will be demanded from you next month.
Make some kids, invest in your relationship. Yes, it is sad that all your good intentions are diminished by this indifference, but why kick a dead horse?
Posted by If there’s one thing I’ve learned in open source, … - moblog on March 15, 2017 at 10:38 PM
[…] Nolan Lawson: What it feels like to be an open-source maintainer | Read the Tea Leaves […]
Posted by Lazy Reading for 2017/03/19 – DragonFly BSD Digest on March 19, 2017 at 5:47 AM
[…] What it feels like to be an open-source maintainer. (via) […]
Posted by passerby on March 20, 2017 at 7:41 PM
“You feel guilty about that too, since you know open source is frequently regarded as an exclusive club for privileged white males, like yourself. So you worry that you’re not doing enough to help fix that problem.”
Don’t do this to yourself. It’s OK to look out for your own self-interest. You’re not obligated to fight for team everyone-but-you.
Posted by Adam on May 12, 2017 at 8:29 AM
Hey Nolan,
I’m aware that this comment is just another thing to read but I wanted to thank you for your efforts. I use PouchDB in most of what I do and learnt a huge amount from your promises article. This specific article has taught me better etiquette should I ever need to raise and issue with someone’s software.
Thank you!
Posted by Tracker 💙 Meson | Sam Thursfield's Blog on May 22, 2017 at 8:52 AM
[…] done so in 5 years without any large corporate backing. Maintaining open source projects is often hard and thankless. Ten thumbs up to the Meson […]
Posted by skierpage on June 4, 2017 at 1:36 AM
For those about to maintain, we salute you! \o/
– AC/DC
You don’t owe anyone anything. They got free source that kind of works!!! So it’s ok to ignore everything.
Prioritize those issues that make your project better, i.e. pull requests and some test cases. Tell everyone that’s it’s only these that may get a response.
I used to earn a decent wage supporting external developers: writing developer documentation, releasing SDKs, providing technical support, investigating customer-reported bugs, etc. The web and GitHub have reduced the barriers, eliminated the friction, and cut out the middleman in those lesser jobs, which is awesome in cutting the costs of releasing software that has allowed 10,000 projects to bloom. But it leaves developers brutally exposed.
Posted by Open Source vs. vacation on June 28, 2017 at 2:20 PM
[…] falls into the same line as What it feels like to be an open-source maintainer , Why I took October off from OSS volunteering and After 10 years, I'm stopping my work on […]
Posted by Karel on July 6, 2017 at 10:25 PM
Thank you so much for everything Nolan. I hope you could find a company who could sponsor Pouchdb, so you could be working on the project in the mean time.
Posted by Macpro on August 14, 2017 at 2:05 AM
[…] Nolan Lawson: […]
Posted by Ken Soh on August 21, 2017 at 5:21 PM
I think something has changed in open-source the last few years. In the past there are many people who forked a project, contribute and maintain a project. Now there are much lesser. I don’t know is it because there are much more open-source projects now or is it the newer people who join do not have time or the technical skills to contribute / maintain code.
For whatever reason, it seems that most people now who looks for open-source projects are only planning to use it (take) but not contribute (give). For example, even when Puppeteer has 9k+ stars now, it has only 200 forks, compared to some older project with 6k+ stars there can be 1000 forks.
I don’t know why and what exactly changed, but this new undercurrent will make maintainers question whether it is a mistake in the first place to contribute and maintain projects.
Posted by Burnout and Twitter fatigue | Read the Tea Leaves on August 23, 2017 at 6:48 AM
[…] suppose it should come as no surprise that the author of “What it feels like to be an open-source maintainer” is suffering from burnout, but to be honest it caught me off-guard. Even after writing it, I […]
Posted by Tony on April 10, 2018 at 11:34 AM
It is not your fault that it turned out this way, Nolan
Posted by Moving on from Microsoft | Read the Tea Leaves on September 9, 2018 at 10:37 AM
[…] For those who follow me mostly for my open-source work, nothing will change with my transition to Salesforce. I intend to continue working on Mastodon- and JavaScript-related projects in my spare time, including Pinafore. In fact, my experience with Pinafore and SvelteJS may pay dividends at my new gig; one of my new coworkers even mentioned SvelteJS as their north star for building a great JavaScript framework. (Seems I may have found my tribe!) Much of my Salesforce work will also be open-source, so I’m looking forward to spending more time back on GitHub as well. (Although perhaps not as intensely as I used to.) […]
Posted by SIGAVDI #32: More than cartographers – avdi.codes on May 15, 2019 at 3:35 AM
[…] From What it feels like to be an open-source maintainer, by Nolan Lawson. […]
Posted by Michael Tsai - Blog - Ending the “npm Install Funding” Experiment on September 2, 2019 at 1:20 PM
[…] And we’re forcing the folks who are able to participate to make extreme sacrifices that inevitably lead to burnout. […]
Posted by Henry Zhu · The ReadME Project · GitHub on August 26, 2020 at 8:20 PM
[…] to be able to dedicate my mental energy to something I loved, and avoid juggling jobs with the burnout that maintainers so frequently […]
Posted by Linkdump 09/2021 | Dirks Logbuch on March 4, 2021 at 8:19 PM
[…] immer auf der Suche nach guten Quellen für Artikel. The picture the author draws is a bit dark, What it feels like to be an open-source maintainer. Zu welchem der vier gehören Sie? Es gibt natürlich auch Mischformen bei Lerntypen. Braindump, […]
Posted by Carlos Nunez on February 27, 2022 at 3:23 PM
Came here from Unix and Linux Systems Administration Handbook. I maintain a small OSS project and this hit right in the feels. My queue isn’t even this bad, but between triaging the queue i do have against other projects (public, employer, private) and life stuff, doing software professionally can be quite exhausting. I still love it though!
Posted by Loïc Dachary on June 25, 2022 at 4:30 AM
Just reduce your workload until you no longer feel guilt and you start to look forward to spending time on FOSS.
There is no relationship between you feeling overwhelmed by a hobby that requires too much of your time and FOSS. I’ve been a Free Software developer for more than 30 years and, at times, I had my finger in too many pies. It was not a good feeling. After reducing the number of projects I was involved it was, again, pleasant feeling.
Very simple solution to a universal problem. I’m surprised you did not come to this conclusion because everything in this excellent article leads to it. I’m also surprised that none of the comments in the past five years suggested it.