Transcript
Hi everyone, my name is Shan Keratton, executive director here at Ruby Central. I'm speaking today on behalf of Ruby Central's board and our team. We had planned a live Q&A for tomorrow, Tuesday, September 23rd, but we heard your concerns about timing and access. We will announce a new date within the next few days. For those celebrating the Rashashana holiday, we wish you a blessed new year. Right now, we do want to share a full consistent update so everyone can get the same information and watch this back on their own time. At Ruby Central, our mission is to support and steward the Ruby ecosystem. That means keeping the tools and infrastructure that millions of developers rely on every day secure, stable, and sustainable. When Bundler and RubyGems came under our responsibility through the merger with Ruby together, it came with operational risk, legal responsibility, and practical obligations. Unfortunately, the merger left governance liability and operational gaps that we are now closing. First, an acknowledgement. Our communication could have been better, clearer, earlier, and more detailed sooner. We're so sorry for the confusion that all of this has caused. This message is meant to correct that, but with facts, timelines, and our next steps. In recent weeks, changes in project roles, responsibilities, and sponsor questions about supply chain risk made one thing clear. We needed to close governance and access gaps quickly. With the departure of a lead maintainer and a transition of security engineer, questions around administrative access to Ruby gems bundler and rubygeems.org became urgent. At the same time, sponsors and companies who depend on Ruby tooling came to us with supply chain concerns. We had already started these discussions with the current maintainers about how to strengthen the governance and access controls. We value their contributions deeply, but it became clear that we couldn't reach agreement on the steps needed to address security and liability concerns in the timeline that we were facing. So rather than leave critical infrastructure exposed, the Ruby Central board voted to temporarily remove certain administrative and commit privileges into agreements could be put in place. This decision was never meant to be permanent. It was about shoring up protections, buying us the time we needed to set agreements, and doing right by the community and the companies that depend on us. This is a procedural time box step to align access with the responsibility and accountability for a production service. This is about formalizing how privilege access works, signed operator agreements, MFA, audit logging, and periodic access reviews. This is not a shutdown of community contribution and it's not permanent. Normal publishing and installation continue. On call coverage remains in place. As Ruby Central's executive director, I've been tasked with getting the organization into truly sustainable shape. This means not only stabilizing how we operate as an organization, but also strengthening how we govern and maintain open source infrastructure. When we began reviewing our practices, it became clear that we needed stronger security pro protocols and clearer governance in Ruby Gems and Bundler. But it also clear that sustainability depends on improvements across the board. How we're managing operations internally and how we support the open source work that powers the ecosystem. These changes are not about limiting the collaboration. They're about making sure Ruby Central can fulfill its mission and remain a strong steward. Ruby Central for most of its history has been run almost entirely by volunteers and independent contractors. Only recently did we begin hiring staff and with that shift came new responsibilities creating professional professional protocols including offboarding processes and stronger security controls. This was actually the first time in Ruby Central's history that we had to offboard an employee working in open source. So removing administrative access to critical systems was not only appropriate, it was necessary. Currently, I do see incredible opportunities in front of Ruby Central. At Railscom earlier this year, I shared that just in a short period of time, I've met so many warm, generous people who love this language and this community. That spirit, it was what drew me here. I believe deeply that Ruby deserves a strong, sustainable home for its infrastructure and its people. My commitment is to help Ruby Central grow into that role, not just for today, but so that Ruby Central can thrive into the future. All of these changes are being made in good faith to ensure that we can continue the hard work on the behalf of the community. Our funding and sponsorships are directly tied to our ability to demonstrate strong operational standards. Without those standards in place, it becomes harder to secure the support needed to keep maintainers paid, organize events, and provide resources for developers at every stage of their journey. Strengthening governance and tightening operational practices are not just about risk mitigation. They're about making sure that Ruby Central remains sustainable and able to serve the Ruby community. So, what does this all mean? First, permissions are restricted only temporarily while we finalize those agreements. So, operator agreements will cover access to production systems like rubygeems.org for on call and maintenance responsibilities while the contributor agreements cover access to bundler and ruby gem code repositories defining responsibilities and expectation for those projects. These agreements will cover both the paid and the volunteer maintainers. Second, this is the first time Ruby Central has put these legally binding agreements in place for maintainers. And here's why. In most open- source projects where the code is a library or framework, you usually don't see formal operator agreements. People contribute under contributor license agreements, codes of conduct, or decisions made by a steering community. But rubygeems.org is different. It's not just code. It's a production service. It runs critical infrastructure for the Ruby ecosystem, processes billions of downloads, stores sensitive metadata, and is relied on by companies that have compliance requirements. Because it's a service, Ruby Central carries the legal liability, the financial exposure, and the operational risk. This is why operator agreements are necessary. They ensure access is tied to responsibility and accountability. While you may not see them in projects like Rails or React, they're the norm in services like npm, pi, or dockerhub. Rubygeems.org belongs in this category. I want to acknowledge that the way that the process played out felt very abrupt and we regret that. Our mission has always been about protecting the community, protecting the ecosystem, and building a stronger foundation for the future. So moving forward, I want to assure everyone that operations are covered by our on call rotation. Incident response and core maintenance continue as usual while we complete the governance and agreement work. Here is how access is being restored starting now. We're issuing those operator agreements to maintainers who support production operations. We're moving the repositories that are part of the services that we provide to a new dedicated GitHub organization. Once the agreements are signed and roles are confirmed, permissions are reenabled and we'll restore the permissions of the remaining repositories to their original owners. This week, we will announce a new date for the live Q&A session. So, please submit those questions in advance and you can do that at contact ruby central.org or you can post your questions in the community Slack and we will monitor and try to answer as many as possible. Within the next few weeks, we will start drafting those government governance documents. So, in closing, I just want to say that Ruby Central exists to steward this ecosystem responsibly. We're a small team of people. The board is mainly engineers working with Ruby in their day jobs and our small but mighty staff who work tirelessly to support this community. We are here because we care about Ruby and we care about you. everything we do with intention of sustaining and strengthening this ecosystem that we all love. Going forward, we are dedicated to making positive, intentional, and cautious changes in the face of risk, communicating those choices clearly and inviting constructive input. We thank you for your care for Ruby and for holding us to a high standard. We're committed to earning and keeping your trust. Thank you.