The Accidental Maintainer: How I Got Promoted by Complaining

This is Part 2 of a 4-part series on the realities of open source development. Read Part 1 here if you missed it.

There’s a moment in every developer’s OSS journey where you cross the Rubicon—you go from being a user who complains about broken software to being the person responsible for fixing it. For me, it happened faster than a git push --force to master.

I was that naive Windows-only developer. My world was small, predictable, and safe. If my code worked on my machine, I felt like I’d achieved programming nirvana. Ready to write books, give talks, maybe even start a podcast about my profound insights into software development.

Then I encountered a gem that didn’t work on my Windows setup in some specific edge case. And like any good developer, I did what came naturally: I wrote a long, detailed critique.

But let’s be honest about what most of us do first. We critique everything. “JavaScript sucks.” “Python is for PhD imbeciles.” “Ruby is for people who don’t actually code and don’t scale” It’s a coping mechanism to show that it’s not our fault—the universe just hates us.

Meanwhile, some COBOL developer is writing code that looks like Moroccan Harira soup and getting $500/hour while we’re fighting about semicolons on Reddit and Hacker News.

The Art of Productive Complaining

Here’s the difference: this wasn’t a drive-by “doesn’t work” GitHub issue or another language war rant. I actually put effort into it. I documented the exact steps to reproduce the problem, included my environment details, proposed a potential fix, and even researched why the issue was happening.

You know, like a responsible human being.

But here’s what I didn’t expect: @bf4 (Benjamin Fleischer), the maintainer of the ActsAsTaggableOn gem, read my critique and instead of just saying “thanks for the report,” he did something that changed my entire trajectory.

He promoted me to maintainer.

Just like that. One conversation, one thoughtful issue report, and suddenly I had commit access to a gem that thousands of other packages depended on. No interview, no trial period, no “let’s see how you handle a few small PRs first.”

Think about that for a second. I’m from Morocco, have a name longer than most password requirements, and my avatar is literally my cat. My entire web presence under @seuros consisted of troll posts in Bitcoin forums predicting it would crash once it reach $10 to $0. Yet here I was, getting commit access to a gem used by thousands.

What struck me wasn’t just the trust—it was how genuinely welcoming the Ruby community was. You had legends like Ryan Bates crafting those perfect Railscasts, Avdi Grimm philosophizing about confident Ruby, Jim Weirich building the very foundations with Rake. Then there was Rafael França, who seemed less like a human and more like some omniscient Rails bot—the guy somehow knew the context of everything and could review/merge PRs faster than most people could read them. DHH stirring controversy while building frameworks, Aaron Patterson making everyone laugh while optimizing Ruby internals, José Valim creating Elixir because Rails wasn’t concurrent enough.

These people judged contributions by merit, not by your LinkedIn endorsements or which bootcamp you attended.

I wasn’t ready for that.

At the time, I didn’t even know how to use git correctly. My workflow was pathetic: prepare a branch, verify it 100 times, then open a PR and pray I didn’t accidentally push my SSH key or some other embarrassing artifact. I had no idea how to rebase or force push—why would I? It worked, so I moved to the next stage, like that dude speedrunning Super Mario Bros who skips half the levels.

This is the dirty secret about a lot of “senior” developers these days. They’re seniors just because they opened a GitHub account 10-12 years ago, or bought one that shows that vintage. I recently worked with someone claiming to master JIRA as a PM who didn’t know what an issue transition was. Ten years of experience, one year repeated ten times.

When Reality Hits Like a Failing CI Pipeline

The first thing you learn as a new maintainer is that your problems just multiplied exponentially. Before, I had one environment to worry about—my Windows machine. Now I was responsible for making sure the gem worked everywhere, for everyone, always.

The issues started rolling in like a broken webhook:

• The Legacy System Guy: “Hi, I’m trying to install this on a production server running Ruby 1.8 on CentOS 6. It’s a banking system, so we can’t upgrade anything. Can you make it work?”

• The Alpine Enthusiast: “Your gem fails on Alpine Linux. I know it’s not officially supported, but all my Docker containers use Alpine, and I really need this to work.”

• The FreeBSD Purist: “Works fine on Linux and macOS, but breaks on FreeBSD. I’ve traced it to how you’re handling file permissions. Here’s a 47-line explanation of why your approach is wrong.”

• The Bleeding Edge Adventurer: “I’m running the latest Arch Linux with kernel 5.x, Ruby 2.1-preview, and your gem conflicts with the new OpenSSL version. Pretty sure it’s your fault.”

Each issue was like a small puzzle that required me to understand not just my gem’s code, but the intricate ecosystem it lived in. Ruby versions, operating systems, kernel differences, OpenSSL versions, filesystem behaviors—suddenly I needed to be an expert in everything.

The Education of Edge Cases

Here’s what they don’t tell you about becoming a maintainer: You become a systems engineer whether you want to or not.

That Arch Linux user with the OpenSSL conflict? Turns out it wasn’t my code at all. It was Ruby itself not being ready for the bleeding-edge libraries they were running. But guess who had to figure that out, document it, and explain it patiently to someone who was convinced I’d broken their setup?

The Alpine Docker user? Learned that Alpine uses musl libc instead of glibc, which handles certain system calls differently, it was failing in Nokogiri not even in the gems.

The FreeBSD issue? File permission semantics that work fine on Linux but fail spectacularly on BSD systems.

Each bug report became a masterclass in “things I never knew I needed to know.”

The Difference Between Criticism and Contribution

Before I became a maintainer, I thought I was being helpful by pointing out problems. And to be fair, I was—but I was also completely naive about the scope of what I was asking for.

When you report a bug, you’re essentially saying: “Hey, this specific thing doesn’t work in my specific environment. Can you fix it?” What you’re not seeing is that fixing it might mean:

• Supporting a new platform you’ve never tested on
• Learning about system-level differences you’ve never encountered
• Maintaining compatibility with 15 other configurations
• Writing tests for edge cases you can’t easily reproduce
• Documenting behavior that only affects 0.1% of users

Criticism is easy. Contribution is hard.

But here’s the thing: Benjamin Fleischer was absolutely right to promote me. Not because I was ready—I definitely wasn’t—but because I’d demonstrated something crucial: I cared enough to investigate, document, and propose solutions.

The Unexpected Promotion Strategy

Looking back, I realize what happened wasn’t random. Benjamin Fleischer had identified something important: I wasn’t just complaining, I was contributing intellectual effort to understanding the problem.

The difference between a helpful issue and a useless one isn’t just about reproduction steps (though those matter). It’s about demonstrating that you’ve done the work to understand the problem space.

Compare these two approaches:

The Useless Complaint: “Your gem doesn’t work on my machine. Fix it.”

The Accidental Job Application: “I’m seeing this specific error when running on Windows 10 with Ruby 3.1. I’ve traced it to line 47 where you’re using Unix-style path separators. Here’s the stack trace, my environment details, and a potential fix using File.join instead of string concatenation.”

Guess which one gets you promoted to maintainer?

The Cascade Effect

Becoming a maintainer taught me something profound about the OSS ecosystem: Every gem is an iceberg. The code you see is just the tip. Below the surface is a massive foundation of supported platforms, edge cases, legacy compatibility, and user expectations.

When someone opens an issue about your gem not working on their exotic setup, they’re not just asking you to fix a bug. They’re asking you to:

1. Learn about their environment
2. Understand why it’s different
3. Implement a solution that doesn’t break anything else
4. Test that solution across multiple configurations
5. Document the fix for future users
6. Maintain that compatibility forever

And here’s the kicker: they’re asking you to do all of this for free, on your own time, with enthusiasm and a smile.

The Maintenance Mindset Shift

The transition from user to maintainer isn’t just about getting commit access. It’s a fundamental shift in how you think about software:

• Before: “Does this work for my use case?”

• After: “Does this work for everyone’s use case?”

• Before: “I’ll just patch this locally and move on.”

• After: “How do I fix this without breaking the other 12,000 people using this gem?”

• Before: “This bug is annoying.”

• After: “This bug is my responsibility.”

That responsibility weighs differently when you realize that every commit you make affects thousands of applications you’ll never see, maintained by developers you’ll never meet, running in environments you’ll never access.

Why Benjamin Fleischer Was Right

Six months after that unexpected promotion, I understood why Benjamin Fleischer made that decision. It wasn’t about my technical skills—those I had to learn on the job. It was about my approach to problems.

The difference between someone who can maintain OSS and someone who can’t comes down to mindset:

• Users think: “This should work.”
• Maintainers think: “Why doesn’t this work, and how do I make it work for everyone?”

When you write a detailed bug report with reproduction steps, environment details, and potential solutions, you’re already thinking like a maintainer. You’re just missing the commit access.

The Real Promotion

Here’s what I learned: Every detailed bug report is actually a job interview. Every thoughtful issue, every well-researched problem description, every time you dig deeper instead of just complaining—you’re demonstrating maintainer qualities.

The promotion wasn’t really about Benjamin Fleischer giving me commit access. It was about recognizing that I’d already made the mental shift from consumer to contributor.

Coming Up Next

In the next post, I’ll break down the eight different types of OSS contributors I’ve encountered over the years—from the visionaries who see missing abstractions to the security sentinels who keep us all safe. Spoiler: there are way more than just “people who write code.”

But first, a word of advice: if you’re going to complain about a gem, make sure you’re ready to become its maintainer. Because the best maintainers don’t start with expertise—they start with curiosity and the willingness to own the problems they identify.

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