Or: Why can't you just merge my ten-line PR already?
I maintain over 200 open source projects. Apparently (this is news to me) I am ranked in the top 200 GitHub users by followers, and there are 18,000 forks and 42,000 stars across my repos.
On an average day, I see between 50-100 emails across my repositories for issues and pull requests, and I filter those down to about 5-10 that I deem worthy of a personal follow-up.
I merge between 5-10 Pull Requests per month, and commit new code or fixes around 166 times per month.
I'm one maintainer, in a tiny corner of the Internet, maintaining a small but broad set of projects from Ansible roles for infrastructure automation to a few small but still-used PHP and Node.js libraries.
Dealing with burnout
There have been a few times I've burned out. That's typical for many maintainers. You either learn coping strategies or burn out completely, and in the best case end up a woodworker or farmer. At least that's what I see most of the time.
My coping strategy for the past five years has been somewhat ruthlessly closing PRs and issues. I also wrote about enabling the stale bot two years ago, and let me tell you:
Despite how much some people detest the stale bot, it—along with a more laissez-faire attitude towards my projects—is the best burnout prevention measure I've taken.
I license my projects as open source for two reasons:
- I have a Pay-it-Forward philosophy when it comes to code and knowledge.
- It helps keep me strict about documentation, generalization, and security.
I don't publish my projects with an open source license because I want to leverage them into VC funding or build a new Silicon Valley startup. Nor do I plan on monetizing any of my projects through services or an 'open core' model.
I have a family, and I have a chronic illness, and I have to maintain some semblance of a work-life balance.
The problem is, users don't understand my project goals or life situation—not that I expect them to.
But some of these users and potential contributors take offense when an issue they post or a PR they toss over rots for a few months, eventually gets marked stale, and gets closed.
It's nothing personal.
I look at it this way: if I didn't use my strategies to stave off burnout, I wouldn't maintain my projects at all. And having a project that works well and is maintained for 80% of the people who find it is better—in my mind—than adding on extra support and maintenance burden by dealing with every issue and PR that comes my way. And in the end, I maintain the projects for my own needs first.
Maybe that sounds callous, but it's the reality of the open source contract, whether the project in question is backed by a multi-billion-dollar corporation or a random guy in St. Louis.
Why did you mark my PR stale?
Even a one-line PR that seems innocuous could break existing use cases, cause weird bugs that CI tests don't cover, and add maintenance overhead that I will be responsible for through the life of the project.
And maybe that one line change leads to the next Log4J. But the person who submitted it isn't going to be the one staying up late on the weekend before a holiday cleaning up the mess:
Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns. https://t.co/W2u6AcBUM8
— Volkan Yazıcı (@yazicivo) December 10, 2021
The buck stops with the maintainer(s).
Therefore I never consider any PR 'simple', outside of grammar fixes in a README.
I'm very picky about which PRs I'll even spend 5 minutes on—usually I'll only look into the code changes if it's (a) fixing a bug in my project, or (b) adding a feature I would consider adding on my own.
And of those PRs, I find problems requiring a follow-up more than half the time.
I have a unique problem of maintaining a diverse set of projects, rather than one or two massive projects, so sometimes I can't be as deep in the code on each project as I'd like to... but even for maintainers of one or two projects, a seemingly innocuous change can introduce major bugs for some percentage of existing users, so that possibility always tempers your enthusiasm to merge the code.
And then there are the PRs for features that I know I'll never use. Usually (in my projects' case) for obscure functionality only needed in severely restricted enterprise environments.
Therefore I often take one of two approaches:
- Instead of merging the fix directly, I'll patch in some functionality that allows my project to be more flexible, so they could plug in their specific changes more easily (but not as easily as them injecting their code directly into my project—thus giving me the maintenance burden).
- I'll recommend they fork the project.
And option number two is honestly where things end up a lot, for features I'd consider a minority use case. When I worked in the severely restricted enterprise environment, I was used to maintaining forks and/or patches for a number of projects, so I could make them work in our strange environment.
Where I thought it might be useful to the upstream project, I would submit patches and PRs, but I fully understood there was little chance of getting the changes merged.
That's life in the open source world. That's why there are a zillion forks of the Linux kernel. That's why there are 18,000 forks of my 200-odd projects.
So sometimes, when someone gets cranky about my choice to ignore a feature or gets overly zealous in calling me out publicly in an issue for not responding, I kindly tell them to go fork themselves. The project is open source for a reason.
Money
Every few years, there's another discussion about how, if only we could inject cash into the open source maintainer's pockets, we wouldn't have future Log4J's, or Heartbleeds, or Shellshocks. I don't think that's the case.
I'm one of the few maintainers who can actually pay my mortgage using the support from individuals and small businesses who contribute to my open source work. And I'm extremely thankful for that.
But I have two thoughts when it comes to 'compensation':
- Per my goals stated earlier, donations are not a contract—if
$megacorpwanted me to make a change to my code, I'd be more amicable if they donated, but I am not beholden to them, nor do I ever want to be (if I did, I'd just work for them). - I've had Patreon and other sponsorship methods for years; it was only after I shifted my approach that I started getting any significant sponsorship.
On that second point, I have to pull out the dreaded M-word that all software devs hate: marketing.
The only way I was finally able to venture out on my own, and devote more time to open source work, was to market things like my books and my YouTube channel. Book sales make up the majority of my revenue currently, and YouTube + sponsorships fill in the rest. And one could argue that most of the sponsorships I have are the result of increased visibility on YouTube.
Even still—with YouTube + book sales + donations—I make half what I made as a full time software developer, especially when I was consulting and charged a substantial hourly rate.
The truth is, money won't prevent the next Log4J vulnerability, or prevent maintainer burnout (leading to the next colors and faker fiasco). It helps, and it's necessary to try to fund developers better—but you can't just say "Microsoft should pay developer X $80,000/year and that will prevent another Shellshock."
Corporate money often comes with expectations, and as an open source maintainer, I have enough to worry about besides trying to keep tabs on which sponsors/donors expect what, so I make it clear they are not 'buying' my time or attention. They're just removing barriers to maintaining the best open source projects I can.
I do think companies should have open source funds, and allocate them to projects and maintainers they depend on, on a monthly basis. But I don't think it will solve the funding problem, mostly because this kind of suggestion has been on the table for over a decade, and there are multiple ways to route the funds (GitHub Sponsors, Open Collective, et all), yet larger companies still allocate a pittance (if anything) to open source maintainers.
Conclusion
This post was somewhat a stream-of-consciousness post for me, so I'm sorry it's a little disorganized. If you do want the greatest chance of me merging your code, I wrote about that back in 2018: How can I get my PR merged into your open source project?.
And if you work for a $megacorp, keep fighting the good fight to allocate some funding to open source projects and maintainers. A few companies are willing to substantially support certain projects they depend on, but they are sadly the exception, not the norm.
Comments
Not really related to what probably spawned this but while reading I couldn't help think about being the submitter of merge requests that never get merged. I've submitted patches with code coverage to projects I actively use and try to help maintain sit for years. Eventually its frustrating enough to lead me to _not_ help anymore and find alternatives. Sometimes at quite a bit of effort. I wonder how we as maintainers should weight the cost of accepting and owning the code vs engaging our community and encouraging additional maintenance outside ourselves.
This might also come from a specific project I've bounced off like this in the past needing some maintenance this morning. Not a great time for me to help and its hard to motivate myself to dedicate free time to it not knowing how much engagement I'd actually get.
The sad fact is, even the act of sharing the burden of maintainership comes with its own set of risks and tradeoffs—therefore many don't do it.
For my own projects, there are a few I have added co-maintainers on, mostly if I notice a pattern of someone who (a) seems to care more than I do about it, and (b) demonstrates a good level of trustworthiness in the issue queues and elsewhere (maybe via IRC, or Twitter, or other community areas).
I know that's not necessarily a direct response to your statement, but I kind of view contributions in that light—most contributions are drive-by pull requests, and you won't even get a response to the first follow-up comment. Some aren't, but it's hard on the first glance to identify which type it will be.
Obligatory XKCD https://imgs.xkcd.com/comics/dependency.png
No matter how many hours you put in creating things on the internet, you can never satisfy everyone. Im just dabbling into open source since a few years and I'm amazed at how much you are already doing. Been a lurker since I found your book about Ansible for DevOps (its one of the easiest way to learn a new technique I've found so far!) and just wanted to reach out, after reading this, to you by giving you my thanks. I work in IT and I know how demanding people can be and especially how vicious the internet can be.
Again, thank you for all the effort you put into your work and keep it up as your time permits, but don't forget about your family.
All I can say is well said. It felt like you were in my head when you wrote this!
Great post, Jeff!
Hey—if you ever do go all out burnout, I highly recommend the farmer approach. :-)
You can still make pull requests (when you milk your cow) and the only forks you’ll need are to pitch the manure she leaves behind.
Really well said Jeff. All I can say is that I appreciate you and all that you've done over the years. Keep it up man.
Open source promises collaborative development on a massive scale. But wasted PRs show that open source collaboration doesn't actually scale intra-project. More users does not lead to more merged PRs.
Open source doesn't lead to scalable intra-project collaboration because it ignores the human side of development. The n-th full time maintainer won't be sufficiently motivated to volunteer. And the required funding to motivate will never materialize.
The funding will never materialize because open source licenses constrain funding methodologies to those primarily based on attention (donations). And attention is a zero-sum game. If you have my attention, someone else doesn't. Hence, wasted PRs.
The Log4j maintainer had three sponsors before the security incident. Loads of users, no attention, no funding.
In order to actually leverage the multiplicative power of open intra-project collaboration, we need a funding mechanism which scales with users. That means we have to leave the realm of open source. But we can take the vast majority of open source properties with us! Actually, the only one we have to leave behind is the one which stops us from setting a fee.
I will not accept that we are simply stuck fighting for funding at the discretion of for-profit corporations. And where our only weapon is guilt.
I'm working on a solution which flattens the barriers that stop small software libraries from raising funds with micro fees:
https://github.com/openfare/openfare#micropriced-commercial-software
Thank you for your work Jeff!
Well stated. Do you link to this in your project readmes or that bot? Might help for a few people that would act nicely with the context.
Closed PRs and unanswered issue queue questions are still helpful open source tools. Helps a future user, often yourself do a sanity check.
I did have to change my expectations when beginning to use open source tools and maybe it's a lesson everyone needs to learn and maybe never does.
Glad the YouTube channel and books are going well and hope the decrease in income is significantly outweighed by positive changes! TTYL.
I do link to a similar post (though a bit shorter) from the bot, since I know some people get a bit mad when they see the message, so I figured I should at least leave a link to more explanation.
It is! Thanks :)