This is a translated and slightly adapted version of 用開源專案建立職涯：從 Ruby 使用者到維護者的經驗分享.

I’m Stan, a Ruby developer from Taiwan. Over the past few years, I’ve been contributing to or maintaining several official Ruby projects, including IRB (the official REPL), RDoc (the official documentation generator), debug.gem (the official debugger), and ZJIT (Ruby’s new JIT compiler). Late last year, I was fortunate enough to become a Ruby committer through these contributions. I also received the 2025 RubyPrize.

I don’t have a computer science background (I studied public administration in college) and I’ve never studied abroad. I got here with a lot of help from others and a lot of luck. Building a career through open source is not easy, especially when English isn’t your first language and you’re far from the usual tech hubs. But if I could get here, maybe my experience can be useful to others.

This post is a collection of things I’ve learned over the years. Most of it comes from an AMA I did with the Ruby Taiwan community, so the content is a bit loose.

My Background

I started teaching myself to code in college in 2013. Before graduating, I interned and worked at a few Taiwanese startups. In 2017, while still in Taiwan, I found a remote job at a UK company. After four years, I moved to the UK. Six months later, I joined Shopify’s Ruby Developer Experience team, where I still work today.

My job is to improve the developer experience for Ruby developers by building and maintaining Ruby LSP, type checkers, debuggers, and other development tools (like the brand new Ruby indexer: Rubydex).

I first got into the open source community while working at one of those startups. I was using Ruby on Rails and would occasionally look at a gem’s source code. I realized “maybe I can contribute something.” With encouragement from my CTO at the time, I started making small contributions.

I became more active in the Ruby community after attending RedDot RubyConf in Singapore in the summer of 2015, and then my first RubyKaigi later that year. At those conferences, I saw engineers around my age sharing things like “I maintain this project” or “I’m one of the first 100 Rails contributors.” I thought it was really cool that you could have an impact on a community just by writing code and contributing to open source.

For Those Who Want to Start Contributing Seriously

This means you already have some context and don’t need extra time to set up the environment. You can even talk to your company about it: spending some work time fixing an issue and upstreaming it to the original gem is better than maintaining a patch in your own project. I still do this regularly at Shopify.

Use AI to Help You Understand the Codebase

Last year I started contributing to ZJIT, a JIT compiler written in Rust. I had never worked on a JIT compiler, never contributed to Ruby itself, and never written Rust. But AI helped me quickly understand the codebase, which significantly lowered the programming language barrier and let me focus on learning JIT concepts and keeping up with development.

Before AI, you had to figure all of this out on your own. Now you can understand a project’s architecture, what each part does, and how tests are written in half a day to a day.

Start with Small Contributions

If you’ve found a project but don’t know where to start, here’s what I’d suggest:

  • Improve tests. For example, extract repeated setup into helper methods, or rewrite confusing tests. Tests don’t affect users, so maintainers are more willing to merge them.
  • Find TODO comments, especially ones that have been sitting there for a long time with no one fixing them.
  • Remove deprecation warnings to clean up the noise.

These small things help you understand the codebase while building trust with the maintainer.

With AI, finding these things is much easier now. But make sure you verify and review everything before opening a PR. If maintainers think you’re sending AI slop, no one will want to review or accept your PRs.

On the other hand, some things aren’t great for a first contribution:

  • Changing dependencies. A project’s dependencies have a big impact on the development workflow and users. It’s easy to make wrong calls before you understand the project well.
  • Changing linting rules. Every team has its own development culture and preferences. It’s not appropriate to weigh in before you’re familiar with them.

Invest 40 Hours in a Single Project

It takes roughly that long before you can honestly say you understand part of a project, including its conventions and processes. At that point, your contributions start to be worth putting on a resume.

After putting in that time, you’ll likely find:

  • Related projects have similar issues you can also contribute to
  • Your experience is worth writing about
  • The maintainer is looking for help, and you’re one of the few people with enough contributions to be considered

(40 hours is from personal experience. Your number may vary.)

Ask Questions in Public

Use GitHub issues instead of email. Others might have the same question you do. Once it’s public, the maintainer only needs to answer once, and future questions can point to that issue.

Don’t worry about bothering maintainers when raising honest questions. Anyone who becomes a maintainer knows that answering questions is part of the job. When someone shows up and participates, we notice.

Sometimes you ask a question or open a PR and the maintainer takes a while to respond. That doesn’t mean they haven’t seen it. Often they know it’s important but need time to think, or have more urgent things to deal with first. For most projects, waiting one to two weeks for a reply is normal. Avoid following up after just two or three days.

Focus Short-Term, Stay Open Long-Term

If you already have contribution experience and are thinking about making open source the center of your career, my advice is: focus on one area for 1-2 years, but stay open long-term. Don’t cling to a single project forever.

For example, my contribution path over the past five years has been: debug.gem → Ruby LSP → IRB → RDoc → ZJIT.

When I first started contributing to debug.gem, I spent over 200 PRs becoming the second-largest contributor. Then through work I got into Ruby LSP and started learning about LSP servers and editors. After getting involved with IRB, I became a maintainer and eventually its top contributor. Then since 2024, I’ve redesigned RDoc’s theme twice, and now I’m rewriting and expanding its features. Last year I also contributed heavily to Ruby’s next-generation JIT compiler (ZJIT), learning a lot about low-level language implementation and optimization.

Each transition started from something I was already using or a field I was relatively familiar with (except for ZJIT, it was because I had a beer with Max and he was kind enough to give me a JIT 101 at a bar lol). For instance, in 2019 when I was contributing most to Rails, I was still doing Rails development and could test patches in my own company’s projects before submitting them. After joining Shopify in 2022 to work on Ruby DX, I no longer touched Rails, so I naturally shifted to contributing to Ruby itself and its surrounding tools.

But after getting comfortable, you should also try to expand your scope.

First, if your expertise is too narrow, it’s hard to connect it with your company’s changing needs, which limits where you can have impact.

Second, when you consciously expand the types of projects you work on, you draw inspiration from different sources. I went from debugger to LSP server to REPL, gradually shifting from being a single-tool expert to someone who understands most developer tools and can even integrate different projects together.

A recent example: after AI development tools became mainstream, I started building related tools like cctop, ruby-skills, and the rubydex MCP server.

Writing Code Isn’t Enough

This is important: writing code alone isn’t enough. You also need to make your contributions visible through blog posts, events, and talks.

Trust matters a lot in open source. Becoming a maintainer, getting help, getting your PRs reviewed. All of it comes down to “I trust this person.” If you never speak up and no one knows who you are, trust builds slowly. And if your goal is to make open source part of your career plan, you should prioritize building the trust as much as possible.

Here’s what I did to make the community aware of me:

Go to Conferences

Starting in 2015, I’ve gone to RubyKaigi every year except during the three years of the pandemic. Even when my company didn’t sponsor it, I bought my own ticket and paid for my own travel. Every day I make sure to attend at least one social event, whether it’s drinks or a coding party.

Many Ruby and Rails maintainers attend the RubyKaigi coding parties. You can sit next to them, discuss things, and work on PRs together. I once opened several Rails PRs at a coding party and they got merged right away because the maintainer was sitting right next to me.

My first year at RubyKaigi, I was too nervous to talk to Matz (Ruby’s creator). The second year, I started saying hi to him. Then I said hi every year after that. See him once at RubyKaigi, again at RubyConfTW in Taiwan, again at RedDot RubyConf in Singapore. Gradually, he got to know me too.

I actually joined Shopify because I met a current colleague at the online Euruko in 2021. A few months later when I was looking for a job, they referred me and I got the interview.

Write Blog Posts

You can write about what you did at work, what gems you used, or what PR you contributed today. It doesn’t have to be long. Just share what you learned. I’d suggest writing in English too, if you can. The more people who see your work, the better. You’ve already spent the time creating the content. Use AI to translate it into English and reach a wider audience. (Of course, always review and take responsibility for the result)

After you publish the post, share it on Reddit, X, or elsewhere. Over time, people will start to recognize your name and know who you are.

Give Talks

This is probably the most stressful, but it’s also very effective.

My first talk was at RubyKaigi 2017, about a toy programming language I built. A few community mentors in Taiwan gave me a lot of help and encouragement. After that first time, I gradually realized I could do this.

When companies look at your resume, they might not click through and read the discussion on your 5 Rails PRs. But if you tell them you gave a 30-minute talk at a conference, they can quickly skim your video and click through your slides. It’s a very effective way to demonstrate your ability. At the very least, it shows you can communicate. You got on stage and shared what you learned.

Don’t Let Language Hold You Back

A question I get a lot: what if my English isn’t good enough?

My English wasn’t good at first either. To contribute to open source, participate in the community, and find jobs abroad, I spent a lot of extra time practicing English.

I can still find my first PR, whose description has three grammar mistakes in just two sentences. But that’s totally fine.

Many maintainers in the community come from Europe, Africa, South America, and all over the world. English usually isn’t their first language either, and they often make grammar mistakes too. Non-native speakers are not at a disadvantage.

The real disadvantage is: not speaking up because you think your English isn’t good enough.

Imperfect English isn’t the problem. The problem is letting bad English stop you from speaking, from getting on stage, from replying on issues. If your English is really holding you back from speaking up, invest time in improving it. Not to meet someone else’s standard, but to convince yourself: my English is good enough, and I can speak up.

This Takes a Huge Upfront Investment

I spent roughly 500 to 1000 hours of personal time on open source projects at my busiest years. In the last few years it’s around 200~500 hours.

This career path has worked well for me, but I honestly don’t recommend it for most people. It requires a massive time investment with no guaranteed return. You could probably spend one or two hundred hours grinding LeetCode and get an offer at the same level.

When I first started contributing to open source, I wanted to demonstrate my coding ability. I didn’t have a CS degree and had zero relevant background. I didn’t want to use LeetCode and grind algorithms (I’m terrible at them). I wanted to show people my work in public. Let them judge me by 8 hours of thoughtful code, not 30 minutes of coding under pressure.

And that’s actually how my career has gone. After my first internship, I’ve almost never had to do a full technical interview. Even at Shopify, I was lucky enough to interview partially through my open source work.

But if you don’t have genuine passion for this, it’s not worth the time. It’s best to do it because you truly enjoy it.

Final Thoughts

Building a career with open source has been a rewarding path for me. But it requires a huge upfront investment, a willingness to be visible, and the ability to push through language and cultural barriers. And there’s no guaranteed return.

If you’re wondering whether this path is right for you, I hope this post is a useful reference.