Photo by Niklas Hamann on UnsplashMy friend Watson recently tweeted this:
I see this sentiment often; open source maintainers feeling bad that they’re not responding to contributors to their code fast enough. There’s an implicit assumption in open source right now: If you open source it, you are responsible for maintaining it. If someone files a bug or opens a pull request, it’s your job to respond and help resolve their issue. Unfortunately, maintainers rarely realize that this guilt can be managed. Although endemic, it is not inextricable from open source. Having an active GitHub doesn’t mean that you need to code in your free time, all of the time. There are a few ways to remove this guilt.
Onboard more maintainers
This is the most obvious solution to the problem. If you have a particularly active person who has been filing issues or opening PRs, you can ask them if they want to help you maintain the project. Sometimes this is obvious; when you have a project that has dozens of contributors, some people will help out with other issues and help you review PRs before they become maintainers. You should encourage this behavior, if you can. Saying “Hey, thanks for reviewing this for me,” is one of the easiest ways to do this. Follow up by asking them if they want to have merge rights in the future, or if they want to help in some other way. However, sometimes your project is just you and that one person who has opened a couple of PRs that you haven’t really had the time to look at. Saying ‘community’ in this case seems a bit over-the-top. Should you ask the person to help in this case? Yes, absolutely. We’re trying to optimize for you not feeling like you’re a bad maintainer. A repository with two contributors and two maintainers is much harder to stress about. You know that if someone files an issue in the future, you’re not the only person who promised to get to it. Onboarding new maintainers can take some initial up-front effort, especially if you have complicated test suites or a large amount of context that you need new coders to understand first. However, it’s largely worth it, because you can step back. Ultimately, another option is to onboard more than a few maintainers, and move the project to its own GitHub organization, so that it has a life beyond you. You don’t need to respond at all, when that happens — everyone knows that the community is the maintainer, not just the original creator.
Clearly Set Expectations
The problem with onboarding new maintainers is that, while you’re diffusing the stress around responding to people in a timely fashion, you’re not actually getting rid of the core problem. There is another way to do this: clearly tell people what your expectations are for the project.
The MIT license, the most common license on GitHub, has a clause in it that says: THE SOFTWARE IS PROVIDED “AS IS”. While this relates to warranties, it also can be viewed (not legally, I am not a lawyer) as a powerful statement about what you’re doing when you open source a project. You’re taking some code, saying “This is what I made,” and giving it to others to use. You’re not saying: “I will respond to any questions about this as fast as if you asked me a question in person." I would suggest taking this statement and expanding it in the Contribute section of your code’s README. Adding something like this does the trick:
This code is made available as it currently is; additions and support are not priorities for me. I offer no assurances that I will respond on time to any issues or pull requests. I may only respond rarely. If your company needs a faster turnaround, email me about paying for dedicated support. As always, this is an open source project, and you are free to fork it and improve it.
This paragraph does a few things. It tells everyone who uses your code that you’re not going to respond immediately, and that you reserve the right to do that. It lets people know that if they really need your help, they can probably use capital to persuade you, but otherwise, this is an open source, free project, and that’s that. It also reminds users that the code is open source; they’re free to copy it into their own namespaces or code, as long as they credit you. But, more importantly, this paragraph is there to remind you that it is not your job to maintain every single thing you’ve ever touched or made. When you open source code, you do it for a certain point of time; you’re not on the hook forever, if you don’t want to be. By making that explicit, you can probably sleep a bit better, knowing that other people know that. Of course, some community members may not understand this, and may still ping you over and over again, or file issues with the title “URGENT PLEASE HELP I can’t install.” With these issues, all you have to do is say: “Hey, didn’t you check the README?” You don’t need to apologize for not responding in time. You’ve already stated clearly that that’s not what you want to do.
And that’s OK.
Hire a maintenance company
A final option is to hire someone else to help you maintain work, like the PA that Watson mentioned. This is a bit harder, because finding good maintenance companies takes time and effort. You want either someone who understands your code and who can respond to people who file issues and help them resolve all of their bugs, or you want someone who is able to say “Hey, thanks, this is an open source project and we’re not able to get to your issue today.” If you write JavaScript, or you’re interested in the latter, I would suggest reaching out to Maintainer Mountaineer, my company which does exactly that. Otherwise, I would ask around for some good references for code maintenance companies, or offer to pay someone you’ve worked with before to help out. Something like Open Collective might work, too; you suggest that contributors pay for support, and then you offload that support to community members who want to be remunerated for their efforts. A couple of hundred dollars a month may be a worthwhile investment if it allows you to offload your guilt. Got any other suggestions? I’d love to hear them.