James Long is an engineer at Mozilla. In this article, he discusses two roles in open source projects: starter and maintainer. How many open source project maintainers can persist without pay?
Starters and Maintainers
It’s late Friday night, my wife is asleep, and I finally have time to look at those pull requests from an old project I put on GitHub last year. My daughter has to get up at 7:30 in the morning, so I’d better not stay up too late.
Since I last checked, there are 9 new issues and 2 pull requests. The good news is that most issues can be closed, and the pull requests are trivial. Oh no, there are some major changes. I have to reconsider these changes and (politely) engage in a long discussion. It’s a breaking change, but they didn’t update the documentation, so we have to figure out how to notify every user to upgrade.
I should set up a better (push) way for the project to notify me of new issues and pull requests. But let’s be honest, that would just make me more exhausted. I simply don’t have that much time to respond to these (issues and pull requests). At least now, when I’m busy with other things, I can pretend it doesn’t exist.
Why Am I Pushing Myself Like This?
Admittedly, my code has helped many people, but the maintenance burden that comes with it is also very heavy, even though it’s just a small project. What if it becomes more popular (even my personal blog on GitHub, which is niche and not much used, already has over 1000 stars, oh my god?!), with more users using it? Then there will be even more work to do. It would become a 10-hour-a-week job.
I have great admiration for those who freely contribute a lot of time to Open Source Software</rt> (OSS) projects. I can’t imagine how much boring free work is being done. It’s great that people are so willing to help others and the community.
I also like to do this, but with a wife and daughter (and a second daughter on the way), plus an already high-intensity job, it’s basically impossible. And my job at Mozilla is basically all OSS work.
I Think the Only Reason I Can Keep Going Is Because I Like Being a Starter.
Everyone likes being a starter, but I want to make an impact and contribute. It’s easy to put something on GitHub, and if no one uses it, you can just ignore it, but that doesn’t make any impact. I want people to see what I’ve made, learn from it, and even use it. By writing libraries that can be used in production, I’ve helped people learn React, React-Router, sensors, hygienic macros, animations, and many other things.
But this also brings a burden.
Once People Use Your Code in Production, Do You Still Need to Maintain It?
You can say no, it’s your right. But most of the time, you want to see your ideas grow and evolve. The problem is that maintaining this motivation requires a lot of work behind the scenes.
Every project has two roles: starter and maintainer. People may play both roles in their lives, but for some reason, I find that for a single project, these two roles usually correspond to different people. Starters are good at taking important big steps in different directions, while maintainers are good at keeping the code alive.
Another big difference is that there is usually only one project starter, but eventually there will be multiple project maintainers, because one person cannot support the entire project. As it becomes more popular, there will be more issues, pull requests, and other requests, with a linear increase between the two. When the project’s popularity reaches a new stage, new maintainers must be added, ideally from existing heavy users.
Because one person cannot support the entire project, starters easily fall into a desperate cycle from the beginning: he/she has all these good ideas, but as some ideas are gradually implemented, there will be more and more noise (from others), which makes it difficult to realize future ideas. The key is that you either don’t forget existing projects or find maintainers for them, and the latter is usually not a task that can be accomplished quickly.
I am definitely a starter. I am interested in everything (curiosity) and not focused on a few concentrated areas. I have been maintaining this library for several years, but dealing with backlogged issues on Friday nights always gives me a huge sense of guilt.
From now on, I plan to make it clear that since the code I put on GitHub is experimental, I will not respond to any issues or pull requests. If I do release a library that can be used in production, it means I have already thought about who will maintain it. I don’t want to take on a second job anymore. :)
This is what I want to say to all maintainers: It is they who do all the thankless work behind the scenes to keep the code alive, including writing documentation, editing versions, registering domain names, etc.
Hey, there are quite a few issues to fix tonight, maybe I can solve everything by just adding a DEPRECATED notice to the README.
