Disclaimer

I was employed by Shopify on the Ruby Infrastructure team from May 2020 to September 2025 where I worked on various projects to improve Ruby’s performance such as Variable Width Allocation, Modular GC, and MMTk. My leave was voluntary and on good terms.

I am also on the Ruby core team.

My opinions here are purely my own and do not reflect the views of the Ruby core team, Shopify, or my current employer.

Background

It might be a bit of an understatement to say that there’s been controversy about RubyGems, Ruby Central (the non-profit that manages RubyGems), and Shopify (the largest sponsor of Ruby Central). If you want details, please research the situation; I won’t cover it here to avoid distracting from the points in this post.　

I’ve heard information from various sources about this whole situation and so I have my own stance on it. However, this blog post isn’t about assigning blame; it’s about how we got into this mess and how to move forward.

Shopify is monopolizing Ruby

This is a phrase I hear a lot on the internet. It’s true that Shopify’s Ruby and Rails Infrastructure team has a wide net cast on the Ruby ecosystem. Shopify employs (past and present) over 10 of the Ruby core team and half (6 of 12) of the Rails core team, and has deep financial and leadership ties to Ruby Central. So it’s no surprise that Shopify has quite a bit of influence on these projects and organizations.

Is Shopify monopolizing Ruby?

Given that Shopify has influence on so much of the ecosystem, it’s natural to be a bit concerned. But does Shopify really want to monopolize Ruby? No, they really don’t. The management team at the Ruby and Rails Infrastructure team have actively tried to collaborate with other large Ruby companies to help them grow teams that can contribute to open source. These companies have passionate developers who want to do this and have vision that can improve Ruby. However, time and time again, someone in the leadership chain at these companies drops the ball. They often have various excuses for doing so: whether they think that open source is just a donation, there’s more pressing issues for the team to work on, or they think that continuing on Ruby isn’t the future. This is disheartening for the developers. This may also be why all four Rails core members at GitHub are now employed at Shopify.

In fact, I’ve had this discussion with Tobi, the CEO of Shopify. He even tried to make some other large Ruby companies contribute more to Ruby, but alas, it didn’t seem to have made a difference.

Open source is the most fragile ecosystem

TLDR: xkcd 2347

Open source powers the internet. If open source stopped being maintained by benevolent people who work without monetary reward, we’ll be in chaos. Things will be broken, there will be lots of security breaches, and we would stagnate as a society. Few companies that recognize this; the others have their heads buried in the sand. The top public Ruby companies have a total market cap of over $500 billion (not even including subsidiary companies that use Ruby). I doubt even 0.01% ($50 million) of that gets poured into open source Ruby software annually. If open source software has bugs, underperforms, or contains security vulnerabilities, your company stands to lose far more than 0.01%.

Without Shopify, Ruby would have no:

YJIT: a JIT compiler in Ruby which gives double digit percentage speedups in Rails.
Variable Width Allocation: improves allocation performance and memory management in Ruby.
ruby-lsp: a great language server to improve development experience.
Tapioca: a tool to generate RBIs for Sorbet.
Bootsnap: a tool to improve boot times for large Ruby applications.

I could go on and on about the things Shopify does for the ecosystem, but I think you get the point.

Without these contributions from Shopify, would Ruby have collapsed? Probably not. But it probably would have stagnated, and when a programming language stagnates, it dies. With these features, companies start having excuses to migrate to other languages for better performance or better developer experience.

On a slightly different topic, if we look at the sponsorship tiers for Ruby Central, we see that any company or individual that sponsors over $2,500 gets their name listed on the Ruby Central home page. If we look on the home page, there are only two names. Shopify and Alpha-Omega. For such a critical piece of infrastructure to Ruby, it’s only backed by one company and one non-profit. That might get you thinking: where are the other $300 billion of companies?

Open source is the most resilient ecosystem

The section above might have been a bit depressing to read and it was certainly a bit depressing for me to write. But I also want to celebrate the strengths of open source. The people who work on open source are extremely passionate people with a vision of improving the world through the things that they make.

Companies wax and wane. Companies that fail to adapt will go bankrupt and new companies emerge to fill the gap. But open source is immortal. It will never fail to adapt to new markets because someone will force it to adapt by either contributing to it or forking it. This, I guess, is perhaps one of the reasons why companies depend so much on open source software.

What you can (and should) do

I discussed a few fragile aspects of the Ruby ecosystem above. How can we make it more resilient?

… but if you’re trying to convince your VP/CTO/CEO, that’s not the right question for me to answer. Instead, I’ll discuss some reasons why contributing to the language and framework that powers your business is an investment, not a donation.

You need experts of your language and framework

Your company probably have developers who are experts in each level of your stack. From your front end, to back end, to infrastructure that hosts all of this. But Ruby, Rails, and gems are all part of your stack too. Do you have people who understand this layer of the stack? If you don’t, then those parts of your stack are unmaintained.

So what do you lose if you don’t have people working on this layer of the stack?

Performance

If you work for a multi-billion dollar company running Ruby, your company might be spending tens or even hundreds of millions of dollars a year on cloud computing. How much does a team of, say, five engineers cost? $1 million per year? Maybe slightly more or slightly less depending on the location. But if that team can make your app 1% faster, they might just pay for their salaries, and we’re not even talking about the better UX from faster apps. Now, how does over 90% faster sound? Yes, as of the time of writing, YJIT speeds up railsbench by that much.

That’s not all though. Variable Width Allocation sped up railsbench by 2.1% and we did some garbage collector algorithm modifications that improved our production performance by 8%.

When your company upgrades Ruby you get all these performance gains for free. So why would you need people to work on this? Because you haven’t unlocked the full potential. These things were built by Shopify, for Shopify. The Ruby and Rails Infrastructure team at Shopify was careful to not work in a black box. The team took advantage of the fact that Shopify had the world’s largest Ruby app to gather data and experiment on it. So naturally, these features are optimized for Shopify’s workloads. Shopify’s code base was also optimized for YJIT and the garbage collector. These aren’t open source. So you’re probably not getting the full potential of these features.

Stability

All software have bugs. Ruby, Rails, and the gems that you use are no exceptions. You might run into these bugs when you modify your app code or perform version upgrades. Do you have the infrastructure to detect when it happens? Do you have people who are responsible for looking into it? Are they adequately equipped with the knowledge to fix it?

Most companies have error monitoring systems that keep track of exceptions that occur. However, I can confidently say that most companies don’t have any mechanisms to detect when Ruby or native gems crash. This is why I gave a talk at Rails World 2025 about how to prevent, detect, and fix crashes in Ruby that happen in production. Your app is probably already crashing in production occasionally. You might be brushing it off as the occasional, unexplained 500 response. But when you do a Ruby upgrade, gem bump, or just some code change, you might trigger Ruby to crash much more often. Many teams just revert, perform work-arounds, or open tickets upstream. But this just adds tech debt and slows teams down. A team who has expertise here would help you find the right solution.

Developer experience

Most of the developers at your company are probably working on the product. That makes sense as that is what makes you money. So therefore, they should be able to work as fast as possible to make the company more money. But if they are focused on solving problems for the customers, who are solving the problems of the developers?

And when there is nobody doing that, you’re left with an app that has an increasing amount of tech debt, the performance becomes increasingly worse, and the tests become increasingly flakier. The developer then has to spend more time writing the code, the reviewer has to spend more time understanding the code, and wasting time retrying CI because of test flakes. This is a classic case of the tragedy of the commons.

Such a team would not just be putting out fires, but can also work on automation and preventive measures to guide developers towards writing more maintainable code. This could be things like introducing more RuboCop rules, introducing and improving type coverage, and developing LSP plugins.

Now, let’s do some napkin math. Assume your company has 100 developers. If you had a team whose full time job is to improve developer productivity and the team is able to produce improvements such that it saves 30 minutes for each developer every day, then it would total 50 developer hours saved each day. Then this would justify a team of 6 developers to work on this.

Your business depends on infrastructure hosted by non-profits

Every time you run CI, the servers are likely pulling files from many different places that don’t charge you in any way. For Ruby apps, this almost certainly includes RubyGems. Even though they don’t charge you in any way, they work extremely hard to ensure that their systems are secure and have good uptime.

Supply chain security is a real threat. Just last month in September, hackers targeted the NPM accounts of maintainers of popular packages and inserted malicious code to steal credentials. Can you imagine how much of a headache it would be if you couldn’t trust the packages you pull off RubyGems? To ensure that this and many other kinds of attacks don’t happen on RubyGems, they need the funding and contributions so that the ecosystem can be more secure.

Do you remember the last time RubyGems has gone down? Me neither. And it’s not just that we didn’t notice it going down, it apparently really hasn’t gone down. In past few years, the products your (and my) company makes have probably gone down countless number of times! This feat isn’t some coincidence or good luck, it’s because there’s engineers who put care in building it and sacrifice their personal time to be on call. So we should recognize that and play our part in ensuring that the uptime remains good so we can bundle install all day, everyday. After all, if RubyGems went down, are you ready to pass a zip file of gems around?

Having your company known helps you hire talented Ruby and Rails developers

Your company probably hires developers from all sorts of backgrounds with different experiences. Some of them aren’t Ruby developers. This is fine, until most of your company aren’t Ruby developers. Now your Ruby code base has notes of Python, Java, Go, Rust, or JavaScript. So to prevent this from happening, you need to have a critical mass of Ruby developers that can guide the code base and other developers towards idiomatic Ruby and Rails.

But how do you attract these Ruby and Rails developers? There are a few ways to do this:

Building an engineering powerhouse: Companies that lead the way for Ruby and Rails have greater development velocity and thus attract better talent. There are many ways to approach this, such as open sourcing an internal tool or gem, or contributing bug fixes and new features into open source projects.
Sponsoring conferences: What better way to hire talented Ruby and Rails developers than to go to the place where they congregate. Your company can send employees to conferences, where they can build connections, get hyped, and learn about the latest in Ruby and Rails. Your company can also sponsor and even set up a booth with recruiters at the conference so people can get to know your company even better.
Publicizing work: Write blog posts, give talks at conferences and local meetups, make tutorial videos, or even livestream coding. These are just some ways to let the world know about the work you do. As Confucius says, “when three people walk together, there is always a teacher for me among them.” I’m sure there’s something you could let the world know about about, like what you’re working on, some quirk you know about Ruby, or tutorials to teach others.

Hiring is not difficult

If you’re management in your company and want to get on board contributing more to open source, great! But you might be wondering, how can you create the team for this? Isn’t it pretty difficult to hire people with niche skills like this? In my opinion, not at all! You likely don’t even need to look outside your company! I’ve met and worked with so many talented and motivated developers at various companies that could have done great things for open source projects. They just lacked the time and support from their companies to do so. So try it out, you can start off by encouraging employees to work on open source on one day of the week or in a company hackathon. It can be as simple as cleaning up your Rails app and upstreaming monkey patches and features you wish upstream had.

Conclusion

In summary, open source’s fragility demands our collective action to ensure its resilience. By investing in Ruby’s ecosystem, companies not only safeguard their future but also contribute to a thriving community. Let’s build a more sustainable path forward.