↤ March 06th, 2017
If you want your open source maintaining to be sustainable, you need to stop caring.
Nolan wrote a very in-depth description of what maintaining open source projects can feel like.
Mikeal suggests leaving projects is the solution, which I think is only the most extreme option.
I’m offering middle ground: stop caring.
I can relate to everything that Nolan is saying and I must know that Mikeal’s solution is always an option in order to be able to not care effectively.
Before I stop caring though, I’d like to address a flaw in how I see people apply “Inbox Zero”. Nolan uses the powerful metaphor of people in front of your door with their problems.
Just because there are people with problems in front of your door, that doesn’t mean they are your problems. You can choose to make them yours, but you want to be very careful about what to care about. Ideally you don’t care about any of these problems and none of these people (more on the people later).
Inbox Zero doesn’t mean you have to have looked at everything, or even handled everything (like replied to every email or commented on every issue), but to have sorted everything into piles that you can work on in batches (it’s more efficient from a context-switch perspective) when you have the time.
When you have the time. This implies that you have to make time to actually resolve issues coming into your inbox. This also means: if you can’t make time, these issues are not going to get handled. And the only way to be okay with this is to stop caring about the issues.
And being very good about being able to bubble to the top what you do want to take time for.
GitHub Notifications, like Email, is often treated as a world-writable todo list. This works for small number of people writing issues, but with a semi successful open source project or multiple small ones, you easily surpass this being a useful model.
As a result I treat all my open source notifications and email as: I might not get to this.
This is from my perspective of maintaining two large-ish Open Source projects: Apache CouchDB and Hoodie and many many small projects I started, or contributed to. CouchDB even went through the birth of the NoSQL database category, so on top of all the Open Source stuff, I had a nascent venture capital infused industry to deal with.
All the advice I have here is for later-stage Open Source projects. For early stage projects, care is the only thing you can give them. But once you’ve shipped version 1.0.0 or even 2.0.0, once you wrote all the documentation, once people start using the project in production with success, once you’ve talked the 100th person through getting started on IRC or Slack, your priorities have to change.
Here’s the list of things I do care about in later-stage Open Source projects:
Code of Conduct violations: these are basic ground rules that govern everything we do in a project. If somebody doesn’t play along, that needs to be dealt with asap.
Security issues: once you are used in production, handling security issues swiftly and professionally is a imperative. Since they can pop up at any time, you want to be having some spare time that you can allocate to this at all times. That doesn’t have to be you individually, but as a project, you always need to be able to handle these.
Trademark violations: Apache CouchDB is a registered trademark, and within the Apache Software Foundation it is the job of the Project Management Committee to go after trademark violations. US trademark law requires action against transgressors for a trademark to be upheld. So this is something I have to do. These things aren’t as urgent as security issues, and are usually solved with a form letter.
No new contributors coming in and signs of fellow maintainer burnout: I’ve written at length about this before in Sustainable Open Source.
Do I sleep/eat/have fun/sport/partner/friends/nature enough? If I don’t function, I can’t give anything to projects or people in Open Source. Michael Bromley sums it up nicely in Why I Haven’t Fixed Your Issue Yet.
Here is a list of things that come up repeatedly, with any variety of urgency, anger, and frustration:
“Hey, I found [other database] works better for me.”: Great! I don’t care.
“Hey I’m building this app / solving this university assignment, can you help me with…”: No, don’t care.
“Hey, I see you haven’t released a new version in X days/weeks/months/years”: I don’t care.
“Hey, I found problem X in your tool”: I don’t care.
“Hey, I can’t get started with your thing”: I don’t care (I’ve already written the docs).
“Hey, I reported this issue, but nobody is picking it up”: I don’t care, send a PR and it might get better.
“Hey, I opened a PR and it doesn’t get merged”: I don’t care.
“Hey, I opened a PR and it doesn’t get merged, and now I’m frustrated and I blame you for stringing me along to spend so much time on this.”: I especially don’t care about guilt-tripping.
“Hey, I read on Hacker News…”: I don’t care.
“Hey, your project is shit.”: Don’t care, insta-block.
None of this is to say that I don’t try and address these people’s issues and concerns, as much as I can, too. But on my terms and in my time, and the only thing that lets me sleep at night is not caring about any of these things. I’ll get to them eventually, some may fall between the cracks.
It’s not nice from a project or people perspective, but short of leaving the project and leaving it all behind, I found this to be the only way to make my personal Open Source maintainership sustainable.