RubyGems Fracture Incident Report

By: Richard Schneeman

This document attempts to give closure to the Ruby community about the events that led to the incident, September 10-18, 2025, which I’ve named “RubyGems Fracture.”

Preamble

I joined Ruby Central’s Open Source Committee on October 22nd, 2025, after the GitHub access changes. I was adamant internally and externally from day one about performing a retrospective to try to wrap my head around the full, true picture of what happened and why.

In the pursuit of this task, I’ve spent 20+ hours interviewing and chasing up leads, easily quadrupling that time spent reviewing other artifacts such as chats and raw GitHub access logs. For any fact learned verbally, I’ve cross-referenced it with either another independent (important) account or hard evidence, such as a document or video, etc. This incident involved many people over a rather long time scale, and it was important to detangle how people perceived events from how they actually unfolded. The subject matter is deeply subjective, and multiple failed attempts at writing this doc came as a result of aiming for objectivity, for blameless representation. Therefore, those named in this report are:

• Full-time employees of Ruby Central
• Part-time consultants who were involved in access discussions
• Anyone who made an access change from September 10th-18th, 2025
• Those who have already been publicly identified in the discourse

Volunteer groups, including the Ruby Central Board and the Open Source Software (OSS) Committee, are listed, but their actions are represented as a group. Individual quotes from the OSS Committee are used without direct attribution when they represent a general consensus.

This document attempts to paint an accurate representation of what Ruby Central (staff and members, especially in the OSS Committee) experienced and did in the events leading up to and including GitHub access removal. It is not the only lens to view these events, and it’s not exhaustive, but the hope is that it will provide transparency and hopefully closure.

Summary

Two engineers, André Arko and Samuel Giddins, were working on RV together. Each announced that they were leaving Ruby Central. Ruby Central, in turn, wanted to cleanly offboard them and sever ties with RubyGems.org production access, which was tightly coupled to GitHub access. However, Ruby Central lacked the structural ability to make this change directly (did not have admin controls on the GitHub Business/Enterprise). The resulting process was drawn out and poorly communicated internally and to the general public.

This led to the GitHub access changes between September 10th-18th, 2025, that resulted in the walkout of paid contributors: André Arko, David Rodríguez, Ellen Dash, Josef Šimánek, Martin Emde, and Samuel Giddins. A group that refers to itself as the maintainers.

This group asserted that they controlled administrative access to the github.com/rubygems organization via the Business/Enterprise permissions and that Ruby Central, the operator of the RubyGems.org service, does not have a right to those abilities or access. When Ruby Central's Open Source Director, Marty Haught, gained access to the GitHub Business/Enterprise and would not relinquish this control, they quit in protest.

Incident Lessons

Here are some of the lessons from the timeline below:

Policies and procedures are important: Runbooks and other operational documents, technical and non-technical, were neglected for a long time. Efforts to document and standardize these efforts began shortly before this incident in July/August 2025. At the time of the incident, there were no documented offboarding policies or checklists. There are now.

Many companies have an “Outside Business Activities” declaration process for full-time employees to formally let their employer know when they’re working with a foundation or pursuing an activity with compensation, such as writing a technical book. Ruby Central does not have a policy like this in place, but I’ve suggested we add one.

Distinguish remarks from requests: The initial access loss timing was accidental. This could have been prevented by clearly labeling requests for action.

Access changes should always come with explanations: When an access change event happens, the person affected should always know:

• What access was changed?
• Why?
• What can they do about it going forward? Is it permanent or temporary? Who can they talk to if they have questions or problems?

Ruby Central has reached out to some of the developers who were removed due to inactivity to let them know why. We will reach out to all of them.

Platforms with permissions management, such as GitHub and RubyGems.org, should consider adding an option for users to include messages when access changes occur.

Teams need to know why access is changing: Beyond letting the people affected know, those who work with them need to know. This is important not just for access removals but additions as well.

• Whose access changed?
• What is it now?
• Who should they talk to if they have questions or problems? It's not always appropriate to share specifics with everyone, but say as much as you can.

Impacts of access changes should be clear: Platforms with Role-Based Access Control (RBAC, such as team membership) and hierarchical access systems (such as a GitHub Business/Enterprise containing many Organizations) make it harder for the user making access changes to know the end result of their change. It is better to place the burden of understanding the impact on the system than on the user.

I suggest that these platforms consider adding the ability to preview the effect of access changes to reduce mistakes. A preview could help ensure that the Principle of Least Privilege (PoLP) is being followed without accidentally removing too much.

Perform sensitive operations "out loud": The Japanese have a concept translated to "pointing and calling" for avoiding and recognizing mistakes. This can be repurposed for many contexts, such as access changes.

An example could be announcing "I'm going to change access now" in a new Slack thread, then following up with how you plan on changing it (such as posting a screenshot, hovering over the new status) before actually making the change. This gives a log so the person can remember individual actions and when they were taken. This is useful even if the system has a log to separate intentions from actions. Done in front of others, it also gives them time to react if the planned action is not desired. It won't stop every mistake, but it will stop some and make doing a retro on others easier.

Decouple access from personal identity: Access changes in open source are especially emotional experiences. Beyond losing capabilities, access reduction can affect perceived credit for and earned positions. For example, removing ownership on RubyGems.org has the side effect of removing gem download metrics from a user’s profile page.

Platforms that couple metrics with permissions management should consider ways to extend attribution that are decoupled from direct access. For example, preserving gem downloads for “alumni” of package owners even after they’re removed.

Access shouldn't gatekeep contributions or getting paid: The way that the maintainers explained financial compensation came from early days of paid work on Bundler and Ruby Gems, where someone would make good contributions, be recognized with commit access, eventually promoted to “maintainer” status, and this would open the door for getting paid for maintenance or operations. The implication is that if commit access is taken away, it is perceived as removing both status and income. This pipeline also introduced an incentive problem where new members gaining status would be perceived as possible income competition.