One engine, many tools — Introducing Rubydex

Introducing Rubydex — a portable static analysis engine powering Ruby LSP, Tapioca, Packwerk, and more. One foundation, compounding benefits for the whole ecosystem.

railsatscale.com

Optimizing Ruby Path Methods

Back in November last year, I started a new job at Intercom, and one of the first projects I got to work on was improving the Intercom monolith CI with some of my new colleagues.

byroot.github.io

Convert a Nova Launcher backup to Lawnchair format

Convert a Nova Launcher backup to Lawnchair format - nova2lawnchair-README.md

gist.github.com

mailchi.mp

Implement moving Immix in MMTk by peterzhu2118 · Pull Request #15744 · ruby/ruby

This commit implements moving Immix in MMTk, which allows objects to move in the GC. The performance of this implementation is not yet amazing. It is very similar to non-moving Immix in many of the...

github.com

Takashi Kokubun, ZJIT: The future of Ruby performance. San Francisco Ruby Conference 2025.

YouTube video by Evil Martians

youtu.be

ZJIT is now available in Ruby 4.0

ZJIT is now available with the release of Ruby 4.0. Here’s an update of our progress.

railsatscale.com

Introducing Aliki: A Modern Theme for Ruby Documentation

Ruby’s documentation gets a fresh look. Starting with RDoc 7.0.0, Aliki is the new default theme—bringing dark mode, better search, and a modern layout to docs.ruby-lang.org and gem documentation.

railsatscale.com

RubyConf 2026 Program Committee Interest Form

Hello and welcome! We are excited to announce our recruiting search has officially opened for the the 2026 RubyConf Program Committee Members. RubyConf 2026 will be happening in Las Vegas, July 14 -…

docs.google.com

Optimizing Ruby performance: Observations from thousands of real-world services | Datadog

Learn about trends in Ruby development and opportunities for improving performance that many organizations are leaving on the table.

datadoghq.com

A catalog of side effects

Optimizing compilers like to keep track of each IR instruction’s effects. An instruction’s effects vary wildly from having no effects at all, to writing a specific variable, to completely unknown (wri...

bernsteinbear.com

Why Ruby Devs Keep Mixing Up Symbols and Frozen Strings; and How to Tell Them Apart

Every time Ruby developers start talking about # frozen_string_literal: true, someone inevitably...

dev.to

GitHub - eregon/ractor-shim: A shim to define Ractor by using Thread, if not already defined

A shim to define Ractor by using Thread, if not already defined - eregon/ractor-shim

github.com

a-k-r.org

Frozen String Literals: Past, Present, Future?

If you are a Rubyist, you’ve likely been writing # frozen_string_literal: true at the top of most of your Ruby source code files, or at the very least, that you’ve seen it in some other projects.

byroot.github.io

Searching Ruby's documentation - John Hawthorn

The official Ruby docs are at https://docs.ruby-lang.org/en/. This documentation (and any documentation built with rdoc 6.15.0 or greater) now can be searched using a query parameter. Check it out! ht...

johnhawthorn.com

The Transition of RubyGems Repository Ownership

ruby-lang.org

Organizations, Like Code, Deserve Refactoring | Robby on Rails

I’ve been thinking about what happens when open source organizations hit their breaking point… when funding dries up, relationships fracture, and everyone’s ...

robbyonrails.com

Rubygems.org AWS Root Access Event – September 2025

As part of standard incident-response practice, Ruby Central is publishing the following post-incident review to the public. This document summarizes the September 2025 AWS root-access event, what…

rubycentral.org

Dear Rubyists: Shopify Isn’t Your Enemy

I’ve been meaning to write a post about my perspective on Open Source and corporate entities. I already got the rough outline of it; however, I’m suffering from writer’s block, but more importantly, t...

byroot.github.io

Why I'm not rushing to take sides in the RubyGems fiasco

We are in the midst of a Ruby drama for the ages (https://www.theregister.com/2025/09/25/open_source_to_closed_doors/). I'm sure a bunch of people figured we were all too old for this shit, but apparently we are not. This debate has been eating at me ever since the news first broke, but I've tried to keep the peace by staying out of it. Unlike most discourse about what's going on, my discomfort stems less from the issue at hand—what Ruby Central did, how they did it, and how poorly it was communicated (https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/)—and more to do with how one-sided the public discussion has been. Beneath the surface of this story are the consequences of a decade-old conflict that was never fully resolved. Then and now, one side—Andre Arko (https://arko.net) and many people associated with him—has availed itself of public channels to voice their perspective, while the other—which includes a surprisingly wide swath of well-known Ruby and Rails contributors—has chosen to stay silent. The losers in this dynamic are the vast majority normal everyday Ruby developers, most of whom are operating on very little information and who understandably feel confused and concerned. People whose livelihood depends on the health of the Ruby ecosystem deserve more information than they're getting, especially now that its operational stability has come under threat. The future of that ecosystem is once again uncertain, but—just like last time—the outcome is being shaped by a history that's been kept from the public, widening the rift between its key decision-makers and the communities they serve. I don't have the answers to what's going on in 2025. A few details have been shared with me—details that would contradict fact-checks and timelines others have pieced together and published—but I can't pretend to have a clear picture of what actually happened, why no one is setting the record straight, or when we'll have clarity on what the future holds. All I can do is offer a little bit of context to explain why I'm dubious of the dominant narrative that has taken shape online. Namely, I don't believe this is a cut-and-dry case of altruistic open-source maintainers being persecuted by oppressive corporate interests. After you read this, perhaps your perspective will shift as well. ## The relevant proper nouns to know (https://justin.searls.co/posts/why-im-not-rushing-to-take-sides-in-the-rubygems-fiasco/#the-relevant-proper-nouns-to-know) Before anything else can make sense, it's important to understand how weird the governance of the Ruby ecosystem is. There are three moving parts involved that are ostensibly managed by three different groups, but whose members have such broadly overlapping systems access that it has now led to disputes over who owns what: • Ruby itself , created by Matz and maintained by a large group of (mostly Japanese) committers, who host https://www.ruby-lang.org/, control the @ruby GitHub organization (https://github.com/ruby), and are supported by the Ruby Association (https://www.ruby.or.jp/en/) • RubyGems , specifically the gem and bundler CLI tools distributed with the Ruby language, which is hosted under @rubygems on GitHub (https://github.com/rubygems) • RubyGems.org , the website, API, and host (https://rubygems.org) from which gem dependencies are installed and which has been run by Ruby Central (https://rubycentral.org) for ages If Ruby were invented today, a single party would probably control all three of these things, but it took nearly fifteen years for today's status quo to take shape. Ruby was invented by someone in Japan in the 1990s. RubyGems was created at a conference in Texas (https://www.linuxjournal.com/article/8967) by a few Americans in the early 2000s. RubyGems.org only became the de facto canonical host for gems six years later (https://web.archive.org/web/20120220191344/http://update.gemcutter.org/2009/10/26/transition.html). My impression is that at no point was communication and coordination particularly fluent between the various parties. Adding to this, Bundler (https://bundler.io)—a meta tool for resolving the correct versions of all of a project's gem dependencies and which quickly became vital to nearly all Ruby application development—was created independently of the above players by Yehuda Katz and Carl Lerche. Andre Arko later became the lead maintainer of Bundler, and in 2015 he founded a 501(c)(6) nonprofit called Ruby Together. In 2019, Bundler was folded into RubyGems (https://github.com/rubygems/rubygems/releases/tag/v3.1.0). In 2022, Ruby Together was absorbed by Ruby Central (https://rubycentral.org/news/a-new-chapter-for-rubygems-how-ruby-central-is-building-a-sustainable-future/). Those last two events—the merging of Bundler and the unwinding of Ruby Together—came about after years of bitter conflict and simmering discord that I hope to shed some light on below. My direct involvement with any of these events was extremely minimal, but I had contemporaneous discussions with dozens of the principals involved. I never donated to Ruby Together and have never materially contributed to Bundler or RubyGems. That said, simply being made aware of several incidents as they were playing out in private was enough to leave behind a scar that has never fully healed. I can only imagine how others are feeling right now. Based on how badly things are playing out this time, it seems they were deeply impacted, too. ## The things people told me (https://justin.searls.co/posts/why-im-not-rushing-to-take-sides-in-the-rubygems-fiasco/#the-things-people-told-me) The earliest recollection I have of someone telling me about Andre Arko was in the summer of 2015, after getting dinner with a friend who happened to be a Ruby Together board member. The friend explained that Andre believed programmers working on open source tools deserve to earn an income that's commensurate with what salaried engineers earn at the companies who benefit from those tools. As such, Andre's goal with Ruby Together was characterized as an effort to fund development activities—initially his own, but eventually others—by paying themselves a market hourly rate. I remember being extremely sympathetic to this perspective, having also wasted countless hours of my life maintaining open source for free only for others to benefit from it. I also recall a figure like either $200 or $250 per hour being mentioned as the rate he was effectively paying himself. Whatever the rate actually was, I distinctly remember thinking, "holy shit, that's a lot higher than individual donors would probably assume." The first time I remember meeting Andre in person was at Ruby on Ales 2016 (https://www.rubyevents.org/events/ruby-on-ales-2016). I remember trying to make a good impression, because growing my network in the community was the primary reason I spoke at conferences. I was presenting with my beloved 12-inch MacBook (/posts/the-12-macbook-was-announced-10-years-ago/), which meant I was traveling with the first iteration of this cursed dongle (https://www.apple.com/shop/product/MW5M3AM/A/usb-c-digital-av-multiport-adapter). Andre needed an adapter, so I ran up to lend him mine. As he was giving it back, I recall him making a half-joking, flippant remark about either his dongle or his computer, saying that "Ruby Together will just buy me another one." It really rubbed me the wrong way. Over the years to follow, more than one person told me stories of Andre paying for shared meals on behalf of Ruby Together without an apparent legitimate justification. They told those stories, I assume, because the attitude he exhibited made them uncomfortable. If I had donated money to Ruby Together and heard the same stories, I would have been upset. For how little has been said about this publicly, a lot of different people told me a lot of concerning stories about Ruby Together over the years, often providing evidence to back it up. I'll do my best to stick to the highlights in this post. Hopefully they will explain why I have not joined the rush to defend the maintainers whose access was recently removed. What Ruby Central did was undoubtedly handled very poorly, but I don't think their bungling of its execution and communication alone is enough to answer the question of what should happen to the future custody and direction of Bundler, RubyGems, and RubyGems.org. ### 2015 (https://justin.searls.co/posts/why-im-not-rushing-to-take-sides-in-the-rubygems-fiasco/#2015) When Ruby Together first launched in 2015, the website suggested donations went to pay "our team" (https://web.archive.org/web/20150425040538/http://RubyTogether.org/), which initially linked to a list of the board members (https://github.com/rubytogether/rubytogether.org/blob/9a03c4c/app/views/home/team.html.erb) without any explanation of how the money was being allocated. This resulted in a nonzero number of donors believing they were funding the work of people like Steve Klabnik, Aaron Patterson, and Sarah Mei, when in fact only Andre was being paid at the time. Shortly after the wording was raised as misleading (https://news.ycombinator.com/item?id=9222549), the team page was updated (https://github.com/rubytogether/rubytogether.org/blob/0136e9f/app/views/home/team.html.erb) accordingly. In May of 2015, Andre suggested making support for older versions of Bundler contingent on Heroku paying Ruby Together (https://github.com/heroku/heroku-buildpack-ruby/pull/385/commits/6b3f3c71f4a98309e29748132be8e84b41d890de), which was interpreted as leveraging his control over Bundler as a pay-to-play scheme. Because Heroku (https://www.heroku.com) serves other people's Ruby apps—many of which aren't updated for very long stretches—the security of their service depends on clear and predictable support windows for Ruby's core technologies, it seems reasonable they would interpret this sudden revocation of support as a pressure tactic, aimed to solicit corporate sponsorship for Ruby Together. (Years later, Andre responded to a feature request from a Heroku engineer (https://github.com/rubygems/rubygems/issues/1811#issuecomment-270788204), which was interpreted at the time as indicating the feature would be withheld from Bundler because Heroku had failed to pay Ruby Together.) ### 2016 (https://justin.searls.co/posts/why-im-not-rushing-to-take-sides-in-the-rubygems-fiasco/#2016) The minutes of a December 2016 Ruby Together board meeting were leaked. The document acknowledged who was paying for the RubyGems.org service at the time: "Fastly is comping us something like $35k worth of CDN service per month. And that's on top of Ruby Central paying for $5k of servers and Ruby Together paying for about $15k of dev work every month." The use of "us" in that sentence suggests that Ruby Together was responsible for hosting RubyGems.org, which Ruby Central later went on to publicly dispute (https://blog.rubygems.org/2017/03/15/rubygems-funding.html). Additionally, one presumes the number of hours and rate paid for development work was determined by Ruby Together itself, rather than being a hard operational cost. Later in the document was a discussion of potential strategies to increase revenue after "new memberships [had] flatlined." Several ideas were discussed, culminating in a proposal to rate-limit access to RubyGems.org as the apparent best option: Rate limiting RubyGems.org seems like the option that scales most linearly with our costs. Companies that cost us money need to pay more (or stop costing us money), and companies that don't cost us money can continue to have a free ride. To be clear, this would not mean cutting off anyone's access to RubyGems.org. I'm imagining that it would work something like GitHub's model: anonymous access has a low limit, registered accounts have a higher limit, and even higher limits are available at each Ruby Together membership level. There are a lot of implementation details that would need to be worked out, but in general I feel like this is probably the most effective option to make companies feel like they are paying money for something they use and that covers our costs well. The leaked minutes were widely circulated in private at the time, due largely to outrage over the document's presupposition that Ruby Together was paying to host RubyGems.org (citing "our costs" as scaling with usage), as opposed to paying for developer effort (the costs of which do not scale with usage). The leak left myself and others worried that Andre might leverage his systems access to effectively hold the Ruby ecosystem hostage for the financial benefit of Ruby Together and—since it was compensating his own development efforts—Andre himself. ### 2017 (https://justin.searls.co/posts/why-im-not-rushing-to-take-sides-in-the-rubygems-fiasco/#2017) In January 2017, Andre added a "post-install message" imploring users to fund Ruby Together (https://github.com/rubygems/bundler/pull/5308/commits/072f9ab80bb1e2d4992962e59b42d479ac37a4c0), which would be displayed every time anyone installed Bundler. Unlike the aforementioned board meeting, this happened in the open and triggered an immediate backlash before eventually being rolled back. In one comment, Andre defended the action and pointed to Shopify's failure to pay Ruby Together (https://github.com/rubygems/bundler/issues/5311#issuecomment-271477520), publicly conflating Ruby Together's sponsorship of development effort with "~$40k/mo worth of servers." But, as Ruby Together's own board minutes from the month prior directly stated, money sent to Ruby Together wasn't going to pay server expenses—server costs were covered by Fastly (https://www.fastly.com) and Ruby Central. In February 2017, following protracted discussion of the post-install message and the threat of rate-limiting access to gem installs, I agreed to put my name on a letter alongside 18 others (including one of Bundler's creators). The letter requested Ruby Together stop misleading the community in this way. My understanding is that some private one-on-one communication followed, that none of it was particularly productive, and that no formal communication occurred between the two groups afterward. In March 2017, Ruby Central went on the record, attempting to clear up confusion and reassure users that https://blog.rubygems.org/2017/03/15/rubygems-funding.html, stating that Ruby Together donations were immaterial to its continued operation: Unfortunately, this past year has also given rise to some misunderstandings about this relationship in some quarters: chiefly, that by donating to Ruby Together, companies were paying for the operations of RubyGems. And in turn, that if enough companies didn't donate to Ruby Together, RubyGems would subsequently be in a perilous situation. This isn't so. No one in the Ruby community should worry about the availability or security of RubyGems being connected in any way to the fundraising of Ruby Together. Funds raised by Ruby Together go primarily towards paying developers to add features and fix bugs. Ruby Central, on the other hand, is wholly responsible for the operations and baseline stability of the system. While these two efforts go hand-in-hand, it's vitally important to understand that they are two different things. Ruby Together's requests for donations do not mean that there is any reason for concern about RubyGems' continued existence or operation. Later, in August 2017, Andre accused Google Cloud Platform (https://github.com/GoogleCloudPlatform/google-cloud-gemserver/issues/36) of wholesale copying gemstash (https://github.com/rubygems/gemstash)'s codebase, going so far as to threaten legal action in his opening message. He juxtaposed the accusation with the complaint that Google had, "repeatedly declined to support Ruby Together." The incident appeared to fit a pattern of behavior to pair high-conflict messaging with an admonition of the target's failure to fund the organization that paid him. Ultimately, Andre's claim turned out to be factually baseless—Google hadn't copied gemstash's code, after all (https://github.com/GoogleCloudPlatform/google-cloud-gemserver/issues/36#issuecomment-324503159). ### 2018–2024 (https://justin.searls.co/posts/why-im-not-rushing-to-take-sides-in-the-rubygems-fiasco/#20182024) Things quieted down and I didn't hear much about any of this stuff anymore. Eventually, Bundler became part of RubyGems and many folks from Ruby Together migrated to analogous roles at Ruby Central. ### 2025 (https://justin.searls.co/posts/why-im-not-rushing-to-take-sides-in-the-rubygems-fiasco/#2025) In August 2025, and seemingly out of nowhere, someone pointed me to the project spinel-coop/rv-ruby (https://github.com/spinel-coop/rv-ruby), an apparent fork of homebrew/homebrew-portable-ruby (https://github.com/homebrew/homebrew-portable-ruby). I say "apparent", because rather than using GitHub's fork button (https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)—which would have maintained clear attribution of who created the upstream project—it looks like it was instead cloned and re-pushed by Andre. Specifically, I was sent this commit replacing references to Homebrew (https://github.com/spinel-coop/rv-ruby/commit/2234bdb7db4e41bfe883a01f06d7d0aff3188997) from late July. As evidence of Homebrew's authorship was being erased and obscured, no additional acknowledgement was added to credit Homebrew for having created and maintained Portable Ruby since 2016. It immediately reminded me of Andre's baseless accusation against Google (https://github.com/GoogleCloudPlatform/google-cloud-gemserver/issues/36). "Not only did you not credit the Gemstash project in any way," Andre wrote, "from an ethical standpoint, this is also super gross." His blatant copying of Portable Ruby (a project significant enough that the lead maintainer gave a talk about how they did it (https://rubykaigi.org/2019/presentations/MikeMcQuaid.html)) struck me as brazenly hypocritical, given Andre's previous litigious and mistaken accusation against Google. In fairness to Andre, the rv-ruby repo continues to retain a copy of (https://github.com/spinel-coop/rv-ruby/blob/main/LICENSE.txt) Homebrew's LICENSE.txt (https://github.com/homebrew/homebrew-portable-ruby/blob/HEAD/LICENSE.txt) which names "Homebrew contributors" as the copyright holder. Andre also later added an explicit acknowledgement to the README (https://github.com/spinel-coop/rv-ruby/commit/76e96c9d9f74ea89eed9d34ff11491bb6c365d54), but that attribution came more than a month later, and (I'm told) only after he was directly asked to credit the original project. Andre wrote this week (https://andre.arko.net/2025/09/25/bundler-belongs-to-the-ruby-community/) that, "Ruby Together did not ever, at any point, demand any form of governance or control over the existing open source projects. Maintainers did their thing in the RubyGems and Bundler GitHub orgs, while Ruby Together staff and board members did their thing in the rubytogether GitHub org." However, while he was leading Ruby Together, he moved to restrict committer access to RubyGems in rubygems/rubygems (https://github.com/rubygems/rubygems/pull/1518), unilaterally erased the original authorship from Bundler's gemspec in bundler/bundler (https://github.com/bundler/bundler/commit/524add155d6b90c679db21b03f0bd9f877f21ab0), and oversaw a number of contributors being removed from bundler/bundler-site (https://github.com/bundler/bundler-site/commit/03d331ac8a0a05a5b4225319fb3783a8d1eb1c9b#diff-efb5113d13615a3e1c5706cd6f316ee73f5db628f8c5c06b450a51e537cf9ec6) in a redesign of Bundler's website. As a result of this broader historical context and in spite of the serious claims and grave implications being thrown around this month, I'm trying my best not to rush to judgment about who's at fault in the current conflict and would urge others to do the same. The future of the Ruby ecosystem may depend on it.

justin.searls.co