GPG Fingerprint: D2B1 7F9D A23C 0A10 991A F2E3 D9EE 01E4 7852 AEE4
OTR Key: 83DFF1C9 95252513 D430604F 5E244CCC C8795B4B

Sustainable Open Source: The Maintainers Perspective or: How I Learned to Stop Caring and Love Open Source

March 06th, 2017

If you want your open source maintaining to be sustainable, you need to stop caring.

Wait what?

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.

Inbox Zero Redux

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:

Not Caring

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.