Starters and Maintainers

December 29, 2015

Journal Entry, 12/18/2015 -

“It’s late Friday night, my wife is already asleep, and I finally found time to go through those pull requests on that old project I put up on github last year. My daughter is getting up at 7:30 though, so I better not stay up too late.

9 new issues since I last checked. 2 new pull requests. Hopefully most of the issues can be closed, and the pull requests are trivial. Ugh, nope, these are some significant changes. I’m going to have to think about this and engage (politely) in a long discussion. They also didn’t update the docs, and this is a breaking change, so we’ll have to figure out how to tell everyone to upgrade.

I should set up a better way to be notified of new issues and pull requests on my projects. But who am I kidding, that would just stress me out more. It’s not like I always have time to respond. At least now I can pretend like this doesn’t exist when other things are stressing me out.

Why do I do this to myself? I’ve helped a lot of people with this code, sure, but the maintainence burden that comes with it is crippling. Even with just one tiny project. If it becomes popular (and my personal clearly-hacky, clearly-DON’T-USE blog engine is over 1,000 stars, WTF), there’s just too much to do. It becomes a 10-hour-a-week job.

I hugely admire people who give so much time to OSS projects for free. I can’t believe how much unpaid boring work is going on. It’s really cool that people care so much about helping others and the community.

I care, too, but with a wife and daughter (and second daughter on the way) and an already-intense job it’s impossible to keep up. My job at Mozilla is basically 100% OSS work anyways.

The only reason I can think of why I keep doing this is because I like starting things. Everybody likes starting things. But I like to really make an impact. To contribute. It’s easy to put something up on github and ignore it if nobody uses it. But that’s not making any kind of impact. I want people to look at my stuff, learn from it, maybe even use it. I’ve helped people learn react, react-router, transducers, hygienic macros, animations, and more by writing production-ready libraries.

That comes with baggage though. Once people use your code in production, are you going to maintain it? It’s your right to say no. But most of the time, you want to see your idea grow and evolve. The problem is that it takes a huge amount of work to keep any momentum.

There are two roles for any project: starters and maintainers. People may play both roles in their lives, but for some reason I’ve found that for a single project it’s usually different people. Starters are good at taking a big step in a different direction, and maintainers are good at being dedicated to keeping the code alive.

Another big difference is that usually there is a single starter of a project, and there always ends up being multiple maintainers. This is because supporting a project alone is simply not scalable. It will grow in popularity, and there’s a linear correlation to the number of issues, pull requests, and other various requests. For every Nth level of popularity a new maintainer must be added, ideally an existing heavy user.

Because it’s not scalable to support a project alone, it’s easy for a starter to get caught in a cycle of despair: he/she has all these cool ideas, but as each get released there is a growing amount of noise to distract from future ideas. It’s crucial to either forget about existing projects or find maintainers for them, but the latter is not a quick task usually.

I am definitely a starter. I tend to be interested in a lot of various things, instead of dedicating myself to a few concentrated areas. I’ve maintained libraries for years, but it’s always a huge source of guilt and late Friday nights to catch up on a backlog of issues.

From now on, I’m going to be clear that code I put on github is experimental and I’m not going to respond to issues or pull requests. If I do release a production-ready library, I’ll already have someone in mind to maintain it. I don’t want to have a second job anymore. :)

Here’s to all the maintainers out there. To all the people putting in tireless, thankless work behind-the-scenes to keep code alive, to write documentation, to cut releases, to register domain names, and everything else. 🍷

Well, so much for catching up on these issues tonight. Maybe I’ll just add DEPRECATED to the README, that’ll fix it.”