RubyGems Fracture Incident Report

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

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 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:

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.

Two engineers, André Arko and Samuel Giddens, 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 ( indirect ), David Rodríguez ( deivid-rodriguez ), Ellen Dash ( duckinator ), Josef Šimánek ( simi ), Martin Emde ( martinemde ), and Samuel Giddins ( segiddins ). 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.

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:

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.

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 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.

Public work and funding require public accountability : The business of open source is not just doing the work, but making sure it’s done in a clear and appropriate way. That means more time and care need to be spent on drafting appropriate policies and communicating them internally and externally. It also means that foundations need to be fluent in engaging with their communities and communicating clearly.

Ultimately, neither project received funding (no grants or sponsors were found to directly hire for the project through Ruby Central), but the item was still in the foundation's technical roadmap of projects it was interested in.

“After sitting with the DHH news for a few days, I’m sorry to say that I’m not going to be able to attend RailsConf, and I am resigning from my advisory role at Ruby Central.

I plan to continue participating in and advising the RubyGems open source projects, but platforming DHH at RailsConf means I cannot continue as an official member or representative of Ruby Central. [...]”

André announced that he is leaving his paid, part-time advisory role with Ruby Central. The OSS Committee read this post as indicating he desired to cut all financial ties with Ruby Central. However, that was not the case. Andre did not leave his secondary on-call rotation, which is also a paid part-time position.

The Ruby Central OSS Committee is a group of volunteers who have oversight of Ruby Central's OSS budget, as proposed by the Ruby Central OSS Director, Marty Haught. At the time, the committee consisted of Gabi Stefanini, Mike Dalessio, and Ufuk Kayserilioglu (who was also a board member). These members have since moved on, and today the committee is composed of one member, Richard Schneeman, the author of this document.

In this meeting, they discussed balancing the maintenance budget given a sponsorship gap by eliminating secondary on-call, as well as onboarding a new contractor. They planned to use this new contractor to support initiatives that can bring in more revenue to fund OSS maintenance, as spelled out in the middle bullet.

This blog post tried to drum up additional funds and diversify sponsors:

“With roughly 110 supporters, we would be able to fully fund our annual goals for operations and maintenance. In addition to our other funding sources, such as corporate sponsors, this level of community funding would enable us to expand beyond maintenance and focus on new features and enhancements that will benefit developers and gem creators.”

There was no documentation on how to run the RubyGems.org service (a.k.a "runbooks”), so in addition to doing scoped work, the new contractor was also tasked with documenting their onboarding process. This also means there was no documentation on how to revoke someone's access or offboard them from the RubyGems.org service.

Ruby Central was not aware of RV or either Sam or André's participation in this new Co-Op at this time. When they learned of it, the structure seemed similar to RubyTogether, which was created in 2015 by André Arko and merged with Ruby Central in 2021. RubyTogether funded bundler and later RubyGems.org codebase maintenance and merged with Ruby Central in October 2021. In the merger, the Ruby Central OSS Director position was created, and André Arko became the first acting director.

While he was only paid part-time to work with Ruby Central, he had intimate knowledge of the foundation roadmap and knew Ruby Central was interested in undertaking a similar project. He did not tell anyone in Ruby Central this work until it launched later, on August 26, 2025.

The forecast from June 27, 2025 , included this pledge, meaning an already tight OSS budget got tighter. However, there was already a declared interest in reducing secondary on-call to slow the burn rate.

“André suggested a way that his consultancy could cover the cost of secondary on call by analyzing gem download access logs to provide usage data by companies. Here's a quick write-up of the proposal in this thread. [...]”

The proposal has André acting as a middleman between Ruby Central and a third party who would pay for the logs. It is unclear at that time who that third party was, how they would make money from the logs, or how much money those logs would be worth to them.

A OSS Committee member responds:

“[...] Do we really, truly need a secondary shift? I think I remember Marty saying that in that last few years, the secondary shift has never been escalated to. [...] It's not stated explicitly in André's message, but my understanding is that he will want to own any derived works based on the HTTP logs. If that's the case, then we need to make sure we're comfortable losing control of community PII in a way that may be unpleasantly surprising down the road. [...] Let's please make sure we're imagining the worst-case scenarios before going much further.”

The cost of secondary on-call is $48,000 USD annually.

August 26, 2025 18:26 UTC

“I'm back and catching up after my mountain trip. I'd love to hear any updates from the committee meeting.

So the other new thing is André's post RV . I saw this mentioned in two slack channels. I did not know of this until I read the post, which is disappointing. Looks like Sam is leaving to work on that. Both of which I learned through the post and not directly from either of them. I'd love your thoughts on how we should respond.

I had debated internally if we should make a public announcement Sam's departure. Does this push us more in a direction?

I was already planning on accelerating removing André but this seems to put that at a higher priority for when I'm back from Rails World. It would be easier if I had another 2 engineers to help with on call.”

This message is the first recorded artifact that mentions a desire to offboard André . The framing “accelerating removing” also shows that the intent came prior to this message and the RV announcement.

August 26, 2025 (follow-up)

“yes, agreed. we can add [a RubyGems contributor] to the rotation if [they are] ready for it, and i think we should accelerate the adoption of people from other companies that can do similar work (like [another contributor from a different company]).”

Another member responds:

“I'd cut Sam and André's ties with the organization as soon as possible, announce the departures, and wish them the best of luck on their endeavor.”

The conversation quickly turns to operations of the RubyGems.org service, where on-call staffing is a concern. Previously, Samuel Giddens was part of the rotation; with his departure, they would need time to find a replacement.

“To follow up on the on call, the team discussed how to handle on call with Sam's departure. We'll have André cover that in September. We're going to put together onboarding and improved documentation in September to train up several folks to be on call ready. [new consultant] and [another developer] has volunteered to be part of that group. I'm looking to get 3-4 total people per time zone block (emea, americas, apac) so we can have a sustainable rotation.”

At this point, the path to offboarding everyone cleanly was uncertain. The new consultant made progress on some runbook documentation, but still did not have server access.

At this time, Marty, as the Ruby Central OSS Director, did not have admin permissions on GitHub. Those permissions are held by Colby Swandale, Hiroshi Shibata, André Arko, Samuel Giddens, and Martin Emde. That means in order to offboard anyone, he needs to ask someone else to make a change.

There was a meeting at RailsWorld between Rails Core, including David Henimier Hanson (DHH), and Ruby Central representatives at the conference. I've interviewed five of the attendees independently. I believe the intent to offboard came from Marty, prior to this meeting on August 26th. Coordinating operators to take over on-call also started on August 26th.

I believe that if this meeting hadn't happened, some details may have changed, but the outcome would have been the same. However, not all present at the meeting would have known all of those pieces or come to the same conclusion.

Hiroshi was not at that meeting, but spoke to Marty at the conference. Marty did not request GitHub access at RailsWorld.

Overall, RV and André's involvement was a very popular "hallway track" topic, as it was released so recently. I had not yet joined Ruby Central, but I saw Marty, and I asked him RV at the conference. Marty confirmed that RV was not a Ruby Central project. He didn't any information regarding André's resignation from Ruby Central or access to RubyGems.org.

Both Colby and Deivid were paid part-time by Ruby Central. Colby is a paid part-time contractor who primarily works on the RubyGems.org service and codebase, while Deivid was the number one contributor to Bundler by commits. All of the self-described the maintainers have a financial relationship with Ruby Central in addition to their unpaid volunteer contributions.

Marty reported back to the committee:

“I have a quick update. Both Colby and David are not supportive of pushing André out on the OSS side of RubyGems without his consent. Removing André's access to the service does not seem to be an issue, so I'm proceeding with that planning.”

A committee member clarified on the "pushing out" framing:

“We are not "pushing André out on the OSS side of RubyGems". I think that framing is wrong. André can continue to be a maintainer of RubyGems/Bundler as an open source contributor/committer, I have no problems that. However, him having ownership of the organization and repos is not acceptable for the organization that is ultimately responsible for the security and reliability of those tools. In that sense, we are trying to make sure the repos have better homes in ruby and rubycentral orgs respectively. [September 10, 17:01 UTC out of order, but wanted to mention it in case people stopped reading too soon]

The risk of handling operations in a world where André and Samuel don't have access to our ops is a risk I am willing to take, considering we can bring in people like [contributor], [another contributor], etc, into the fold if/when necessary. IMO, it is more important to swiftly and publicly cut ties with the folks that have already committed (semi-)publicly that they want to have nothing to do with RC, than worry incidents.”

The link between GitHub access and production access is not enumerated. As Deivid Rodriguez does not operate the RubyGems.org service, he wouldn't have known the link between GitHub access controls and production server admin. Colby is more familiar with the service and would have known.

Another OSS Committee member responds:

“Now that you have already discussed with Colby & David [...], I can guarantee you that André & Samuel already know. You should expect and be prepared for retaliation, be it a blog post that might post or that they remove your access from the repos. [September 9, 2025].”

At this point, it was clear to the OSS Committee that even though André and Sam had "left Ruby Central," they did not want to reduce their permission levels. A sentiment that is consistent with most Ruby Open Source projects, where access is granted and rarely revoked. For example, still has the founders of GitHub as gem owners on it, even though they've not pushed a new release for a very long time. For a community library, access is usually considered a "reward" and "earned."

RubyGems.org and other package registries are faced with an increased surface area of supply chain attacks. An extremely public NPM supply chain attack happened at roughly the same time as these access changes were happening (September 15, 2025). While this attack was not known to Ruby Central when the first access change occurred, the attack vector is one they were worried : A targeted phishing campaign compromised a maintainer's access tokens. Ruby Central is actively engaged with openssf.org and specifically their Principles for Package Repository Security , and is currently working towards level 3 security maturity.

With that context, Ruby Central (OSS Committee and Director) desired an access model closer to that of a professional organization, like the one I work for at my day job. I hold admin rights of a repository that I maintain, but do not have admin rights over the whole organization. With this strategy, the foundation can audit access and fully own completing offboarding from the RubyGems.org service. This strategy was a change from how things previously worked under other directors. The OSS committee believed that reducing Sam and Andre's access levels (at all, even temporarily) would be perceived as a demotion that risks retaliation.

The timeline of access changes is below, but to understand them fully, you need to understand what a GitHub Business/Enterprise is.

Most GitHub repositories live under an organization. For example, github.com/zombocom/rack-timeout is the rack-timeout repository that lives in the zombocom organization. There is another hierarchical level that can contain many organizations, which is known as either a Business or an Enterprise. Most GitHub users aren't familiar with this level. I've been writing Ruby code since 2006, and I've never encountered it. It looks like this:

For the RubyGems GitHub Business/Enterprise, it holds a nearly empty bundler organization and the rubygems organization with many codebases:

The RubyGems Business/Enterprise account was created by Hiroshi Shibata, hsbt , who the then current admins on the RubyGems organization to admins on the enterprise.

Confusingly, GitHub has another product called "GitHub Enterprise," which is different; that's a product that allows you to run a self-hosted version of GitHub on your own infrastructure. When "Enterprise" is used, it is in the "Business" context. These changes will show up in access logs with a prefix of business .

In addition to these levels, organizations also have teams as a way to control permissions.

This section was reconstructed based on audit logs from the enterprise account . The ability to audit access logs was not previously available for the OSS Director and the OSS committee. This was resolved when Marty gained access to the enterprise/business account.

September 9, 2025 (continued)

September 10, 2:23:49 UTC by hsbt

September 10, 2025, 3:32:27 UTC by hsbt

André and Samuel were removed from the business, and their organization permissions were downgraded at the request of Ruby Central. Marty (OSS Director) was added to the business.

Hiroshi stated that Martin was granted this permission in 2023 by André, but he didn’t know why at the time. So, he reverted Martin’s Business/Enterprise owner status.

At this time, they could not transfer repositories outside of the organization, but they still had admin access to the RubyGems and Bundler repositories. They also still had the capacity to run RubyGems.org operations (such as deploying the service) through their team access.

Hiroshi believed that Deivid Rodriguez's access level was too low for the level of work he was performing, and increased his organization's access to admin.

This removal of indirect , segiddins , and martinemde was characterized externally as “a mistake,” but the only mistake was the timing, which was not properly communicated by Marty to Hiroshi.

“I’m reviewing account permissions for rubygems now. I’ve assigned enterprise and org owner roles to only Marty, Colby, Deivid and me. The repository admin roles remains unchanged. Please let me know if you encounter any problems.”

André asked why his permissions were downgraded in a DM, and Hiroshi shares:

“[...] Because you are [leaving] Ruby Central now. Owner can access billing and account control. I would like to align to minimum permission around that.”

“[...], Colby, David Rodriguez, and hsbt are the owners in RubyGems. hsbt, Colby, and me are the enterprise owners. Team access is still the same but with a quick check André only has member access in the places I've checked.”

Committee members asked for clarification on the commit status. Marty responds:

“Let's this tomorrow. Forcing André out is likely to cause the team to defect. Removing his administrative abilities less so. I can my thoughts on ways to keep him from blocking changes.”

That RFC creates an “owner” definition, described as “A person with enterprise or organization owner permissions on GitHub for RubyGems/Bundler projects,” which would mirror the GitHub enterprise/billing owner. The high-level idea was to leave permissions as they were, but create a voting mechanism for removing permissions outside of “inactivity.”

While they didn’t know all the specifics of what Ruby Central desired (when they first drafted the RFC), they knew it had something to do with limiting access and thought this document would afford them the ability to have an official way to ask for permission/access removal, such that the OSS Director wouldn't need it directly.

Ruby Central wanted to make access control finer-grained and split RubyGems.org production server access controls out from the rest of the repositories. The top suggestion within the OSS committee was to move bundler/rubygems into the github.com/ruby organization.

September 15, 2025, 8:59:39 UTC by hsbt

September 16, 2025, 1:51:29 UTC by hsbt at the request of Ruby Central

All access was returned to indirect , segiddins , and martinemde . Permissions for mghaught , the current OSS Director, and deivid-rodriguez gained on September 10, 2025, remained.

A meeting was scheduled.

Context not present in the meeting: André and Martin were former acting OSS Directors and had github.com/rubygems organization and enterprise controls at the time. Prior to that, it was held by Evan Phoenix on behalf of Ruby Central until February 28, 2025 when it was removed by André Arko. So, they are not opposed to “Ruby Central” or the OSS Director having that control; they are opposed to someone getting that control without their input or buy-in as current Business/Enterprise admins.

September 17, 2025 (cont.)

September 17, 2025 (cont.)

“This call is mind-boggling to me. The lines between open-source work and paid work are blurry as hell and we need to fix this ASAP. [...]”

On September 18th, there was a board meeting where an official decision was made on offboarding Sam and André. They decided to remove production access, including control of the github.com/rubygems organization, and their ability to commit. At the time, Ruby Central lacked legal agreements with all operators regarding their access to production servers and data.

It was thought that after offboarding efforts were finalized, they could work together to disentangle GitHub access. Ruby Central’s plan was to eventually present them with legal “operator agreements,” which would be enough to alleviate Ruby Central’s concerns and restore commit access. Followed by resolving proper homes for all repositories.

Internally in Ruby Central, the decision to remove commit access was met with dissension and debate. GitHub team access and Shipit access were explicitly talked in the September 18th board session, but the full implication of that access (that it effectively meant that GitHub access and production infrastructure access were connected) was not fully spelled out.

This would mean that those with prior knowledge of those systems believe everyone understood the full links between access changes to github.com/rubygems and the RubyGems.org server, while those who were new to the information wouldn’t have intuitively understood all of the connections. Some felt that this was clearly a line too far, and some argued that their concerns merited an extended loss of access.

Due to the lack of a prior documented onboarding or offboarding procedure (runbooks), there was uncertainty around the minimum acceptable access changes to remove all RubyGems.org production server access.

September 18, 2025, 17:56:19 UTC by mghaught

André and Sam are removed from the business again. From prior conversations, there was a worry that others would add their permissions back without warning, so while Martin is not being offboarded, his access is reduced. Deivid did not have business admin access prior to September 10th, and this change was an attempt to revert to that state.

When I came to Ruby Central, I was unfamiliar with the business/enterprise access level. So I did not know, as Marty didn't, that this action of removing a member here would remove them entirely. This total loss of access included all teams and repositories. This was a mistake. This action cannot be undone. Someone removed from a business must be invited back, and that person must accept.

While Ruby Central intended to remove commit access from André and Samuel temporarily, they did not intend to remove them completely from the business. Now, before any access can be given back, they need to be invited back to the org and accept. Their complete removal from the org was a mistake.

Further, Deivid was not supposed to have his access reduced below the September 10, 2025, levels. This was a mistake.

September 18, 2025 18:04 UTC

“After consultation with the OSS Committee and the Ruby Central board, we have removed your RubyGems.org production access, given your departure from Ruby Central. We’re also pausing the on call rotations while we work through this transition. Please send a prorated invoice for on call services.

I believe there are two remaining service accounts I never transferred, PagerDuty and HelpScout. I’d appreciate it if you’d transfer ownership to my email at your convenience.

I’m deeply grateful for all you’ve done for the RubyGems and our community. I will be meeting with the OSS Committee shortly so I can resolve any open conversations.”

Both emails contained a rationale for the access loss, but it was limited. Neither message acknowledged the GitHub access changes. Changes to commit access should have been listed along with the intention that those changes were intended to be temporary.

A strong concern from the start was that Ruby Central would lose developers beyond the two who were offboarded, due to a walkout. Rather than being direct and clear with actions and their motivations, Ruby Central tried to avoid the impression of conflict in hopes that others of the maintainers would not resign.

No other emails were prepared or sent to the other developers whose access was affected or their peers who still retained access. There were messages in Slack, but this communication was not pre-prepared.

September 18, 2025 18:47 UTC

“I'm terribly sorry the GitHub removal. I messed up, and I accidentally removed all org access instead of downgrading. This is temporary as I work to fix the permissions structure. Martin's been helping me with this.

I was forced by the board to take this action due to legal risk to Ruby Central. We're actively exploring how to move the specific repos (terraform, shipit, GitHub team control) out and adjust team control so that RubyGems, the code base, and GitHub organization can be controlled by least privilege by the agreed governance.

I'll follow up more on this and engage with the governance rfc in good faith.”

An email was sent apologizing for the mistake of removing developers from the GitHub organization. This apology was for the mechanics of the access removal, but not the intent.

Martin requested that Marty restore his permissions, and he would assist with restoring the rest. Marty inexplicably didn't see the controls he expected to invite someone to the github.com/rubygems organization. Martin was unable to identify the problem either. While being removed from a business/enterprise is inherited by the organization, being added as an admin is not. The issue was that he had to grant himself organization access, which he had not done.

September 18, 2025, 21:45 UTC

Colby was not directly involved in any of the GitHub removals and received the same communications as other team members. He was asked to help correct the accidental removal from the GitHub Business/Enterprise. Colby is in the AEST (Australia) time zone, so this was very early in his day (7:45 am). This request took some time to respond to.

September 18, 2025, 23:17:32 UTC taken by hsbt

A Ruby Central board and OSS Committee member, Ufuk, was granted enterprise and organization access. He was asked to assist with access changes. This occurred roughly five hours after the business.remove_member changes went into effect.

September 18, 2025, 23:19:49 UTC taken by mghaught

The permissions issue with the Enterprise/Business was diagnosed and resolved. With this change, Marty could send out invites to the organization. However, communication in this time period between business.remove_member , and now could be described as a conflict cycle where attempts to avoid conflict by one side have the opposite reaction and can perpetuate the cycle. While both sides some similar goals and objectives, the built-up tension, lack of trust, and unclear communications prevented closure or repair.

Various grievances around how things unfolded would be added. The talks for resolution were counterproductive, and they ultimately pushed both parties further apart.

From this point forward, communication or requests/attempts to “restore all access” are interpreted by Ruby Central as including production access and therefore as attempts to reverse off-boarding measures and effectively take control of the service. From the point of view of those removed, Ruby Central had just kicked them out for a second time; whether the specific mechanics involved were intended or not wasn’t important, or wasn’t even believable, given the earlier hiding of motivations.

September 18, 2025, 23:21:19 UTC taken by colby-swandale

Colby responded to Marty’s earlier message by inviting Martin back to the organization. He then requested more details from Marty and was asked to pause the task. Martin would have received the invitation at 4:21 pm (16:21) his local time.

September 18, 2025, 23:31:42 UTC taken by paracycle

These changes were based on the previously stated risk that someone would add offboarded members back unexpectedly. Other changes were made based on inactivity.

Ellen Dash, duckinator , lost admin access to repositories in the github.com/rubygems organization due to removal from rubygems/maintainers . In addition, four other members were removed from the rubygems/maintainers team with the most recent commits to the github.com/rubygems organization in 2022, 2021, 2018, and 2016 (due to inactivity).

Notably, Josef Šimánek, simi, retained rubygems/maintainers team membership at this time.

September 18, 2025 23:35:15 UTC by hsbt

September 18, 2025, 23:38:02 UTC by paracycle

The rubygems/rubygems-org-deployers team gates access to deploy RubyGems.org via Shipit. The rubygems/rubygems-org team gates access to the RubyGems.org admin panel. Users with admin access to that panel have significant capabilities such as: modifying owners on gems, blocking users, yanking gems, resetting credentials, managing feature flags, running arbitrary SQL queries, and running maintenance tasks.

All of these team-level access changes affected a total of fifteen developers, including duckinator . Aside from duckinator, who had been recently active in 2025, most changes were made due to inactivity. The remaining fourteen developers last contributed to github.com/rubygems in the year:

You can see a list of the github.com/rubygems organization members and their activity levels in Mike McQuaid’s post, RubyGems Contribution Data with Homebrew's Tooling (September 24, 2025).

September 19th, 2025 1:53:25 UTC by hsbt

While most access changes have been removal, the access of deivid-rodriguez has been consistently increased. However, removal from an organization cannot be reversed; you must re-invite them, and they must accept. Deivid was invited back again.

September 19, 2025, 5:01:10 UTC by hsbt

This included one bot and three developers who last contributed to the bundler site in 2023, 2020, and 2016.

September 19, 2025, 8:59:40 UTC by hsbt

This was the last organization removal via Ruby Central.

At this time, simi retained access, but the rest of the maintainers are no longer in the organization. None of those affected were contacted with an explanation of why the changes had been made.

The first public description of the incident is published by duckinator , though they did not yet name a concrete group or adopt the label the maintainers . At the time, Ruby Central had not delivered any description of the situation internally beyond those who played a part in it directly.

Ruby Central found itself in a similar situation to the September 10th, 2025, enterprise/business access changes, where they struggled to explain their motivations without discussing personnel matters. Later that day, Ruby Central would release a blog post that did not directly address the duckinator sequence of events laid out or the “takeover” claims.

A key point in the post said:

“In the near term we will temporarily hold administrative access to these projects [...].”

Ruby Central would be unable to return any of the administrative access (or any access) to the maintainers without their participation. At this time, there have been two invitations delivered, and one canceled, which leaves one outstanding ( deivid-rodriguez ). Zero invitations have been accepted. In addition, Ruby Central would not relinquish administrative access to the github.com/rubygems organization.

In this time period, there were public blog posts by many of the maintainers . There were limited and sporadic private communications. Like before, these conversations were unproductive at best, counterproductive at worst. Ruby Central would not be restoring access controls to their state prior to September 10th, and the maintainers would not accept anything less.

September 23, 2025, 20:28:03 UTC by simi

This removal of simi was self-imposed as a protest after continued talks proved to be unproductive. Prior to this time, none of his access had been changed by Ruby Central.

September 24, 2025 1:07:58 UTC by hsbt

Deivid indicated in Slack that he would not be accepting the invitation, so it was canceled. The sentiment inside of Ruby Central was that they had “walked away.” This was later validated by a conversation with one of the maintainers .

“just reflecting a bit, I’m a little surprised you didn’t know that we all walked out on [Ruby Central]. That’s the whole situation. This was “you f[...]d up that bad and you want us to come groveling back to you, no” [January 2, 2026]”.

As of September 24, two of the original community owners retained organization controls: hsbt and colby-swandale . Two added members, the Ruby Central Director of Open Source, mghaught, and a then Ruby Central Board member, paracycle , retained control on behalf of Ruby Central. None of the maintainers had membership in the github.com/rubygems organization nor any outstanding invitations.

Ufuk’s access was later passed to another board member when he left the Ruby Central board.

Some execution failures and mistakes are individual, but the purpose of having a foundation and having an institution is that it can rise above individual limitations and provide robust, fault-tolerant systems. Therefore, these are our mistakes, collectively. And collectively we'll learn from them, but only if we face what happened, what we meant to do, and where we fell short.

The hope is that by sharing this, we can provide some closure to the community and increase transparency. It's also been a time to reflect internally and understand deeper issues that led up to this situation. You've likely been witness to some effects of this process, even if they seem mundane or unrelated. We have been going through a period of structural change, and that process will continue. It will not happen overnight. We want to face this and learn from it. You're welcome to judge us by our actions, and we hope you keep calling us in and calling us out when we don't live up to expectations.