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.

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.

Burnout.

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!

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

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.

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...

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

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.

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.

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.

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

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.'

Conclusion

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.