Dear Rubyists,

Thank you for giving me this opportunity to share with you. We take our stewardship of the Ruby Gems ecosystem seriously. Our mission is clear: keep the language and the infrastructure you rely on stable, safe, and trustworthy. Before we get to what the next steps will be, here is a quick recap from the video that we shared last week.

Moving parts:

  • We recognize there is confusion between some of the moving parts in this conversation, and we would like to add some clarity around that.
  • The rubygems client and bundler source code both live in the rubygems/rubygems Github monorepo 
  • Similarly, the source code for the rubygems.org service lives in the rubygems/rubygems.org Github repo
  • Lastly, the production rubygems.org service is run on AWS servers by Ruby Central operators.
  • These components are distinct but related, and work together to provide gems from developers to end-users. Ruby Central’s role is to ensure the whole platform runs securely and reliably end-to-end, from gem publishing to gem hosting and, eventually, to gem installation on end-user machines.
  • The rubygems repository README and the rubygems.org repository README both explicitly state that they are “managed by Ruby Central”

Where we are

  • We implemented a temporary, procedural change to privileged access to the rubygems/rubygems repository, to the rubygems/rubygems.org repository and to the production systems for the rubygems.org service. Why we did this and how long it lasts are outlined in the next section.
  • Publishing and installing gems continue as usual; on-call coverage and incident response remain active.
  • We are prioritizing the finalization of Operator Agreements for access to our Rubygems.org production systems as a priority, followed by Contributor Agreements for contributions to the open-source above-mentioned repositories, both on a firm timeline. The operator agreements are essential to define who can access production systems, under what conditions, and with what accountability. This prevents unilateral control over critical infrastructure and removes single points of failure. Similarly, contributor agreements will clarify how code is contributed, reviewed, and licensed, ensuring contributions remain open source, transparent, and aligned with Ruby Central’s mission.
  • We are also conducting a final review of credentials to ensure that no legacy access remains in the system.

Why we acted

  • Ruby Central is responsible for the security, maintenance, and availability of the RubyGems service, including the canonical clients, RubyGems and Bundler, which install and update gems. To meet that duty of care, privileged access and operational decisions must align under a single, accountable stewardship model from codebase to production.
  • Unlike open-source projects that are simply distributed “as-is” with no warranties, but similar to other infrastructure projects, these codebases underpin a service operated by Ruby Central, and its canonical clients, relied on by millions of developers every day to securely download and publish gems. 
  • A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems. We had intended to resolve this over time. However, the departure of key maintainers and contribution data showing that some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline.
  • During our review, we also saw potential privacy risks stemming from gaps in accountability. No signs of unauthorized access or PII exposure were found. At the same time, new privacy laws in multiple jurisdictions require Ruby Central to have agreements in place with operators that protect the personal information in its control. To comply with these obligations and maintain community trust, we moved quickly to strengthen security, increase auditability, and set clear responsibilities.

How we decided to address these gaps

  • For production access (live systems), we’ve put a short, procedural hold on top-level/admin permissions while we finalize operator agreements, enforce least-privilege + MFA, rotate keys, and verify audit logging. Service remains uninterrupted.
  • For code access (RubyGems/Bundler repo), community PRs continue as normal, while a small set of direct commit/owner rights are temporarily paused and are being re-granted as roles are confirmed.
  • We have set a clear deadline to complete this work within the next two weeks, so access can be restored in an orderly, transparent way.

What this is—and what it isn’t.

  • It is: Risk-reduction and accountability; signed operator and contributor agreements, MFA, audit logging, and periodic access reviews for privileged accounts.
  • It is not: This is not a takeover, a shutdown of contribution, or commentary on individuals. We accept responsibility for how our initial communications created the impression of sponsor-driven action. In practice, we focused first on contacting the team members directly affected and left our broader communication for business hours. Ultimately, we moved fast without providing enough advance detail, did not publish the rationale and timeline at the same time as the changes, and let routine sponsor briefings be conflated with direction. To rebuild trust, we’re sharing more detailed rationale and checkpoints (operator agreements executed, access restorations, audit verifications, uptime/MTTR), updating a public FAQ on a set cadence, and reiterating that Board decisions are independent and not contingent on funding.     
  • Additionally, we’d like to address a related concern we’ve heard from the community. Publishing a gem on the rubygems.org service does not mean that Ruby Central can “take” it from you. Ownership changes on rubygems.org are handled through the standard administrative procedures available to gem owners. Ruby Central has not unilaterally altered database records or reassigned ownership. In other words, ownership changes are initiated by gem owners in accordance with established procedures.

On Our Communication

We could have communicated earlier and in more detail. And we won’t stop apologizing  for the confusion that caused. We are improving cadence and clarity so you always know what’s changing, why, and when.

The Latest

  • In the last few weeks, partial or speculative information has spread quickly and caused concern. We recognize our obligation is to the entire Ruby Community and we appreciate your efforts to hold us to account. We ask for your patience as we respond to your concerns as quickly as we are able.  
  • In an open community, information and personnel updates move quickly. We speak regularly with current sponsors as part of routine briefings and potential sponsors regarding organizational support.  Their input is not instruction; their input did not direct our actions. The Board acted independently, and financial support was NOT conditioned on taking these steps.
  • We know that everyone wants to know about the status of the repos. An update will be out soon. I know this isn’t the best news. But that is all that can be shared at the moment. 
  • We will moderate official channels to keep discussion constructive and aligned with our Code of Conduct.
  • We’ll publish updates on a predictable schedule (weekly on Fridays).

We want to assure the community that we have our heads down and all hands have been on deck to resolve this in a way that will be the best for the community. This will take a little bit of time. There are a number of moving pieces we are trying to resolve and we know that our next steps are integral in improving your trust with Ruby Central.

How we will engage

  • Written FAQ + updates: Recurring posts that track decisions, timelines, and what’s next.
  • Async questions: A short form to collect questions between live sessions. We’ll publish responses on a regular cadence.
  • Security briefings for companies: If your security team needs details on controls and escalation paths, contact contact@rubycentral.org.

Our commitments

  • Mission first: Stability, safety, and trust for the RubyGems ecosystem.
  • Timely and accurate information: We’ll say what we know, what we’re doing, and what’s still in progress.
  • Transparency and consistency: One source of truth, mirrored to official channels.
  • Respectful dialogue: Strong opinions welcome; personal attacks and speculation are not.

We truly appreciate you for all of your concerns and for holding us to a high standard. 

With respect,

Shan Cureton

Executive Director, Ruby Central