The Reality Check Nobody Talks About: What OSS Costs

Open source is great, you’ll hear that from every advocate on Twitter promoting some closed-source software while sitting on a stable salary, telling others to “just contribute back to the community.”

Here’s what they won’t tell you: Open source will cost you money. Not just time—actual money. And mental energy. And probably a few nights of sleep wondering if your latest commit just broke production for someone in a timezone you can’t pronounce.

This is the first in a series about the reality of open source development. Not the feel-good conference talk version, but the 2 AM debugging session version. The one where you’re testing your gem on five different operating systems because apparently “works on my machine” isn’t a valid deployment strategy.

A quick note: This series was triggered on X when Josef Strzibny @strzibnyj mentioned that writing blogs or books genuinely helps people. After checking out his notes-to-self and buying his Kamal Handbook, I started writing notes too. Turns out writing isn’t that hard after all. My only problem was that my ideas come like JSON-RPC calls—in no particular order. But now in 2025 with LLMs, I can just sort them with AI.

From “It Works on My Machine” to “It Works for Everybody”

When I started doing open source, my world was narrow. If my code worked on my Windows machine, I felt like I’d achieved programming enlightenment. I should write a book, start giving conference talks, maybe get one of those fancy developer advocate jobs.

Then I opened a long, detailed critique about how a gem didn’t work on my Windows machine in some edge cases. Criticism is easy, right? You point out what’s broken, maybe suggest a fix, pat yourself on the back for being helpful.

That’s when @bf4, the maintainer, did something unexpected: he promoted me to maintainer of the gem.

I wasn’t ready for that.

Suddenly, issues started piling up. Some developer installing the gem on a legacy system, begging for patches. Another one trying to make it work on Alpine Linux or FreeBSD, i didn’t even know that existed. That Arch Linux user who insists on running the bleeding-edge kernel and thinks my code is causing their OpenSSL conflicts—when I’m just following the patterns from the Ruby docs.

This is when you learn the hard truth: OSS isn’t about “it works on my machine.” It’s about building stuff that works for everybody.

Let me tell you about the night that really drove this home. Spring 2023, 2 AM: automated alerts screaming about a remote code execution vulnerability in one of my gems. What followed was 36 hours straight of triage hell—patching five supported releases, writing tests, coordinating a CVE number, drafting release notes, and fielding panicked emails from users whose production systems were potentially compromised.

By hour 30, I was subsisting on cold pizza and caffeine, pushing fixes at 3 AM, then again at 6 AM on Sunday. No sleep, no weekend, no pay. Just the crushing responsibility of knowing that thousands of applications depended on getting this right.

That’s when you realize: every commit carries invisible weight.

The Hidden Costs Nobody Mentions

Let’s talk numbers. Not the inspiring “look how many downloads my package has” numbers, but the actual costs:

Hardware and Services

• Multiple operating systems: You need to test on macOS, Linux, Windows. Maybe FreeBSD if you’re feeling masochistic.
• Cloud CI/CD minutes: GitHub Actions is generous until you have real test suites. Then you’re paying.
• Hosting and infrastructure: Documentation sites, demo apps, artifact storage—it adds up.
• Hardware upgrades: Your 2018 MacBook isn’t going to cut it when you’re running Docker containers for five different Ruby versions simultaneously.

The Mental Tax

This is the big one. Every commit comes with invisible weight:

• Support requests: “Your gem broke my app.” (It’s usually their app, but you still need to help.)
• Security audits: Scanning dependencies, updating vulnerable packages, coordinating CVE disclosures.
• Documentation maintenance: Every API change means updating guides, examples, and FAQs. Miss one, and you’ll get the same question 47 times.
• Community management: Moderating discussions, enforcing codes of conduct, explaining why “just fix it” isn’t helpful feedback.

The Opportunity Cost Nobody Calculates

Here’s the part that’ll make you laugh (or cry): Most of your work will be donated. Let me put this in numbers that hurt.

If you spend 10 hours a week on OSS—which is conservative for active maintainers—you’re donating roughly 25% of a full-time job’s worth of effort. That’s a quarter of your professional capacity, unpaid. Whether you’re making $30k or $300k annually, that percentage stings the same.

The GitHub Sponsors button might get you enough for a coffee once a month. Maybe a nice coffee if you’re lucky. But that 25% of your working life? That’s coming straight out of your potential income.

And here’s the kicker: sometimes your brain gets so flooded with that critical OSS bug—the one that’s breaking production for hundreds of users—that you underperform at your actual paying job. You’re sitting in meetings thinking about edge cases, distracted during code reviews, mentally debugging someone else’s environment while you should be focused on your employer’s priorities.

Meanwhile, some startup is building their entire business on your free library, and when they finally open an issue, it’s a masterpiece like: “doesn’t work” with zero reproduction steps, no environment details, and a passive-aggressive tone that suggests it’s somehow your fault their deployment pipeline is held together with duct tape and prayer.

The Complexity Nobody Warns You About

When you do open source seriously, you don’t stay in your echo chamber of “two ways to do one thing.” You start learning how to build your own tools. Then you learn how to build tool factories. Then you learn how to build the factories that build those initial factories.

This is a level of complexity that only a few people are willing to tackle, and most aren’t willing to share their knowledge once they find the “secret”—not because they’re gatekeeping, but because you have to configure your brain and life in a special way that most people aren’t willing to do.

Because let’s be honest: building is addictive. And building in Ruby? Even more addictive. Ruby is probably the OG of vibe coding—you write a DSL, then you start building stuff on top of it.

The Infrastructure Nobody Sees

Here’s what maintaining a quality open source gem actually looks like:

Your .github/workflows directory becomes a small novel of YAML configuration, testing across Ruby versions (3.0, 3.1, 3.2, 3.3, 3.4, 3.5 and probably JRuby/TruffleRuby if you’re feeling ambitious), operating systems (Ubuntu, macOS, Windows), database systems, and different dependency versions—because semantic versioning is more of a suggestion than a rule.

Every week brings a new flavor of “it doesn’t work”: breaks on Ruby 3.4 with frozen string literals, incompatible with Rails 8 , fails on M1 Macs with native extensions, doesn’t work with bundler 2.7. Each issue requires investigation, reproduction, testing, and usually a patch that doesn’t break the other 15 configurations.

Then there’s the security work: dependency scanning with tools like bundle audit, monitoring for CVEs in your dependency tree, backporting security fixes to older versions, coordinating responsible disclosure when you find vulnerabilities.

All unpaid. All on your own time. All while maintaining the facade that you actually enjoy debugging edge cases at 3 AM.

Why We Still Do It

Despite all this, here’s why open source is worth it: It’s immutable proof of what you can build.

When you have OSS activity, you skip the interview bullshit. No respectable company will put you through coding challenges when they can see 12 years of your actual work on GitHub. They won’t ask you to implement fizzbuzz when you’ve built the library they want to hire you to work on.

I’ve seen developers claiming 12 years of experience who still struggle with rebasing or merging a PR without leaving <<< conflict markers in the code. Meanwhile, your GitHub profile shows exactly what you’ve built, when you built it, and how you handle edge cases.

Open source is your real resume. Everything else is just theater.

Coming Up Next

This is just the beginning. In the next post, I’ll tell you about how I accidentally became a maintainer and what that really means when the issues start piling up from platforms you’ve never heard of.

But for now, remember: if you’re thinking about getting into open source, budget for it. Not just time—actual money. And maybe invest in some good coffee. You’re going to need it during those 2 AM debugging sessions.

*This is Part 1 of a 4-part series on the realities of open source development.