Open source guilt

gistfile1.md

So here's the thing: I've been releasing my code as open source for nearly 15 years. When I write something for me, I release it for other people. Inevitably, I eventually stop needing that thing, so I stop spending time on it.

When a PR comes in for a project I haven't actively worked on in a while, handling that PR requires me to reacquaint myself with the old code, remember how and why I made certain choices, consider whether accepting the PR would create any new maintenance burdens for me or would potentially introduce problems for users who've been using a stable and unchanged program for years now. If I decide it's worthwhile, then I have to test it. Maybe my old project has tests; maybe it doesn't. If it doesn't, that means I have to get it running and test manually.

More often than not, a PR will contain questionable code or inconsistent formatting or something else that requires some back and forth with the author. This takes time out of my day (often out of several days due to the async nature of this communication). Even if all goes smoothly and I end up accepting and pulling in the PR, now I have to decide whether to push out a new release. That means updating change history, maybe updating docs, bumping the version, building release packages, tagging them, pushing them, etc.

Some of this process can be automated, but much of it can't be. I have a lot of old projects that aren't popular enough for a new maintainer to step up and take ownership of, but that I don't want to just abandon, since people still use them. If I allow every PR that comes in to interrupt my day and force me through this process, I'll never get anything done. So generally I'll let PRs build up for a little while until I have a chunk of free time, and then I'll sweep through and deal with them all at once. Sometimes this takes months or even a year or two.

The beauty of open source -- and especially open source on GitHub -- is that none of this matters. If there's an outstanding PR on one of my projects that you want to use, you can fork the project and pull it into your fork. You have exactly as much control over the code as I do, and I use very permissive licenses for exactly this reason.

If something is important enough for someone to want me to spend my time on it but not important enough for them to spend their time on it, then it's generally not urgent, and I'm not going to allow myself to feel guilty about it. Otherwise, open source would be no fun at all.

The broad stroke of my generic statement on Twitter implies an ignorance of the difficulties to maintain a project. I'll give a specific example of what irked me: https://github.com/visionmedia/minstache
Take a look at pull request #7. This requires no testing and the only review would take 30 seconds to make sure the url to the repository is accurate. T.J. made a very useful little module that I was able to quickly add to my project for the one served page that uses it an then move on. However, because npm complains to me in the console every time I perform an install, outdated or update I am faced with a visual disruption to remind me. My first instinct was to quickly create a pull request myself. Then I see one sitting there since a year ago...

Sure, I could fork this project and fix the issue, but then do I release yet another version to npm? (my preference is to not directly rely on GitHub for node dependencies)

For complicated/opinionated/untested pull requests, I completely understand the difficulties involved with maintenance. I just wonder why spin so many plates, knowing that eventually they will start to fall.

Open source isn't about launching products. When I release something I've written, it's not because I want it to win marketshare or something; it's just because I work in the open by default. I write code for myself, and I share it for whoever else finds it useful.

But my needs change, so in time I may stop needing that thing I wrote. If someone else is willing to take over the project, great! But that's rarely the case. So that thing I wrote goes into maintenance mode, and I only touch it occasionally when I have free time, because I want to help the people who are still using it.

When I sit down to write a piece of software that I need, the questions of "should I release this?" or "is this too many spinning plates?" never enter my mind, because it's not a choice. I need something that doesn't exist, so I'm going to write it. I don't just sit around trying to think of ideas for a new open source project to start.

T.J. is one of the most prolific developers out there, and I know what it feels like to send him a PR that he doesn't look at for a long time. But I also know what it feels like from his side of things, so I try not to pressure him about it.

Open source guilt is a real thing that really hurts people emotionally and professionally. People get depressed over it, quit their careers over it, sometimes even contemplate (or commit) suicide over it. It's not worth it. As a community, we need to be more empathetic and supportive of people who volunteer their time and experience for the benefit of others.

My empathy for those maintaining open source is vast. My suggestion to alleviate the pressure is to focus their amazing energy on fewer things.

Software, open or private, is a thing produced by labor. In the open case, community participation should not be limited to passive consumption without critique. Without feedback, how could it improve to the greatest potential?

The open projects that persevere tend to be the main focus of those maintaining them. I am concerned there is entirely too much energy directed at reinvention vs. evolution.

What do you see as the path for an open source developer with many projects to focus on fewer projects?

As I've said, it's surprisingly difficult to find new maintainers, even for popular projects. So the choice ends up being between lightly maintaining something or just designating it "unmaintained" and ignoring it, and hoping it dies without pissing off too many people.

In my experience (I've tried both approaches on quite a few projects), the only real difference between the two is that I actually feel guiltier when someone asks a question or sends a PR for a project I've explicitly stopped maintaining, because I must actively ignore it instead of adding it to a bucket of things that I'll get around to when I have time.

In a perfect world, someone would come along and adopt the projects I'm no longer interested in maintaining, but that's happened to me exactly twice. So I have many projects that I no longer maintain actively, but that I'll do a small amount of work on once a year or so because people still use them. I feel this is a reasonable tradeoff. That code is still useful to somebody. Hell, sometimes a few years will go by and I'll suddenly need that project again, so I'll pick it up once more (this has happened to me more than once).

I worry that when people advise folks like T.J. to "focus on fewer things", what they really mean is "focus on the things I want you to focus on." The truth is that T.J. is focusing on fewer things, he's just doing so without explicitly killing all the things he's not focusing on at a given moment.

(This has been a fun discussion, by the way! I really appreciate you sharing your feelings on this, even though we seem to feel differently.)