Just Say No

Saying yes is easy—at first.

It makes you feel better. And it makes you feel like you can do anything! And the person you're saying yes to also gets a happy feeling because you're going to do something for them.

No No No

Saying no is hard. It's an admission you can't do something. And worse still, you're disappointing someone else who wants you to say yes.

But here's the thing: none of us is a god. We're people. We have a certain amount of mental resources.

Some people are kind of crazy and can do a lot more than you or I can, but nobody can do it all. And sometimes you can burn the midnight candle for a little while, but you're just building up debt. Every 'Yes' is a loan you have to pay off.

And that leads to the B-word.


It's okay to say no

But before I get into the weeds, if you need to check out for a bit, the one thing I want you to take away from this is:

Jeff Geerling says it is perfectly fine for you to say "No."

In fact, I encourage you to try it at least once today!

GitHub issues geerlingguy

That pull request that's 100 lines and'll take you an hour to review? No.

That issue that's requesting you to pull your project just in a slightly different direction? No.

That little opportunity that you've been waiting for but you just know you can't do right now? No.

It hurts, most of the time, but if you don't get better about saying 'No' more often, then your 'Yes'es become less fruitful.

Dealing with Burnout

Baseball bat kid hitting

The first time I seriously reflected on burnout as a maintainer was around 2016. I had a young and growing family, and had just had my third kid—with three under 5—and life was understandably getting stressful.

Back then I wrote this:

I don't like closing a PR without merging, because a PR means someone liked my project enough to contribute back. But sometimes it's necessary. I'm not trying to be a jerk (and I usually start by thanking the contributor to try to soften the blow), I'm just ensuring the continued health of the project.

I started changing my perspective. In that post, I gave some guidelines I could point to when considering a pull request or issue.

I finished out that blog post with:

Feel free to say 'no' when a PR doesn't meet your standards. So many projects get derailed by accepting too many new features without evaluating them for long-term maintainability, and it's a problem that's avoided by a simple two-letter word.

Jeff holding bag of diapers

A year and a few thousand diapers later, I talked about burnout at DrupalCon Baltimore.

And that was in 2017, after a major surgery to help with my Crohn's disease. Here's what I said then:

Having to deal with the ups and downs of Crohn's disease has really made me feel thankful for the times when I can be productive, and more importantly it's a constant reminder that you never know what someone else is going through, so I know it's important to always treat others with compassion and assume the best intent.

I was still a bit optimistic about how much I could take on. That session had a pretty positive vibe: we're all human, we all have our own struggles, we're all in this together, so if you have to say no, try to say it nicely and let people down lightly...

Jeff after surgery hospital bed

But little did I know, my health would tank over the next year, to the point I had a major surgery that basically knocked me out for a month.

It gave me a lotta time to reflect.

I started writing a book about Crohn's, but I also changed my perspective on saying No.

And just before the pandemic started, I wrote this:

Unless it's generating income, it's for me and I'm not gonna spend more than a couple hours a month looking at it—if that.

Little did I know, that change in perspective—that embrace of the word 'No'—would lead to the biggest opportunity of my lifetime.

No leads to opportunities

Jeff Geerling presenting on Raspberry Pis

I've always wanted to teach. I was even close to being an adjunct professor at a local university a few years back. But making that work while providing for a family and dealing with chronic illness would've been difficult.

But I started prioritizing the open source work that fed into my paid work, and adopted the mantra:

Be liberal with your 'no', be judicious with your 'yes'.

I wrote that blog post just a few days before starting my first YouTube livestream, migrating my Drupal 7 website to Drupal 8. I've always enjoyed sharing my open source work, and this was a new and unique way to do it.

YouTube livestream Ansible 101 series Jeff Geerling

Also a bit stressful, but it was the first real taste I had of educating on YouTube. So I spent an hour a week live-streaming the upgrade process, and then something huge happened:

The pandemic.

Suddenly thousands of developers were sent home during lockdown, and a many people had a lot of time on their hands.

So I decided to take a risk. Using time I freed up by my adoption of 'No', I devoted a few hours a week to prepping a new livestream series, Ansible 101. That series fed into another series on Kubernetes, and the rest is history.

YouTube stats Jeff Geerling

My YouTube channel took off during the first few months of the pandemic. After a year, I decided to roll off software contracting and go full-time into YouTube, open source, and writing.

Jeff with rackmount server in front of green screen

I still don't make as much as I used to as a full time developer. But now I can do more things, like be with my family, spend time on interesting projects, and teach.

None of that would happen if I didn't learn the power of the word 'No'.

And it's not just in open source. Saying No to that lucrative job offer, or that big fancy project, or to some new hobby is hard.

But it can pay off big time.

Practical Tips

Practical advice to prevent burnout for open source

First, if someone isn't paying you money, you don't owe them anything. Even if they've contributed a patch. That's nice, and I always show my appreciation for people who help. But you still don't owe them anything.

That's why we choose open source licenses. It says, basically, you can use my code. But it's not a support contract. It's not a retainer. For me, I usually provide the most liberal license, MIT, even though it's not the most 'purist' license out there. I do that because I encourage people to fork my projects.

If they're angry their feature that's critical to their business isn't merged yet? Well, fork it!

I also enabled the GitHub Stale Bot on most of my repos, and let me tell ya—for a lot of people that seems to be a hot-button topic.

But I'll repeat what I wrote in my most recent post on burnout from January:

Despite how much some people detest the stale bot, it—along with a more easygoing attitude towards my projects—is the best burnout prevention measure I've personally taken.

I enabled the Stale Bot because it was an admission of this fact: Unless I specifically mark an issue as a bug or being 'planned' in my roadmap, it's just not that important to me.

Note that I never lock an issue. There are millions of old, closed GitHub issues with tons of useful information. And I encourage people to work through things in an issue, regardless of its status. But for me, maybe I'm just crazy, but when I hop over to one of my own open source projects, and see a thousand open issues? That's not motivating.

Some people don't care about that. Some people love the anarchy of an inbox with 50,000 unread emails. I don't know how my wife does that. But that ain't me.

So I close issues. And I don't respond to anyone who tries to make me feel bad about it, because it's just not worth my time. That's another way I say 'No.'


So, "No."

Like I said at the beginning, that's all there is to it.

And I'm not the only one hammering out this message. Just a couple weeks ago, Mike McQuaid wrote this:

Maintainers need to learn to say “no” again and again. No to new features. No to breaking changes. No to working on holiday. No to fixing issues or merging pull requests from people who are being unpleasant. No to demands that something has to be fixed right now.

And if that's not enough, I just noticed a post by Connor Tumbleson on Open Source & Saying "No".

No is powerful, it gives you focus, it gives you freedom. And it might just be the thing that prevents you from burning out.

To anyone who doesn't like it, remind them that if you don't say No now, there's a good chance there won't even be an opportunity for a Yes later, if you're burned out!

The above post is a version of the talk I gave to open source developers at GitHub Nova 2022.


I agree!

PS: They always misquote me! I said, "Just say 'No *two* drugs.'"

Can I submit a PR to correct the misspelling of 'adjunct' (s/adjuct/adjunct) (Somewhere between snarky and pedantic. ;) And just kidding.)
Good points about PRs. The first one I got was to correct some typos and I merged it while thanking the contributor. For anything I expect might get contributors, I explicitly reserve the right to refuse them for anything I deem reasonable. I submitted a PR to a project that fixed some documentation errors. They merged and thanked me. I submitted a documentation PR to Homeassistant that was rejected because they didn't see the need for clarification. I won't bother them further with PRs.

Sounds logical, and practical Jeff. Stick to it.

The next time you're going to say "No, because", offer up a "Yes, if" option.
Starting a dialogue might benefit all the parties involved.

The only problem is that there are cases where the answer is never going to be Yes (e.g. a feature you will never support in your project), in that case, a No is more helpful because it indicates if the person wants that feature, the best way to get it is to fork the project or otherwise build it on their own.

The other issue I've seen is some developers who decide time is money say explicitly "pay a bug bounty of $X and I'll do it", and 99% of the time they're ghosted. The other 1% people start yelling at them online about how open source should be free and all that... so it's an unwinnable scenario. Being explicit with the 'No' solves that issue.

Bug bounties can work. Thunar now has built-in ctrl-pgup and ctrl-pgdn tab switching because me an another guy put up an $80 bounty to get it done.

Difference there may be it wasn't the primary developer saying "pay me or else", it was users saying "we'll pay this much if somebody codes it and gets it committed."

I like the message but it's slightly irritating to read someone always reference work they've written before. Try cutting all the "I wrote in 2014 just after X that" and self-quotations; it comes off as arrogant and it's not necessary for your argument flow.

I disagree, and I definitely don't think that it comes off as arrogant. I really appreciate Jeff providing quotes and links, as they provide context, and also a timeline for situations where Jeff has changed his opinion, and why. The links also provide the reader the opportunity to read the quote in the entire context of the original blog post.

Great post Jeff, as someone who has benefited from your code and work, thank you for all you've done, but bravo for prioritizing what really matters; your health, physical and mental, as well as your family. I always think of the Depeche Mode song, "Get the balance right" and I feel that's the path your on with this.

Related: a chapter of Essentialism: The Disciplined Pursuit of Less is dedicated to the power of saying no. I liked that book.