We appreciate the community’s patience and grace as we briefly paused our regular cadence of weekly updates. Out of respect for last week’s announcement from Matz and its importance to the community, we held this Q&A until today. For this week’s update, we’re sharing a collection of all the questions that have been presented to Ruby Central over the past several weeks. To respect privacy and consent, we are not attributing where individual questions originated, but in the spirit of transparency and equitable communication, we are including them all here. 

Many of the questions we received overlapped or touched on similar themes, so we’ve organized them into groups. This makes it easier to provide clear, thorough answers and ensures every question is acknowledged and addressed.

We’ve shared a link to our asynchronous Q&A form with each update, though we’ve heard that it’s not always easy to find. Starting this week, the form link will appear prominently at the top of every update. 

While we also gathered questions that community members posted in other public forums and repositories, moving forward we’ll respond only to those submitted through this official form using this link. This ensures that every question is received, reviewed, and answered and no question is overlooked or mistaken as ignored. We also continue to hear your requests for a live conversation. We’re working toward that and will announce opportunities to connect with us live before the end of the month.

Since many of the questions we received were submitted several weeks ago, some of the information has already been addressed through prior updates and ongoing work. We felt this was the right moment to also hear directly from leadership. Shan Cureton, Executive Director of Ruby Central, joins Errol Schmidt on the Technology for Humans podcast today, where she’ll address many of these questions and share what’s ahead for the community. We encourage everyone to tune in for additional context and to continue submitting questions through the Q&A form.

Link To Submit Questions

Communication and Community Engagement

  • Why are there delays in answering submitted questions?
  • Why hasn’t the next Q&A session been scheduled? Isn’t this just a simple Zoom call?
  • Why is the lack of engagement causing so much frustration?
  • When will the community Q&A happen? Why hasn’t it been held yet?
  • Will you publish all collected questions and responses?

We understand why the delays in answering questions and the lack of a live conversation have been frustrating. That frustration is real, and it reflects a gap between when actions were taken internally and when the community heard about them. Those delays were not intentional, but they did create a sense of distance between Ruby Central and the community at a critical moment.

The slower pace was due to several factors. First, we made the decision to prioritize accuracy over speed, which meant verifying each answer carefully before publishing. Second, some of the questions touch on legal, personnel, or security matters that require additional review before we can respond publicly. Third, we needed to build a structured process for collecting, reviewing, and publishing questions consistently rather than responding in fragmented or inconsistent ways.

Moving forward, we are committing to a more predictable and visible communication cadence. All collected questions will continue to be grouped by theme and shared in weekly Source of Truth updates so that everyone receives the same verified information. The Q&A submission form is now linked at the top of every update to make it easier for the community to find and use. We are also planning a live Q&A session before the end of the month, once we can ensure accurate and consistent answers are ready for discussion.

We can’t undo the delays, but we can fix the structure behind them. Rebuilding trust means showing up consistently, communicating clearly, and creating more direct ways for the community to engage.

Stewardship and Rebuilding Trust

  • What’s next for rebuilding trust with the community?
  • Why should the community trust Ruby Central now? 
  • How will you repair the damage to Ruby’s reputation?
  • What lessons has Ruby Central learned?
  • Why should the community believe Ruby Central is a good steward?
  • How did we end up here? Who is responsible, and how will you ensure better actions and communication in the future?

Responsibility for what happened rests with Ruby Central as an organization. We acknowledge that gaps in governance, access management, and communication contributed to confusion and frustration across the community. We’ve learned from this, and we’ve made changes.

Stewardship is demonstrated through transparency, open contribution pathways, and responsible management of shared infrastructure.

Ruby Central’s role is to protect the infrastructure that powers the Ruby ecosystem. We aim to rebuild trust with the community by acting transparently, strengthening governance, and inviting collaboration. We’ve implemented stronger controls, released a full incident report, and are engaging openly to rebuild confidence through consistency.

Timelines and Decision Context

  • What was the “funding deadline” referenced in earlier posts? Was it issued by a sponsor?
  • What was the “timeline” that drove the access changes?
  • Were sponsors behind these decisions? Are there NDAs or funding conditions tied to compliance deadlines?
  • Why did you act when you did? Were there real deadlines?

The recent access changes were shaped by ongoing security improvements and a  broader governance review that began earlier in the year. 

The departure of key individuals from Ruby Central meant that their access to code and production systems were no longer protected by contractor or employment agreements. As part of the standard off-boarding process in any professional organization, we started a review of our internal systems that were under the control of key individuals and set an internal timeline for when control should revert back to Ruby Central. We did this in reflection of our organization’s responsibility for providing a secure and sustainable supply-chain for the Ruby community.

The Board acted independently in their decision based on the internal timeline that was set; there was no sponsor-imposed funding deadline. Ruby Central maintains standard sponsorship agreements that do not grant operational control or impose conditions on governance. As such, sponsors were only briefed as part of normal communication and were not involved in any decisions or deadlines. 

We acknowledge that our public communication lagged behind internal actions, which understandably caused concern. Going forward, we’re improving how and when we communicate security and governance changes so the community receives timely, verified information.

Board Governance and Transparency

  • Why isn’t the board elected by a polling or voting process?
  • Will minutes from Ruby Central Board meetings be made available to the community? If no, why not?
  • If Ruby Together once published minutes showing ownership of the RubyGems client, can we see current Ruby Central board minutes from when repository changes were made?

Ruby Central is a nonprofit governed by a board as outlined in bylaws. Board member applications are open to the whole community and members are chosen from the candidates for their governance, fiduciary, and operational expertise to meet legal and organizational obligations.

Ruby Central’s Board has never published its meeting minutes publicly. As a nonprofit, our governance policy does not include public release of minutes from regular or special sessions, which often involve legal, contractual, or personnel matters. Instead, we provide transparency through published reports and community updates which offer a verified account of the Board’s actions and decisions relevant to this event.

Maintainers and Project Roles

  • Who will maintain RubyGems and Bundler going forward? Are they the same people who operate RubyGems.org?
  • What is the status of maintainers who lost access? Will commit rights be restored? Will a list of maintainers be published?
  • Who are the new maintainers mentioned in the October update? Will you publish a full list?

Maintenance will remain a collaboration between community contributors and vetted operators. Ruby Central oversees the infrastructure, and the security and sustainability of the open-source clients. Contributors from the community continue to work on Bundler and RubyGems codebases under open governance and contributor agreements, including both contracted and grant funded maintenance and voluntary community contributions. We are finalizing operator and contributor agreements that clearly define responsibilities and access to infrastructure and repositories. Several maintainers have already been engaged under these agreements. A current list of maintainers will be published once agreements are fully executed and reviewed for privacy and security compliance.

Sponsorship and Community Support 

  • What is the official relationship between Ruby Central and corporate sponsors financially?
  • What is the official relationship between Ruby Central and Shopify? Are there signed agreements? How much money is involved?
  • How many individual and corporate sponsors currently support Ruby Central?
  • Has Ruby Central engaged with other long-time corporate contributors like Stripe, GitHub, 37signals, or Airbnb?
  • What’s the relationship between Ruby Central and Shopify?
  • How are other companies like Stripe or GitHub involved?
  • Why has Ruby Central not been completely transparent about funding sources, spending, and sponsor relationships?
  • Do corporate sponsors impose explicit or implicit expectations on Ruby Central?
  • Did a sponsor ask for a specific maintainer to be removed?
  • Will you publish all sponsor communications?

As a 501(c)(3) nonprofit, Ruby Central reports funding and expenditures annually through public IRS filings. Corporate sponsorships help offset the costs of the services and educational content we deliver, but carry no governance authority or conditions. Our sponsors do not direct or approve decisions related to operations, governance, programming or personnel. None of Ruby Central’s sponsorship agreements confer any form of operational control or governance authority over staffing, events and event content (other than specifically designated sponsor talks and booths), or technical projects.

Ruby Central regularly engages with many companies that depend on Ruby infrastructure. We discuss shared goals for ecosystem stability and how they can help sustain the shared infrastructure managed by our organization, through sponsorship, engineering contributions, or in-kind support. These relationships are collaborative, not directive, and our conversations focus on partnership, not control.

We are finalizing our 2025 fiscal-year reporting and will publish a summary of contributors, grouped by tier, in our annual report and on IRS Form 990. We continue to expand both unrestricted community and corporate partnerships as well as grant funding to ensure sustainability.

Shopify is a corporate sponsor that supports Ruby Central’s mission through standard funding agreements. Ruby Shield, our partnership with Shopify started 3 years ago and was announced very publicly here: https://rubycentral.org/news/ruby-shield/  As shared in that announcement, Shopify has committed $1 million USD over four years to strengthen supply-chain security for the Ruby ecosystem. As with our other sponsors, our agreement with Shopify does not grant them any operational control, governance authority, or conditions on program content or personnel.

We will continue to improve clarity by summarizing sponsorship categories and board-approved budgets in our annual report.

Repository Stewardship and Ownership 

  • What is Ruby Central’s claim of ownership over RubyGems and Bundler? Does it extend to the code itself?
  • Is Ruby Central planning to own the Ruby language?
  • Does Ruby Central own RubyGems and Bundler? What’s the chain of custody?
  • Could Ruby Central secure RubyGems.org without asserting ownership of the projects?
  • What is the basis for Ruby Central’s claim of operational responsibility?
  • Did Ruby Central “take control” of RubyGems and Bundler?

RubyGems and Bundler have been managed by Ruby Central, as stated in their repository READMEs, since the merger with Ruby Together. Ruby Central has authority over the code and the gems commensurate with this management responsibility and the responsibility for delivering a secure and sustainable supply chain for the whole Ruby community.

While the RubyGems.org service is deployed from rubygems/rubygems.org repository, it also needs at least 2 more private repositories in the same organization for infrastructure-as-code, and CDN deployments. Additionally, the deployment process has access controls gated on GitHub team membership in the same organization.

On the client tools side, while the repos could have been forked, as long as individuals could publish the gems from any source they want, no forked repository could have been the canonical and secure source of the tools.

In summary, there are many moving parts of the complete supply-chain under Ruby Central management and responsibility, and access changes were the least disruptive and the most secure way of taking action.

Supply Chain Security

  • Are additional projects planned to improve RubyGems supply-chain security?
  • What projects are planned to improve RubyGems supply-chain security?
  • Have supply chain attacks on RubyGems.org increased?

We have not observed a measurable rise in attacks to RubyGems.org, mostly due to our recent investments in strengthening security by introducing mandatory MFA for owners of popular gems, our implementation of trusted publishing and our long-standing defenses against dependency confusion, namesquatting and typo-squatting. However, industry-wide risks have grown significantly in our peer communities, which is why we’re implementing stronger controls, periodic audits, and multi-factor authentication for all privileged accounts.

We’re also expanding the Corporate Contributor Stewardship Program to strengthen maintenance and resilience. In addition, we have a strong roadmap of features we want to build for strengthening the whole Ruby supply-chain, details of which we will be announcing in the near future.

These upcoming projects include expanding trusted publishing coverage, improving automated detection and response capabilities, and formalizing periodic security audits and operator accountability measures. This work is part of a proactive security posture not a reaction to new incidents ensuring RubyGems remains a secure, resilient service at the center of the Ruby ecosystem.

Sustaining and expanding this work requires dedicated investment. Strengthening supply-chain security isn’t a one-time project, it’s an ongoing commitment to staffing, monitoring, and improvement. Ruby Central is currently hiring a Senior Security Engineer to focus on this work full-time and to help accelerate key initiatives. Additional funding will allow us to build the infrastructure, automation, and capacity needed to meet the scale of security challenges facing open-source ecosystems.

Code vs. Service: Roles and Responsibilities

  • Do you recognize the difference between the open-source RubyGems/Bundler projects and the RubyGems.org service?
  • Are you conflating commit rights for Bundler/RubyGems with production access to RubyGems.org?
  • Could Ruby Central secure RubyGems.org without asserting ownership of the projects?

We recognize that code contributions (Bundler and RubyGems) and production operations (RubyGems.org) are distinct. However, Ruby Central has management responsibilities for both the infrastructure, and the open-source client tools to ensure their security and sustainability.

Operating the service involves managing infrastructure, credentials, deployment pipelines, and other security controls that keep RubyGems.org stable and reliable for the entire Ruby ecosystem. These operational responsibilities are different from contributing to the code itself and cannot simply be replaced through a fork or code-only change.

Contributor agreements outline how people engage with the open-source projects, while operator agreements define who is entrusted with managing the live production environment. Both are essential to ensuring that the code remains open and collaborative while the service remains secure and stable.

Governance Structure and Technical Roles

  • Will Ruby Central separate technical and non-technical governance?
  • Will Ruby Central consider separating technical and non-technical governance?
  • When will Operator and Contributor Agreements be finalized?

Yes. Ruby Central is actively separating technical and non-technical governance to make roles, responsibilities, and decision-making processes clearer. Technical operations are managed through defined operator and contributor roles, while non-technical governance remains the responsibility of the Board of Directors.

Governance oversight resides with the Board, which holds fiduciary and legal responsibilities for the organization. Technical operations, including infrastructure management, security controls, and the stewardship of RubyGems.org, are handled by vetted operators and maintainers under documented policies, with technical expertise and guidance from the Open Source Committee.

Operator and Contributor Agreements formalize this separation. They define who has access to infrastructure, who contributes to the code, and how both groups are accountable to each other and to the community. Operator agreements are nearly complete, and contributor agreements will follow shortly after. Updates will continue to be shared through weekly Source of Truth posts.

This structure creates clearer accountability and ensures that technical decision-making is guided by operational expertise and community input, while broader organizational oversight remains with the Board.

Security Risk Response & Mitigation 

  • What was the actual risk discovered during the access review?
  • Have old AWS credentials and security audit findings been fixed?
  • What was the specific security risk involving a single individual with system control? Who was it? Has access been restored?

All historical credentials have been rotated and are MFA-protected. Every prior audit finding has been reviewed and remediated or scheduled for completion under independent verification.

For privacy and legal reasons, we do not identify individuals. The risk involved a concentration of control and unrotated credentials. Access has since been fully restructured under least-privilege and audit-logged accounts. MFA protects all systems.

In addition to remediating the immediate issue, we have strengthened our overall security posture. Access pathways have been narrowed, infrastructure roles have been formally documented, and responsibilities are now tied to clear agreements rather than individual trust. Regular security reviews, credential rotation schedules, and external verification are now part of our ongoing security practices.

These changes ensure that no single individual holds unilateral control over critical systems and that safeguards are in place to detect and prevent similar risks in the future.

RailsConf Keynotes

  • Was DHH’s RailsConf 2025 keynote pre-announced before the review process? Was it part of Shopify’s sponsorship agreement?
  • Why was DHH’s role or keynote mentioned so prominently? Was Shopify involved?
  • Was DHH’s RailsConf keynote pre-decided or linked to sponsorship?

Programming decisions for RailsConf are made by the volunteer co-chairs and program committee, with support from Ruby Central staff. Conversations to have DHH as a speaker began in early 2024, but the timing didn’t work out for that year. Those conversations resumed in 2025 and since it was the final RailsConf, it made sense to make it happen then. The invitation was not tied to any sponsorship agreements or external requirements, and was purely a programming decision by the co-chairs of the conferences.

Shopify, like other sponsors, has never played any role in keynote selection or conference programming decisions. Sponsors do not have governance or program authority. DHH’s keynote was highlighted the same way as other featured speakers, and any increased visibility came from community conversation around the event.

Additional Community Questions

What’s Ruby Central’s stance on external “fact-check” posts and independent investigations?

We respect the community’s right to question and verify. Our responsibility is to provide verified, source-based updates. You can look at our previous posts here:

Everyone is entitled to their own opinions, and everyone comes with their own perspectives based on the individual experiences we have. We welcome you to look at all sides. Our goal is to release concrete and verifiable information to the community as it comes together.

Is Ruby Central planning to own the Ruby language?

No. The Ruby language remains led by Matz and the Ruby Association in Japan. Ruby Central’s role is stewardship of supporting infrastructure and tools such as RubyGem.org, RubyGems, and Bundler. We work in partnership with the broader Ruby community to ensure that these systems remain secure, stable, and accessible, but we do not direct or govern the language itself.

Does Ruby Central plan to continue membership donations?

Yes. Individual contributions remain an important part of Ruby Central’s funding; in fact, we encourage a grassroots approach to funding open source and community programs. Donations help maintain RubyGems infrastructure, community events, and educational programs.

Membership contributions are a critical part of sustaining the ecosystem’s long-term health. They provide flexible funding that supports ongoing security investments, helps expand programs, and allows us to respond quickly to emerging needs without relying solely on large sponsors. Updated membership tiers will be announced alongside our next annual report, creating more ways for Rubyists to directly support this work.

Why did Ruby Central’s actions appear to remove an active maintainer “by mistake”?

Our rapid credential alignment unintentionally paused access for one active maintainer. That access has since been reviewed under the new agreement process. We’ve updated internal review protocols to mitigate against similar occurrences. These protocols now include a more deliberate verification step before access changes are finalized.

What happened with the cease-and-desist letter?

We have no further comment on this matter beyond what we stated in this update post.

What’s really going on here? What’s the context behind people saying Ruby Central “attacked” RubyGems?

The situation stems from necessary governance and security changes to align access controls with current policy. We placed a temporary hold on certain privileges while finalizing operator agreements and security reviews. No code changes or ownership “takeover” occurred; RubyGems.org remained fully operational throughout.

At the time, the parties closest to the situation had a limited view of all the facts. Because of that, they responded with the information they had, including the abrupt access changes and the limited communication from us at the time. This combination understandably created confusion and concern.

In reality, these actions were part of a broader security alignment effort to protect the infrastructure and reduce single points of failure. We’ve since improved how we communicate these changes so the intent and scope are clear before, not after, they happen.

Why did Ruby Central contact someone outside the organization about repository control?

Discussions about transferring the RubyGems and Bundler repositories under the Ruby Core team have been ongoing for several years. Over time, frequent leadership turnover at Ruby Central made it difficult to sustain the momentum needed to finalize that transition.

Our timeline was ultimately accelerated for two reasons. First, we needed to ensure that governance over these critical repositories was properly aligned with the Ruby language’s upstream leadership. Second, recent personnel changes made it essential to clarify roles and responsibilities in order to reduce operational risk and strengthen long-term stewardship.

The outreach to external parties was not an attempt to seize control or act unilaterally. It was the next step in finalizing a process that had been underway for years and ensuring the transition happened in a way that best serves the community and the long-term stability of Ruby’s infrastructure.

Is Ruby Central aware of community comparisons to other OSS governance conflicts like TWiki/FOSWiki?

We’re aware of the discussion but believe direct comparison isn’t accurate. Our goal has always been to secure and stabilize shared infrastructure, not to commercialize or restrict collaboration. We welcome constructive input to strengthen governance.

Ruby Central’s role is focused on responsible stewardship of infrastructure and tools that serve the entire Ruby ecosystem. The open-source projects remain open to contributors, and governance decisions are guided by transparency, community input, and operational security needs. We welcome constructive feedback to strengthen those governance processes even further.

Will Friday’s communication address projects from separated or continuing staff?

If such updates directly affect RubyGems infrastructure or governance, they’ll be included. Otherwise, we focus our Friday updates on verified operational and governance topics.

This was a collaborative effort from all of the Ruby Central Board and Staff.