Rubyists, thank you for your continued engagement and patience as we move forward together. The pace of questions has steadied, and the tone across the community has shifted towards progress. Ruby Central remains focused on stability and stewardship, not only in operations but in how we communicate and collaborate. Our commitment remains the same, to keep the infrastructure secure.
Since many of the earlier questions have now been addressed, we’re shifting to a more focused approach, answering a few questions each week over the next few weeks and then resuming our normal monthly newsletter cadence.
Organizational Updates
As we return to our steady communication cadence, we are sharing a few key updates across programs, partnerships, and upcoming events. These highlight our continued focus on strengthening operations, expanding capacity, and preparing for 2026.
- Newsletter Cadence - Our regular schedule will resume. The Friday updates will continue for the next few weeks and then be replaced by the normal monthly newsletter.
- Contributor Stewardship Program - We are welcoming new operators to help extend the capacity across our open source infrastructure. These contributors are crucial to strengthening continuity, distributing workload, and supporting ongoing improvements and maintenance.
- Sponsorships & Partnerships - Let’s Build the Future of Ruby! We’re excited to share our new Ruby Central Partnership Guide, designed for companies that want to make a lasting impact in the Ruby community. Whether through events, open source, or educational programs, there are more ways than ever to get involved
Interested in partnering with us? We’d love to explore what’s possible together. Please email tom@rubycentral.org for more information. - RubyConf 2026 - In the coming weeks, we’ll be announcing the location for RubyConf, along with all the exciting details. Stay tuned for the official reveal!
Open Source Updates
On-Call: We’ve extended our primary and secondary on call rotations to six engineers. This forms our core group of operators to manage the service 24/7. All of these operators have signed our new operator agreements or have joined through our Contributor Stewardship Program. During this time, we’ve created new onboarding documentation and runbooks for the Rubygems.org service.
AWS Outage: RubyGems.org was not affected by the recent AWS outages. Our status page host, Statuspage, was temporarily affected by the outage.
Sigstore: On October 10th, the sigstore-ruby client fell behind in its support of Sigstore's production servers, resulting in all attestations failing. We addressed the issue by contributing pull requests to the upstream sigstore Ruby library, resulting in a new release of sigstore-ruby and full restoration of trusted publishing functionality.
What's next:
- Work continues to enhance our disaster recovery procedures
- We're continuing to document our services, runbooks
- Expand our on-call team beyond 6 engineers to bolster our EMEA and APAC coverage
Asynchronous Q&A
We know trust is tested by unanswered questions. We’re continuing with an asynchronous Q&A so everyone can participate and read the same answers, regardless of time zone. We may group questions by theme, publish them on a set cadence, and keep answers concise and fact-based.
Question 1: What legal and governance challenges led to the new structure, and how does it address them?Perhaps rubygems isn’t a small group of volunteers with small risk, anymore, it could be seen as a critical piece of infrastructure for the globe, and so the old admin practices don’t match the new world? Are there things that NPM and PyPI have struggled with that the new RubyGems governance solves? Do you foresee other language packaging ecosystems making similar moves?
A: The more general question raised here is better answered independently in an impartial context by the Open Source Security Foundation: https://openssf.org/blog/2025/09/23/open-infrastructure-is-not-free-a-joint-statement-on-sustainable-stewardship/
While we are members of OpenSSF, we missed the opportunity to be a signatory on the joint statement.
Nevertheless, we support it both generally and as it applies here.
Question 2: In your update on Oct 24, you stated: “Shopify, like other sponsors, has never played any role in keynote selection or conference programming decisions. Sponsors do not have governance or program authority.” Can you please confirm who the conference chairs were for RailsConf, and who they are employed by? Can you also further confirm their relationship with RubyCentral otherwise. My understanding is that there were two co-chairs, one who is the founder of GoRails, and the other is a Shopify employee. The latter is also a board member of Ruby Central. Is this accurate? If so, what measures have been taken to ensure that decision making is genuinely independent? The reason for this question is because it is fairly hard to believe that there isn’t some level of bias inherent in this choice given that the program committee was not given input, and the speaker is a member of Shopify’s board, and the moderator a Shopify employee. Is there a reason why you did not at least disclose these affiliations in your reply?
A: Hi, Ufuk Kayserilioglu here, the Ruby Central board member who was the co-chair of RailsConf (both 2024, and 2025) that you seem to be asking about. I’ll try to answer this question personally.
I am a Shopify employee, but my Ruby Central board role has nothing to do with my employment at Shopify; it is my personal engagement that is neither directed nor guided by Shopify. I joined the Ruby Central board in December 2023, and the first role assigned to me as a new board member was to co-chair RailsConf 2024. After accepting the assignment, I made 2 requests to the board. First, I asked the board for permission to seek a community co-chair to help organize RailsConf 2024 and the board approved. This was important, since it was the first time Ruby Central ever had an outside community member have any role in the decision making for our conferences. Program chairs of Ruby Central conferences have complete authority in setting the theme and the program for the conference without needing board approval, so this was an important step towards community engagement for the organization. Since then, we’ve continued to use that model, seen it work really well, and have decided to continue using it for all of our conferences going forward.
The second thing I asked the board to vote on was permission to reach out to DHH to get him on the RailsConf 2024 program, which the board approved. My goal was to find a way to get DHH back to speak at RailsConf, and my co-chair was also on-board with that decision. Back in February 2024, when we did the initial reach out, DHH had no relationship with Shopify, and our decision, as conference chairs, to reach out to him had nothing to do with Shopify either. He actually joined Shopify's board much later, in Nov 2024. Ultimately, there was too little time left until RailsConf 2024 to arrange an appearance, so we deferred the conversation to RailsConf 2025.
I volunteered to co-chair the 2025 RailsConf as well, and found a community co-chair with whom we formed the program committee, and restarted the conversation with DHH about an appearance at the conference. At the kick-off meeting of the program committee, as first order of business, I made sure to let the committee members know that DHH might be one of the keynote speakers and that if that was going to be a point of concern with anyone that they could choose to decline their program committee role. There were no objections or concerns raised by any of the committee members and none of the program committee members decided to leave at that point or at any point afterwards. The committee, as a group, ultimately selected all the talks, the workshops and three of the five keynote speakers that formed the conference program.
Given this timeline, I hope it is clear that the program, theme and keynote selection have been done by the co-chairs in a fair and independent manner, with multiple points of community engagement, and soliciting opinions and approvals from multiple parties when and as appropriate. As we have made it clear over and over again, Ruby Central does not take direction from any sponsor, nor allow any sponsor to influence the program which is planned and decided independently by the group of community volunteers on the program committee.
We didn’t feel the need to disclose any company affiliations in our original response, since those affiliations are already a matter of public knowledge given that our board members and conference co-chairs are publicly shared on the relevant websites. For example, the program chairs of both the 2024 and 2025 RailsConf can be seen on their websites at https://2024.railsconf.org/about and https://railsconf.org/about. The same is true of our conference sponsors and the speakers at our conferences. The point that seems to be contentious in these questions though is one we can answer clearly: none of those affiliations have played any part in any programming decision in any of our conferences.
Closing and Next Steps
We will continue to respond to community questions. As we move forward, we’ll focus on ongoing transparency, consistent communication, and strengthening operations and collaboration.
We encourage you to submit your questions through our official form so we can continue to address them. Thank you again for your patience and being a part of this evolving and resilient community. We are looking forward to continuing to build, improve, and grow together.
This was a collaborative effort from all of the Ruby Central Board and Staff.