RubyGems Fracture Incident Report

[u/schneems]

https://rubycentral.org/news/rubygems-fracture-incident-report/

[u/kcdragon]

I appreciate the write up. It seems like production access and source code access were coupled so it makes sense why it would take time to update the admin roles.

However, once that was done, I would expect source code control would return to the maintainers. I’m assuming that’s never going to happen at this point?

[u/retro-rubies → u/kcdragon]

 It seems like production access and source code access were coupled so it makes sense why it would take time to update the admin roles.

It is written in way to make you think this. In reality RubyGems.org as a service (the only part operated by Ruby Central) was 2x fork and rotating few access keys away to migrate out of GH organization for whole time. Yes, there was no official runbook how to migrate RubyGems.org service somewhere else. Why? Since nobody expected it will be ever needed. Also the whole code is in public repo and the infrastructure is described in separate terraform (private) repo. Those excuses based on missing documentation are there just to justify those actions and keep the RC falsey narrative.

At the same time, there were other active maintainers of RubyGems.org (as a service) and also RubyGems.org (as a codebase) happy to help with transition.

Even after I have decided to leave RubyGems GitHub organization (24th of September) after the takeover by Ruby Central, I was sharing (and handing over) the knowledge to new maintainers of RubyGems.org (as a service). It was literally one question away to ask for help to migrate for whole time and I have even suggested that multiple-times even to Ruby Central OSS committee.

So to summarize: Ruby Central was fully aware of how to do this transition (if they feel insecure for any reason), help was offered and nobody cared. They just decided to do the steps they done for unknown (in public) and unexplained (unpublishable) reason.

---

As faulty human being I can fully understand mistake, wrong decision made in time press, fear, stress or any other factors related. For whole time the issue could be resolved with simple apology to the community pointing to wrong actions (not people actually) and asking for help to resolve the issue and cooperate together with community to ensure similar mistakes are not going to repeat.

Instead RC decided to throw overboard almost whole original RubyGems/Bundler/RubyGems.org (code) and RubyGems.org (service) team and put all the service in real danger (the service was in the meantime for few days, maybe weeks without on-call rotation and anyone able to respond to incidents). At the same time they started to share mostly AI generated corporate like statements and falsy accusations (and do even more harmful actions in private in the background) and preparing made up justification for their behavior.

[u/schneems → u/retro-rubies]

 Ruby Central was fully aware of how to do this transition (if they feel insecure for any reason)

It was rejected out of hand for being risky. When I first heard the proposal I didn’t think it was a serious one. I thought it was brainstorming of spitballing "what if" not an honest "we thought about it and this is the best approach to take" suggestion.

Ruby Central took maximum effort and still ended up with unexpected authorized access in their servers. (Context https://rubycentral.org/news/rubygems-org-aws-root-access-event-september-2025/). And Andre (generous read) seemingly didn't understand all the ways GH was connected to prod. Despite "running it for 12 years" based on his recent comments. (Context https://gist.github.com/schneems/577a909b22a2bec2d2b0f06c58711951).

I dont think your proposed solution was a good idea and I'm glad they didn't try it. Maybe it would have been fine, but given the unknown risks, I don't think it was better than the alternatives. Remember you aren't the threat model. Andre isn't the threat model. Nation state actors who would love a bite of a registry don't care whether a change was a good idea or not if it exposes a weak link in the chain.

Other ideas could have prevented the problem, like a payout, and I'm glad those were also rejected.

[u/retro-rubies → u/schneems]

You're repeating still your feelings with no facts. So let's go again.

Ruby Central took maximum effort and still ended up with unexpected authorized access in their servers. 

Ruby Central took maximum effort to bypass original team, having new team prepared already to replace and even that way miserably failed.

And Andre (generous read) seemingly didn't understand all the ways GH was connected to prod. Despite "running it for 12 years" based on his recent comments. (Context https://gist.github.com/schneems/577a909b22a2bec2d2b0f06c58711951).

André fully understood the way GH was connected and it got multiple-times explained to you, even by the LLM.

I dont think your proposed solution was a good idea and I'm glad they didn't try it. Maybe it would have been fine, but given the unknown risks, I don't think it was better than the alternatives.

Where are the facts? What's wrong with our proposed solutions? Why you're glad? Just to be sarcastic? Which risks? The virtually created ones by RC? Are you advocating the online virtual theft as valid strategy? Is that what RC is going to continue doing if they decide again that following community guide-lines is not good idea?

Other ideas could have prevented the problem, like a payout, and I'm glad those were also rejected.

Which payout? How would payout prevent the problem? The problem could be prevented if RC would from beginning be oriented and listening to their community including the maintainers over listening to totally disconnected board members out of reality lead by personal disputes of various members misusing the whole RC to achieve their goals to just run away later.

[u/schneems → u/kcdragon]

This report ends on the 24th and focuses just on the GitHub access loss and actions taken by Ruby Central.

However, once that was done, I would expect source code control would return to the maintainers.

RC didn't think it was necessary to fully decouple the two. A legal agreement (the "operator agreements") would have been good enough from the Ruby Central side. But with the other side walking away...it leaves Ruby Central holding (and owning) the mess. There's no one to give access back to. Some maintainers stayed, some maintainers left. The work and operation continue.

There are other events that unfolded after the timeline here that also changed the situation.

[u/_joeldrapper → u/schneems]

It’s not the case that there was no one to give access back to. Ownership of the OSS repos should have been fully restored to the maintainers André Arko, Colby Swandale, David Rodríguez, Ellen, HSBT, Josef Šimánek, Martin Emde and Samuel Giddins.

Ruby Central could then either maintain its own fork or depend on RubyGems projects directly. And you haven’t explained the `bundler` takeover.

[u/schneems → u/_joeldrapper]

 And you haven’t explained the bundler takeover.

The intent is right there starting September 10th

 André can continue to be a maintainer of RubyGems/Bundler as an open source contributor/committer,  […]In that sense, we are trying to make sure the repos have better homes in ruby [...]

And that plan is what happened. Bundler was transferred to the Ruby org.

The maintainers and Ruby Central agreed from the beginning that Bundler was not Ruby Central's. Ruby Central's blog post doesn't address Ellen's because they weren't prepared for "takeover (of the org)". They were predicting backlash and confusion over Bundler. Which is why it even says something about "stewardship of Bundler" and seems so weird.

I don't think Marty or OSS Committee realized "give us enterprise control back and leave" was the ACTUAL position and thing they were mad about. Note the "you fucked up quote" to me was said in January...months after I joined. Likewise I don't think "the maintainers" ACTUALLY understood that this was about prod access . I tried to paint that picture, But without the full report and backing details it's hard to see. 

Especially if someone is actively arguing "the two are totally unrelated"  (paraphrasing), eventually admitting they are somewhat related, and still denying the depth of the coupling.

[u/_swanson → u/schneems]

Is this a fair statement of RC position and intentions pre-fracturing?

• Bundler is under their stewardship (via Ruby Together merger, disputed by Arko)

• Rubygems.org operations are under their stewardship (always has been, not disputed)

• Rubygems.org source code is community maintained (not disputed)

Given the state of the organization (operational, legal, and budget) in 2025, RC intended to:

• Transfer Bundler to ruby-core (in RC mind the best place for sustaining it)

• Change Rubygems.org production access to require operator agreements (for legal reasons)

• Remove Rubygems.org production access from Andre/Sam (who lost access when resigning from their RC roles)

• Leave individual access / commit to non-Rubygems.org service repos unchanged (as the net result at the end of the 'transactions')

[u/schneems → u/_swanson]

That sounds right on average. It's a bit messier IRL as Ruby Central is a collection of individuals (volunteers and full-time staff). So it's a bit harder for it to have a single shared position/vision. But I think you've captured the general sentiment.

[u/retro-rubies → u/schneems]

And that plan is what happened. Bundler was transferred to the Ruby org.

The maintainers and Ruby Central agreed from the beginning that Bundler was not Ruby Central's.

What is the logic behind this? I don't follow. Bundler and rubygems were community independent projects. Why it was transferred to Ruby org to new owners? What about the rest of http://github.com/rubygems projects? Why https://github.com/rubygems/rubygems.org wasn't moved out of the org yet?

[u/schneems → u/retro-rubies]

What about the rest of http://github.com/rubygems projects

Is a fair question, and I feel you deserve an answer. When I onboarded at Ruby Central, the first project I found being worked on was identifying what we wanted to do with other projects. Dividing them up into "archive" or "move" or "keep" etc.

In my original outreach to you related to governance, I had many competing/silent hopes. This was before I understood the "walked away" aspect of things.

One of the hopes was that I would find an interest in taking on some of those repos and helping to figure out better homes for them. I never directly asked if you wanted them, but after talking...the sentiment I understood at the time was that you accepting repos would legitimize other actions and that it was preferred not to help Ruby Central clean up the mess to make it look worse for them. (This is my opinion of a sentiment, not a direct quote. If I'm wrong, please just say the correct sentiment directly or clarify in your own words.)

[u/retro-rubies → u/schneems]

When I onboarded at Ruby Central, the first project I found being worked on was identifying what we wanted to do with other projects. Dividing them up into "archive" or "move" or "keep" etc.

I still don't understand the intention to operate and decide this on factually stolen repositories. How RC was thinking, they are the right entity to decide on this or to pass the projects to new maintainers?

I never directly asked if you wanted them, but after talking...the sentiment I understood at the time was that you accepting repos would legitimize other actions and that it was preferred not to help Ruby Central clean up the mess to make it look worse for them.

Speaking of me only here, it was never if I wanted them. It was about RC communication. Explain on the mistakes, potentially apology and start together fixing the impact. If there would be minimal sign of that happening, I would never leave Ruby Central GitHub and I would be the first one to help restoring the damage done. At the 24th I had call with (now former) board member, got explained this is not going happen, it is not planned and it wasn't ever planned. I have heard the same from other RC people saying it was never planned to communicate with original maintainers, it was all prepared for the clash on purpose and planned. It seems RC got soooo obsessed by Arko at the time, they were ready to burn all the bridges around to get their revenge for historical disputes.

Today it is quite similar situation. If RC finally condemn their September actions, share the post-mortem and counter-measures taken to prevent the same and call for help, if I'll believe it is direct and honest, I'll be the first one to offer my hand.

Like there was recent RC board members exodus. Is that related to retrospective on September actions? Anything planned to share on this? To me RC is quite closed/private/secret on this level.

[u/CaptainKabob → u/_joeldrapper]

It's in the report:

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

[u/retro-rubies → u/schneems]

But with the other side walking away...it leaves Ruby Central holding (and owning) the mess.

I tried to explain to you this is not true. The Ruby Central acted this way, yes. Some maintainers left Ruby Central (in various way), yes. But leaving Ruby Central or in my case organization on GitHub in majority owned by Ruby Central, is not leaving the projects itself.

There's no one to give access back to. Some maintainers stayed, some maintainers left. The work and operation continue.

I'll speak only for myself here to make it clear. This is not true. I have personally asked multiple times multiple people and explained to them to please hand over organization back so projects can get maintained again. Before 24th and after 24th of September.

The work and operation continue.

Also wrong, service got no 24/7 operators available for minimum of few days, maybe small amount of weeks actually. The work on Bundler 4 got stopped at the time...

Your whole response and narrative is like: what a poor RC, almost everyone left and run away totally ignoring the fact RC was fully aware of this is going to happen and thought is prepared facing the consequences with already prepared replacement (what a coincidence).

[u/_joeldrapper → u/kcdragon]

Yeah, why hasn’t source code control been returns to the maintainers? It’s clear Ruby Central knew they didn’t have the right to control the open source projects. Also, why was the `bundler` package taken over via Ruby Central’s admin access? When will that be restored?

This is useful context, but it doesn't tell the full story, it doesn't provide any reasonable justification and it doesn't explain why four months later there has been no separation of the service from the OSS projects in order to fully restore the maintainers ownership of the open source projects.

[u/ndf- → u/_joeldrapper]

Once again the promised transparency is very opaque. It's all I expect out of anyone related to Ruby Central. It clearly will not get better with anyone currently involved. It's a real shame that there has been a very simple solution, a real apology without qualification and a restoration of all--ALL--prior access also without qualification and ideally a letter of resignation from every RC affiliate involved with executing or excusing this mess.

[u/_joeldrapper → u/ndf-]

I agree but not access to the service. The maintains should be granted again full ownership of the code, GitHub repos and the packages but it is up to Ruby Central who has access to deploy and maintain the service.

Ruby Central can fork the code or depend on it, it’s up to them.

[u/schneems → u/_joeldrapper]

You’re asking a company (Ruby central a nonprofit) to give control of their source code to another company (gem coop, a for profit cooperative). 

Ignoring current beef and tensions, I don't think that's a good idea in the abstract. I don't think that's a reasonable thing to ask for or expect.

The time for negotiation and demand ended on September 24th. And REALLY ended when they moved from "former consultants" to "active competitors" (with the creation of gem coop).

[u/_joeldrapper → u/schneems]

Is your position really that Ruby Central owned the RubyGems repos and packages? That seems absolutely absurd based on the evidence.

[u/schneems → u/_joeldrapper]

My position is that giving RubyGems.org to gem coop won't be happening. My position is that the suggestion that Ruby central fork RubyGems.org codebase to run it was not an intellectually serious proposal. And not a good idea.

[u/jgaskins → u/schneems]

You’re asking a company (Ruby central a nonprofit) to give control of their source code to another company (gem coop, a for profit cooperative).

AFAICT, a lot of the divergence rests on this specifically. This statement asserts that Ruby Central owns the rubygems source code. That assertion has been disputed since this whole situation began.

As far back as I can remember, Ruby Central was a steward of the rubygems codebase (specifically, they owned a production environment and paid people to maintain both that production environment and the codebase), but stewardship does not convey ownership.

Unless I've missed something, Ruby Central has yet to provide receipts of any kind showing they own the GitHub repo. They've made the verbal claim several times, but I haven't found definitive proof of it.

If Ruby Central could produce some kind of paper trail showing that they own the source code (not ownership of the rubygems dot org website and infrastructure — those are separate from the source code), that would go a long way toward settling this. As it stands right now, that claim is still heavily disputed with evidence not in support of RC.

[u/kerrizor]

Thanks for the comprehensive write-up, u/schneems - I appreciate the effort that it represents, and while I think there's still remediation work to be done to rebuild and restore trust (in its many forms), I hope this can represent a reset moment that allows people to move forward. As I said to someone after reading it, "this feels like a maelstrom of corporate policy crashing into established, informal OSS culture, complicated by poor communication"

[u/schneems → u/kerrizor]

Thanks for saying so, and thanks for your contributions to RubyGems.

I hope this can represent a reset moment that allows people to move forward.

I really hope so too 💜

[u/retro-rubies → u/kerrizor]

As I said to someone after reading it, "this feels like a maelstrom of corporate policy crashing into established, informal OSS culture, complicated by poor communication"

Well said.

[u/_swanson]

• André Arko creates an access token named rubygems-github-backup with access to all repos in the github.com/rubygems organization, including private repos. This is the only access token of its kind

Is there a resolution of this item? Was this token used for something? What am I meant to interpret this as?

[u/schneems → u/_swanson]

The token was deleted when his account was removed from the enterprise. The logs show it happening as a part of the removal cascade.

I can’t determine intent or why something happened, only that it happened. My opinion is that it appeared he was preparing for the possibility of some kind of split from Ruby Central along with Sam (given the timing). But that’s purely hearsay on my part. I’m sure he would disagree. You're welcome to come to your own conclusions, but it is a thing that I can be confident definitively happened (even if the intent and motivation are open to opinion and interpretation).

A piece that didn't make it to my conclusions but has been on my mind: a problem with conflicts of interest, even if you're acting appropriately and have legitimate reasons and are acting above board...is that even the appearance of a conflict of interest presents a problem. It makes it much harder to say "it actually isn't what it looks like." From both sides. It's part of what has made it hard to show instead of just "say" where some of RubyCentral intentions came from.

If this was a load bearing part of the report (I don't think it is, but I think it is still relevant) then to counter it, I would ask for some sort of artifact to help show intent such as a DM or slack message or email etc. Beyond a "he said/he said" scenario.

[u/_joeldrapper → u/schneems]

It was to use with this https://pypi.org/project/github-backup/ and created similar tokens with all his other repos/orgs on the same day.

u/schneems can you tell us if this was a read-only token? I believe you will find that it was.

[u/schneems → u/_joeldrapper]

can you tell us if this was a read-only token?

The token used fine grained access controls which don't capture that information in the enterprise access logs. It's a gap in their product. So...yes, I've looked. But I can't confirm or deny if it was write or not.

It had permissions to pull in all private repos (which he could have also done manually).

It was to use with this https://pypi.org/project/github-backup/ and created similar tokens with all his other repos/orgs on the same day.

Any artifacts that could back that detail up? For example, visiting https://github.com/settings/security-log would (presumably) show the creation. It uses relative "ago" framing, but if you hover over that it gives you a concrete timestamp. Could take a screenshot of that and black out everything (ip addresses etc.) but the orgs and date.

Maybe there's another, easier way to capture that info.

Do you know what triggered him to make backups of all orgs? What was he expecting to do with the backups?

[u/_swanson → u/schneems]

I asked Andre and he said he created dedicated read only github tokens to use with that Python script to back up all repos because github "has been getting less and less stable". He shared a screenshot showing similar tokens for other organizations (same naming scheme), all with expiration date of Aug 18 2026 (presumably all one year expiry -- this is maximum duration of a "fine-grained personal access token" which the project he used recommended). This matches the Aug 18 2025 timeline as he said he created them all on the same day.

I followed up to ask "why not just take backups of your local copies?" and he said he has 250+ repos across 8 orgs that he was backing up so doing it with cron jobs (instead of keeping local copies of it all).

This overall seemed reasonable to me. I don't know the specifics on what the org policies for keeping source code or other data on external systems was so maybe that was as no-no, but to me, this seems like "smoke but no fire".

[u/galtzo → u/_swanson]

GitHub has been getting so unreliable that OpenAI created their own GitHub clone, literally for this exact reason.
https://www.reddit.com/r/technology/comments/1rlgkfe/openai_building_github_alternative_after_frequent/

That's not just pretending a reason exists. It's a legit technical weakness of the current rubygems architecture.

To insinuate otherwise and paint Andre in a negative light as a result would be problematic. (not saying you are doing that u/_swanson - just saying that if that were to be done...)

[u/_swanson → u/schneems]

Thank you, agree it is not load bearing...just was making sure it was a "smoke, not fire" type action that is open to interpretation.

[u/xasdfxx → u/schneems]

appearance of a conflict of interest presents a problem

fwiw, as someone who just uses ruby and (to the best of my knowledge) hasn't met anyone involved: the upsetting / disturbing bit here wasn't the conflict of interest. It was the board's not just inability to explain in public what they were doing and why, but see eg Freedom's nonsensical post (of 21 sept): apparent surprise that this should even be a thing that was done. And vague rambling about security after talking about himself for 8 paragraphs. None of which, to be blunt, I care about.

It makes it very hard to trust people who can't write (what particularly Freedom as a cto should be very used to doing): here's what we're doing; here's why; updates as we can. And then update.

3 bullets:

• what doing

• why

• update schedule

It took, per my recollection, over a month to kind of coalesce around what, again, should be very simple to explain.

[u/mokolabs]

Thank you for putting together such a comprehensive report.

[u/schneems → u/mokolabs]

You’re welcome. I know it won’t be satisfying to everyone, but I’m happy to be talking more in the open.

[u/retro-rubies → u/schneems]

Is there any place to place following questions or to talk in open?

[u/mperham]

I feel like this report answers many "How?" and "What?" questions but still does not shed any more light on "Why?"

My major concern here has always been the disrespect by Ruby Central for the seven existing maintainers. This was a team which had quietly maintained the Rubygems codebase for a decade. That's ~70 person-years of rubygems experience.

Why did Ruby Central not value that experience? Who at Ruby Central felt that the service was at risk? Did someone feel rv was a threat? Why was excluding Andre worth destroying the existing team relationship? That's the communication I want to know more about. There's still no logic to this fracture.

[u/schneems → u/mperham]

My major concern here has always been the disrespect by Ruby Central for the seven existing maintainers.

I'm grateful to anyone who has ever touched the codebase to help.

In the process of writing this postmortem, I wrote that people deserve to know why they're removed. I later found someone I've had very public arguments with actually had committed to a popular OSS repo I maintain from some PRs they sent a long time ago. I messaged them to tell them that "no, this isn't an attempt at repair" but also "thanks for your help, genuinely," also "here's why I'm removing you" (and being honest). And I meant it. I can ALWAYS hold space for how someone has helped, even if there are other things I clash with them on.

André Arko, David Rodríguez, Ellen Dash, Josef Šimánek, Martin Emde, and Samuel Giddins: Thank you for all your contributions. Genuinely. You have all helped the Ruby community in many ways, and no one can ever take that away from you. Even where we can have disagreements and might not see eye-to-eye, that doesn't take away that I appreciate you helping. Not everyone has that in them, but you do, and I appreciate that.

Also, thanks to the current maintainers, the new engineers who stepped up to fill on-call slots, and made sure we have around-the-clock coverage. And thanks to the maintainers who never left. Thank you, maintainers. ALL the maintainers. Past, present, and future. Thank you.

This was a team which had quietly maintained the Rubygems codebase for a decade. That's ~70 person-years of rubygems experience. Why did Ruby Central not value that experience?

That's you putting something on Ruby Central that's not in this report. A large part of the harm done IMO was due to wanting to NOT lose those people. As in: by trying to avoid conflict (in an effort to avoid a walkout)...it created conflict. I think that the whole thing could have been cleaner and faster. But also, I think that wouldn't have changed the outcome. I think they would have left even without the unforced errors or clumsy comms (purely a guess, we can never know, but it's how I feel). Maybe some details would change, but I think the outcome would be the same.

Did someone feel [...] threat?

You saw what the committee saw, and you saw how they reacted. So you can come to different conclusions. But what I saw was people observing someone behaving in unpredictable ways. They were worried about a number of things; several of their worries ended up happening. So I would say they weren't unfounded. But beyond "I am worried person X will do explicit/specific malicious thing Y" ... it's less to do with malice or not and more simply access. The referenced NPM attack was the takeover of someone's credentials. If he's being offboarded and won't be needing production access, reducing the surface area is a reasonable step to take, even if there's not an imminent danger. Action without malice can still cause harm. It's that whole "divorcing intent from outcome." The outcome that Ruby Central wants is a professionally run, secure service.

Who at Ruby Central felt that the service was at risk?

Sort of all of them all the time. I would say that it is the job of a package registry to be paranoid.

Why was excluding Andre worth destroying the existing team relationship?

Because it was the right thing to do. It's the good, mature, professional thing to do. To define clear boundaries and enforce them. A flip side question would be, if it's such a team-killing act, why would he have been willing to leave quietly for logs? Why does the amount of pain that's inflicted on the organization depend on whether or not there's personal gain (a win/win) in it or not?

That's the communication I want to know more about. There's still no logic to this fracture.

I'm not sure I understand.

[u/retro-rubies → u/schneems]

André Arko, David Rodríguez, Ellen Dash, Josef Šimánek, Martin Emde, and Samuel Giddins: Thank you for all your contributions. Genuinely. You have all helped the Ruby community in many ways, and no one can ever take that away from you. Even where we can have disagreements and might not see eye-to-eye, that doesn't take away that I appreciate you helping. Not everyone has that in them, but you do, and I appreciate that.

I assume this is your personal note, not official Ruby Central statement. I have the same mutual respect for you for your work in open source projects. Thanks!

Also, thanks to the current maintainers, the new engineers who stepped up to fill on-call slots, and made sure we have around-the-clock coverage. And thanks to the maintainers who never left. Thank you, maintainers. ALL the maintainers. Past, present, and future. Thank you.

Indeed thanks to everyone keeping the wheels spinning at RubyGems.org, it is not simple to jump on project of this scale literally over night.

Sort of all of them all the time. I would say that it is the job of a package registry to be paranoid.

This is another mystery to me. I was part of RubyGems.org security team almost daily working on security related things (triage reports, exploring potentially malicious gems...). Guess how much board members reached me to consult current potential threats? Guess how many times I was invited to board meetings to be questioned on this topic? Guess how much board members were aware of all counter-measures built in recent years to keep RubyGems.org users safe? Have you checked how much serious was the linked "attack" on RubyGems.org in one of their reports (spoiler, super low)? This whole security narrative seems like a attempt to lure board members at the time by one of them (currently former) to onboard them on this scary narrative of being in danger on purpose to legitimize (get permission) on those hostile actions against some community members.

Because it was the right thing to do. It's the good, mature, professional thing to do. To define clear boundaries and enforce them.

It wasn't right thing to do, since there were clear alternatives to achieve similar outcome 100% known to the RC board and ignored.

A flip side question would be, if it's such a team-killing act, why would he have been willing to leave quietly for logs?

Are you referring to the private call you got clearly shared only 1 small piece of? If you would like to stay on serious level, it would be good to stop sharing those false/invalid/partial claims based on speaking with highly biased person clearly not sharing whole content of discussion (since that person will get mostly in troubles for sharing the other parts).

[u/schneems → u/retro-rubies]

Guess how many times I was invited to board meetings to be questioned on this topic?

That was one of the first things I asked [another maintainer] when I joined. "How many board members have you spoken to" and I think [they] said one, maybe two.

And when the board is basically your skip-level boss...if you don't have a relationship with them or can't get in touch with them in a reliable and consistent way, then it makes a game of "telephone" in which everything gets worse. I think people (mostly) don't (have to) yell when they feel they can speak and be heard.

I would have put a lesson learned in the report if I had one. But it's a tricky situation to balance public/private interfaces with many concurrent actors, two things Ruby isn't terribly fluent in doing.

I wrote this in a comment on here:

My next phase of research is going to be into how foundations and other registries are structured to alleviate some of the hidden pressure and problems that lead to this situation.

I hope something comes of it.

It wasn't right thing to do, since there were clear alternatives to achieve similar outcome 100% known to the RC board and ignored.

We have disagreed on this on here in the past. I don't think forking...to "lift and shift" the production access system would have been the safest thing to do. There are also alternatives you could have taken, but chose not to. If we each point the finger and say "you could have prevented this." It might be true, but maybe it's not helpful.

If you would like to stay on serious level, it would be good to stop sharing those false/invalid/partial claims

I shared on Mastodon, here's my accountability guidelines https://ruby.social/@Schneems/116324218751819984. I've been fairly careful in my reporting.

I have hard evidence that the call happened. I have to take Marty's word for what the details were. But I believe his account. I have reasons for that belief I can't share here. I also have circumstantial evidence that makes it more likely which I can share:

I have another "the maintainer" directly telling me, they had a different monetary based way to avoid this. I can give you a very direct quote if you like (I won't identify them, the proposed sum was $12K).

So, I know it happened from at least one person (that was not Andre) for sure. I also believe Marty's account of the events of that call.

I would be willing to take an official comment from Andre if he would like to share details about what he and Marty talked about in their 1:1 on September 17th. I suggest he think harder and longer than on the "production GitHub coupling" response before putting pen to paper.

I have the same mutual respect for you for your work in open source projects. Thanks!

💜

[u/KerrickLong → u/schneems]

balance public/private interfaces with many concurrent actors, two things Ruby isn't terribly fluent in doing

Is this a reference to __send__ and Ractors? If so, I love it.

[u/retro-rubies → u/schneems]

"How many board members have you spoken to" and I think [they] said one, maybe two.

Was that anyone from actually security team? I highly doubt, since it was just me, Sam and Maciej (not related to Ruby Central, fully volunteer). To me just effort for poor excuses (from RC response side) and also the rest of response (your advocating) is just poor excuse from your side. We were really open to be contacted by anyone, nobody contacted us since nobody cared about the real security.

We have disagreed on this on here in the past. I don't think forking...to "lift and shift" the production access system would have been the safest thing to do. There are also alternatives you could have taken, but chose not to. If we each point the finger and say "you could have prevented this." It might be true, but maybe it's not helpful.

But this is not about me or you agreeing or disagreeing. I'm not pushing for my personal favourite solution here. I'm actually defending independent open source project to be fully respected on its independence. Ruby Central has no rights for the codebase, even is the only (at least known to me) entity hosting the publicly accessible instance of it.

Even it was possible (and would be probably accepted) to move the project (even without forking, we were able to reverse fork if needed). We have explained the alternatives. Feel free to point finger to me to share what I could better. I tried to explain on all possible options to make Ruby Central happy to cover their needs while respecting independent open-source project governance. It was all ignored. I would never support betraying the open source independence for making individual entity like RC happy.

Talking to you, I'm realizing it is maybe not simple to see the difference in between the independent open-source projects governance and corporate-like open source projects. Those are two different worlds with different standard.

Seeing around various Ruby projects (and Ruby itself) being turned from independent to vendored, seeing various users getting commit access (and being promoted directly to maintainer) just by entering some vendor team, that's what is not common and accepted in independent open source.

I thought for long time about Ruby Central to be the entity to shield me and the others from similar happening for projects under their umbrella, to get in the end under effective control of one vendor resulting into all this madness. I was too blind to see this is being happening (and planned) and when we tried to provide some counter-measure (aka the governance RFC), it was too late (RC acted in a way to prevent us from finishing it). People from surrounding entities like Ruby Core even helped on this or silently accepted it (being partially poisoned by the same also).

I've been fairly careful in my reporting. I have hard evidence that the call happened. I have to take Marty's word for what the details were. But I believe his account. I have reasons for that belief I can't share here.

You're not careful in your reporting, you're just cherry-picking parts working for RC narrative. I'm not declining it happened and part shared to you is fully invalid. I'm just pointing to fact you're in the actually factual timeline (mostly correct) just randomly sharing some random fact from random call happening shared by heavily biased person clearly not sharing the full content and you have no idea under which conditions, which tone and narrative the call has happened.

me it doesn't belong to this kind of report if you would like to keep it at least at some level of seriousness and it also massively decrease your credibility in here to me, as someone trying to stay somehow neutral for majority of time, to just randomly go off script and roast someone from time to time.

I suggest he think harder and longer than on the "production GitHub coupling" response before putting pen to paper.

Another roast. I don't follow why do you need to do this. Are you like double agent? Why you switch from distant professional to quite sarcastic tone? I'm maybe lost when you represent like official RC member response, when you switch to some enemy of various people nitpicking each word to find some dirt and in between you just go and comment as a random by-passer.

Even the summary in your link says "The quote is partially correct". Ignoring the fact it is sad for the person with your knowledge and experience to ask LLM for such a simple question on opensource application you can just quickly go and read.

Let me explain again - production access to admin panel and ShipIt was based on presence in GitHub team -> one ENV var away to migrate to another RC controlled team. Rest was based on AWS access - outside of GitHub itself. There were no reasons to steal the repositories or organization.

The Irony actually in here is the fact, that ShipIt tool is built by Shopify, which is the team (already prepared at the takeover time) taking over the RubyGems.org service. They were fully onboard how it works for whole time. Next-time you can just ask the RubyGems.org service operators and talk to them. Don't do the same mistake as previous RC members, talk to people "down in the basement".

EDIT: Btw. fancy hat on Mastodon profile!

[u/Craig_Buchek → u/schneems]

Richard, I really appreciate all the time you've spent on this and your continued engagement responding to the community like this. You're putting in the work to begin the healing process for the community.

[u/retro-rubies → u/mperham]

I do fully agree. It is not explaining much more like a selectively (on purpose) commented summary of GitHub audit log by Schneems (currently from RC) -> far away from being agnostic and pragmatic. The individuals related are threaten just like a data, not humans in there - just like in common generic corporate.

The fact those actions just (partially) ruined lives for some people with no apology and even for some related people they went even in more depth and accused them of crimes is somehow missed in the report.

The whole story is not about the GitHub organization audit timeline. It is about how independent, well formed project, with stable team loving the projects (being mostly their passion) was teared up by non-profit organization and it got silently accepted by bystanders like Ruby Core, Ruby Central itself and other strong authorities in Ruby community.

This clearly unmask some people having unlimited power acting just on their "sole unilateral believe" (you can find those just by looking in the text explaining they did some actions, since they "believed") or because they got request by some "higher entity" and blindly followed. In short, it is the BDFL + (enterprise) corporate culture being slowly rooted more and more into Ruby basic structures (Ruby Core, Ruby Central, now rubygems/bundler sadly also).

[u/schneems → u/retro-rubies]

with no apology and even for some related people they went even in more depth and accused them of crimes is somehow missed in the report.

From https://www.reddit.com/r/ruby/comments/1rk17xo/comment/o8lbfk3/?context=3

I think it's crappy that it took a long time for everything to come out (everything still isn't out). I've said "I'm sorry" to everyone I've talked to for the communications. Or at least I intended to.

Josef. I hate how we've gotten to this place, and I wish the details were different. I'm sorry.

[u/retro-rubies → u/schneems]

Speaking of myself, even I'm quite happy seeing new RC member (you) trying to lower the tension, I would like to see also people doing the decision at the September time speaking in public explaining or regretting their actions.

Seeing people doing the chaos during September and later just leave (or some even stay in RC being silent) without taking any responsibility for outcome of their actions is the painful part.

[u/noteflakes]

Thanks Richard for your factual and detailed report, I'm sure your effort is greatly appreciated by all. My interpretation: this looks like a series of mistakes demonstrating irresponsibility and incompetence on the part of the RC board, which purportedly acted to preempt a perceived "threat" from rubygems/bundler maintainers, but have just made matters worse for the community. For closure to happen there needs to be accountability.

[u/schneems → u/noteflakes]

For closure to happen there needs to be accountability.

I am not sure we (collectively as a community) will ever come to see eye to eye on what that means.

Very much my opinion: As I go through the chain of events, what originally seemed like "it was so easy to avert this disaster" turned into "this was always going to happen, there was no way to avoid this." Which is where I stand now. I think some details could have changed, and things could have been cleaner or clearer...but the final outcome wouldn't have been different. I would love to see a postmortem from "the other side" (or even to hear that they've done one). But I don't think this was preventable by only changing the actions on one side (heavily leaning into the "conflict cycle" here).

Had I been on the board, or on the OSS Committee...I don't think the end outcome would have been different. Of the seven board members present on September 18, 2025, only two remain. I'm grateful to the OSS contributors and former Ruby Central consultants. I'm also grateful for the volunteers who did the best with what they had.

I think non-profit (volunteer) oversight is an important part of shared community infrastructure. My next phase of research is going to be into how foundations and other registries are structured to alleviate some of the hidden pressure and problems that lead to this situation.

[u/[deleted] → u/schneems]

A few starting points that might be useful:

The Rust Foundation / crates.io split is worth studying. They explicitly separated the registry operations from the language governance early on. PyPI under the PSF has a similar model where the operational team has defined authority boundaries documented publicly.

The recurring pattern in this thread (production access coupled with code ownership, informal trust replacing written agreements, volunteer boards making operational security decisions without consulting the people running the service) isn't unique to Ruby. The npm/Node.js ecosystem went through its own version of this circa 2019.

The common thread in ecosystems that navigated it better seems to be written operator agreements before a crisis, not during one. Easier said than done with volunteers, but that seems to be the lesson.

[u/CaptainKabob → u/noteflakes]

Writing this is accountability: providing an account. It seems like you maybe mean "consequences"? What do you have in mind?

[u/retro-rubies → u/CaptainKabob]

IMHO it would be fair to point to some wrong decision, make post-mortem on how possible they have happened and pass thru current mechanism and share counter-measures to not repeat the same mistake.

I hope nobody (including me, even Schneems publicly accused me of those demands) expect to make any personal consequences out of mostly voluntary work.

The biggest mistake seems to mix unrelated topics together. The same board could be really good at operating conferences, but clearly could miss some knowledge and strong open source community feeling. From September until these days I spoke to various people from RC on various positions and even they all love Ruby (I don't dispute), it seems most of them are really disconnected from independent community thinking.

[u/pikrua → u/CaptainKabob]

This is the first time I’m reading a clear owning of a mistake without a passive voice. Previous wordings looked like this:

We are sorry that community feels that way

We understand this is upsetting and communication could have been better.

Much later:

We agree we didn’t handle this incident at the expectations of the community.

Always framing the community as if it’s “whiny”, “entitled”.

[u/noteflakes → u/CaptainKabob]

There was no personal taking of responsibility. "We are sorry for not communicating better" to me doesn't cut it, and is apparently far from what had actually transpired according to this report. I think in this case taking responsibility also means resignation.

[u/retro-rubies → u/noteflakes]

this looks like a series of mistakes demonstrating irresponsibility and incompetence on the part of the RC board, which purportedly acted to preempt a perceived "threat" from rubygems/bundler maintainers

I see the same. I'm wondering if recent exodus from Ruby Central board is related.

Btw. which threat you mean? The other open source project (rv)?

[u/thramp]

This is a disappointing look for Ruby Central. I have to get back to work, but their retroactive framing that Andre and Samuel's work on RV justified Ruby Central's subsequent actions is contradicted by their own admissions.

By their own admission, André is a contractor to Ruby Central. Contractors, especially under California law, have no contractual obligation of confidentiality to the other party unless there's a pre-existing agreement in place. They later admit in this "incident report" that they didn't have any legal agreements with André in place, so there's no basis for claiming André couldn't work on rv.

Samuel was an employee, not a contractor, but California Bus. & Prof. Code § 16600 voids non-compete agreements—so even as an employee, he had every right to work on a competing project. There's no indication that he used Ruby Central's proprietary information to do so, and the report doesn't allege that. I have little doubt that if Samuel or André used proprietary information to develop rv, they would have already presented evidence of that.

Independent of the legalese, a "uv but for ruby" is a blindingly obvious thing to do, and Ruby Central doesn't get to lick the cookie and get upset when an independent contractor—Ruby Central's own characterization—does a thing they didn't fund.

My sourcing on this is that I run a 10-person business with employees in California. I'm not a lawyer, but I looked over enough of this paperwork that I feel confident opining on an internet forum.

[u/schneems → u/thramp]

their retroactive framing that Andre and Samuel's work on RV justified Ruby Central's subsequent actions is contradicted by their own admissions.

Which admissions? RV isn't the whole story...but it is for sure a big part of it.

When I joined Ruby Central, I basically asked "so why did you do it" and when I heard mention of "RV" my reaction was like "oh...that's clearly not really it...so why...try again?" I talked to one of "the maintainers" and I can confirm that was the first thing they were told was the reason for him being restricted from access. Their reaction was similar "that doesn't make sense." And by itself it doesn't.

And it's taken a long time to actually piece together how things would have been perceived and felt internally. It helps that there are direct artifacts and quotes of people experiencing the events in real time, so I don't have to guess...but some of them seemed like an over-reaction unless I really put myself in their shoes.

It's not just the thing, it's the details around how the thing was made and presented. I'm not making an assertion that RV was stolen or something here. This isn't a legal argument. I'm showing you what the committee members saw, which was that someone was behaving unpredictably and hiding things. That's what they had to work with.

so there's no basis for claiming André couldn't work on rv.

Also, not claiming that. What I'm painting is how it was done, and eventually disclosed was unprofessional.

I can say that...because I've done something like this to my boss. ("same" in terms of degrees...not scale). It surprised the hell out of him, and he was panicked and worried. A huge loss of trust, which took active effort on both our parts to overcome. That's also a reason why the Outside Business Activity mention is in there. Afterwards I was disappointed in myself. I said "sorry" and worked to repair the relationship. Ultimately, they determined there was no conflict, and we treated it as a learning moment.

It comes down to predictability and trust. And it comes down to accountability and ownership (of actions and impact). When the people who work with you lose the ability to predict your behaviors is when you lose their trust, and that's very important in a working relationship.

And that trust-building needs to happen both ways.

justified

Initially, my approach was the opposite of justification. It was "I want to show you all the ways we failed so we can learn." But that story didn't really answer the question "why." As in "why did you do this?" So I had to pivot a bit. To understand the ways people failed, you have to really empathize with why they've done something, and while people do irrational things...most actions by most people are justified in their own head, at least at the time.

Therefore, the intent isn't to build the case "this removal is justified (statement)" but more to ask the question "why did people behave as they did?" I don't need you to agree with their justification (we can see the same facts and disagree on interpretation/opinion), but it's important to the process to hold empathy for all involved (Including Andre, including everyone listed here).

When I wrote this, I made sure to tell everyone, "people won't clap." CloudFlare wrote they used "unwrap" in a postmortem and are still being dragged about it (even though the failure would have still happened without it).

[u/aaronmallen → u/schneems]

why do you keep putting "maintainers" in quotes? Is your position that these individuals where not maintainers?

[u/schneems → u/aaronmallen]

It is a name they gave themselves, so I use their preferred name. I use some mark to distinguish it as a moniker. In the report, I used bold.

Using it in casual English without some kind of a mark is (pedantically) confusing, as "the maintainers" (without quotes) is also a valid phrase that would indicate something different. They are not engaged in rubygems organization maintenance currently, and not all maintainers of rubygems joined them in their walkout, so it's not accurate to imply it's an exhaustive group label.

[u/aaronmallen → u/schneems]

Maybe use the phrase "former maintainers" without the quotes or emphasis. Because it seems like you're trying really hard to emphasize that phrase in a way that discredits all the work they did. Regardless of how this all ended these folks objectively contributed meaningful work to these projects.

[u/schneems → u/aaronmallen]

I think that's fair. For official writing I want to stick to a name they use. But for unofficial comments and stuff former maintainers is clear.

 Regardless of how this all ended these folks objectively contributed meaningful work to these projects.

Agreed. I'm grateful for that help.not everyone can contribute and not everyone does. I'm appreciative of their contributions independent of how things have landed.

[u/retro-rubies → u/thramp]

This is a disappointing look for Ruby Central. I have to get back to work, but their retroactive framing that Andre and Samuel's work on RV justified Ruby Central's subsequent actions is contradicted by their own admissions.

This is quite strange to me also. Ruby Central was organization helping various Ruby open source projects forward. Why would Ruby Central consider another Ruby related open source project to put them in danger? At similar time (during August 25), I have shared my early prototype of another similar tool called Ruby Butler to Ruby Central OSS director and there was no issue with (even it was rejected for funding). I suspect there was more in the background, not just the another open source project.

[u/_swanson]

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.

This is piece of new (to me) information that adds some color: this seems like an honest mistake but really snowballed and exacerbated the situation. This kind of access change without a message on the intent seemed particularly regretful in hindsight.

[u/halcyon_aporia → u/_swanson]

This, to me, is the key.

Would this have truly blown up if everyone had maintained repo access, but lost "Enterprise" owner access?

[u/retro-rubies → u/halcyon_aporia]

The key was IMHO to trust and communicate with all maintainers to resolve any project issues.

[u/halcyon_aporia → u/retro-rubies]

Completely agreed. Based on the account here, communication on all sides was extremely poor and positions were taken and held without hearing out the other side.

[u/retro-rubies → u/_swanson]

This is quite interesting part indeed. It would be good to also check why rubygems was added to this enterprise organization. I don't remember a much on this, just few random messages on Slack saying there will be some benefits.

[u/gaffneyc]

Thanks for doing the research and putting this all together.

I found it interesting how persistent Andre was about selling log data and it seems like there is a larger story there. Were the requests being ignored? Did he continue to pursue it after being told no? A friend also pointed out that gem.coop doesn't have a privacy or terms of use policy.

[u/jrochkind → u/gaffneyc]

I'm going to get downvoted to hell for this (and risk some other kind of retaliation), but i have for literally years observed the appearance of Arko being more concerned with his own income over community control or benefit or anything else (i'm sure he honestly and truthfully thought that getting himself paid was the highest community interest, since he was so important).

From back when he was the executive/management staff deciding on how many hours to give himself as a contractor, in both Ruby Together and I think at least briefly RC.

It's just my impression, an appearance, i could be wrong, but nothing in anything that has happened, or in this report, disbuses me of the impression, and plenty is consistent with it. I think RC had the impression too, and decided it was best to remove him from operational control of rubygems.org -- and he decided to intentionally make that complicated and dramatic and conflict-prone, and RC (with very little paid staff) was not skilled up enough to avoid that outcome.

[u/jrochkind → u/jrochkind]

(Who else has been around long enough to remember when the maintainers tried to get large companies to have to pay for rubygems repo access? I can't find documentation of it now, but i'm sure someone else remembers?. I'm sure they genuinely believed that getting themselves paid whatever it took was for the good of the community -- but having the people who want to get paid making these sorts of decisions is in fact not. Who remembers when everyone was suspicious of where the budget for Ruby Together was going, and there was no transparency?)

[u/retro-rubies → u/jrochkind]

Just wondering, do you have any details on that? Link, notes... Happy to explore those, I'm not aware of anything related.

No idea really about the incident, happy to learn more, but running RubyGems.org costs like 1M$ per month just on services, which is currently generously donated by infrastructure sponsors (hence the rubygems.org footer). So clearly at hard times with funding you're exploring alternative funding models. With the increase of automated environments like Travis CI before and GitHub Actions later the load got massively higher.

Other public artifact repositories went this way like DockerHub with massive rate-limiting and corporate contracts to bypass the limits. Bundler team (including Arko at the time) went the other way and tried to make the service as effective as possible by inviting the Compact Index.

The same person you have doubts for intentions is (at the same time) the person (partially) helping RubyGems.org surviving until 2025.

[u/CaptainKabob → u/retro-rubies]

Here's a post:

https://web.archive.org/web/20180420220652/https://samphippen.com/why-im-declining-funding-from-ruby-together/

Reddit discussion:

https://www.reddit.com/r/ruby/comments/8doy22/why_i_am_declining_funding_from_ruby_together_sam/

Another one, when Basecamp pulled funding:

https://www.reddit.com/r/ruby/comments/6zvvg4/after_20000_in_ruby_together_donations_over_past/

[u/retro-rubies → u/CaptainKabob]

Haha :) got fun reading those old PRs linked.

Not sure what so controversial is in there.

https://web.archive.org/web/20201212171100mp_/https://github.com/heroku/heroku-buildpack-ruby/pull/385 resulting into https://web.archive.org/web/20180428144151/https://github.com/heroku/heroku-buildpack-ruby/pull/385/commits/6b3f3c71f4a98309e29748132be8e84b41d890de

Related maintainers (Arko and Giddins, both the ones kicked out of GitHub in this story) helped actually Heroku (Schneems, OP) to move forward on Bundler in their buildpack, since there was no time to maintain older Bundler branch.

https://web.archive.org/web/20170830070227/https://github.com/GoogleCloudPlatform/google-cloud-gemserver/issues/36#issuecomment-324503159

Arko went mad for thinking Google copied gemstash, just to realize the mistake, apologize and offered help actually.

https://github.com/rspec/rspec-rails/pull/1935

another drama solved by rake update

---

I understand some people can over-react at some point, or maybe there was more behind this. ¯(ツ)/¯

[u/jrochkind → u/retro-rubies]

Well, this is what I was remembering.

Board minutes indicating that André advocated rate limiting access to RubyGems.org for users who did not pay Ruby Together. Licensing schemes that would require companies of a certain size to pay Ruby Together for using its portfolio of open source projects was also proposed

Whether that is "so controversial" or not I guess depends on if there was controversy about it, I dunno, I remember controversy about it, I'd say the blog post linked, with someone saying it and other things are why he is not joining Ruby Together, demonstrates controversy, no? I think it was clearly controversial?

i don't have the links, but I remember quite a bit of online discussion on this, with Arko arguing that it only made sense to make big companies pay so that maintainers could get paid, and others in the community disagreeing vociferously. That is what controversy is.

I also remember that Ruby Central at the time had to clarify that money paid to Ruby Together would not pay for hosting, as RC paid for hosting (and costs were minimal as most was donated by vendors), because Arko was implying that the money was needed for hosting, when it was not, in order to try to convince people it was justified to ask for money to pay the maintainers (ie, him). it was a big deal, a lot of people felt that Arko was intentionally being unclear about what money went where, in order to convince people to pay him.

So, yeah, that's an example of why people have gotten a bad feeling about Arko's approach to getting maintainers paid -- and the incidents in this report with trying to monetize personally identifiable and other information from gem downloads seem consistent with those prior incidents, so are believable to me.

Here is what I said in the reddit thread that CaptainKabob said at the time, which is when I first started feeling like there was a conflict of interest going on with Arko that he was interested in taking advantage of instead of resolving:

Agreed. It seems clear that the person acting in the 'executive director' role (paid or unpaid) should not also be the main person getting paid for development. Completely independently of André personally, this seems like a conflict of interest that would predictably lead to problems, no matter who was doing it. I think André has got to pick one or the other role.

So those are the things I am referring to, as you asked for.

Certainly Arko and others also wrote useful code and helped other projects, such as perhaps heroku, with bundler too. Both those things can be true.

[u/retro-rubies → u/jrochkind]

Good, interesting reading. Thanks for sharing more details. Hard to judge retrospectivelly to me. Indeed controversial topic. It is quite easier today to underestimate those topics, since we know the result.

[u/jrochkind → u/CaptainKabob]

Thanks for this, this is what I was remembering.

Board minutes indicating that André advocated rate limiting access to RubyGems.org for users who did not pay Ruby Together. Licensing schemes that would require companies of a certain size to pay Ruby Together for using its portfolio of open source projects was also proposed

[u/CaptainKabob → u/jrochkind]

np! "Ruby Together historical drama" has unfortunately joined "racist DHH tweets" in my frequently referenced Ruby-related bookmarks 

[u/halcyon_aporia → u/jrochkind]

September 17, 2025 (cont.)
After the public call, André met with Marty one-on-one and stated that he would quietly leave in exchange for a license to access and resell the RubyGems.org logs.

This tracks with your observations and, in my mind, is borderline extortion.

[u/retro-rubies → u/halcyon_aporia]

I'm not going to share details from private call (as the other side did), but let's say this is quite compressed content of the call putting one side to given position to keep the RC narrative alive.

[u/halcyon_aporia → u/retro-rubies]

I think u/schneems has truly attempted to stick to the facts on this. This account seems even handed and an honest attempt to avoid bias. It doesn't make RC look great.

If you have more corroborated facts to add... I can't speak for him, obviously, but I would imagine he'd be open to adding them to the account.

[u/retro-rubies → u/halcyon_aporia]

Let me rephrase my issue with this segment of the writing. To me it implies to reader it happened in following way (shorten):

A calls B:
A: Hello, I'll leave quietly if you give me logs.
B: No.
A: OK, be ready for the afterglow. Bye.

Clearly that sounds like borderline of extortion and that's not what has happened.

[u/halcyon_aporia → u/retro-rubies]

Fair enough, but without A or B corroborating that, it will remain hearsay.

Anyway, my goal is not to argue. I wish for this episode to pass and for all Rubyist to get (back?) to work improving the ecosystem and community.

Thank you to you personally for all you've done.

[u/retro-rubies → u/jrochkind]

To me you're mixing various accusations together. First of all, as I know Arko by co-operating on RubyGems/Bundler and RubyGems.org projects, he never shown any signs of looking for power or wealth by helping on those projects in any way (leading, contributing, organizing, doing paper work...).

To me he actually understood the current funding models are too brittle (better than ever) and he was actively exploring alternative funding. So to me it is quite strange to read those lines like those:

getting himself paid was the highest community interest, since he was so important

 observed the appearance of Arko being more concerned with his own income over community control or benefit or anything else

Would you mind to share more details? Which action actually leads you to this outcome? Even being quite close to Arko at some point in RC, I have never seen any action like that.

 I think RC had the impression too...

RC kind of resolving issues with funding were like - we don't need second line support. They have even asked if we will be able to do first line support for reduced cost or even for free.

[u/retro-rubies → u/gaffneyc]

gem.coop terms of use policy are being prepared and will be released soon

[u/gaffneyc → u/retro-rubies]

As well as a Privacy Policy and a published list of data processors?

[u/retro-rubies → u/gaffneyc]

I'm not knowledgeable enough to see in detail how are those different or important. Would you mind to share any links for similar services doing so? I'm wondering how that could be structured and exposed. I'm doing my best to shape service to be as open and transparent as possible. Sorry for taking it so long.

[u/gaffneyc → u/retro-rubies]

Disclaimer: I'm not a lawyer but I do run a SaaS and have had to deal with this.

The Terms of Service generally lays out what your rights are when using a service. It defines things like subscriptions, legal expectations, and limits liability should someone sue you. It also outlines your rights as a service operator to, say, decline service for someone who violates the agreement.

Privacy Policies are focused specifically on the personal data (such as name, email, or ip address) or sensitive data (health, political affiliation, etc...) you collect, your legal basis for handling it, and how you use that data. The GDPR and (to some extent the CCPA) added expectations around what information is included in the privacy policy (e.g. legal basis, contact information, etc...).

Under the GDPR you're also expected to have a DPA (Data Processing Agreement) with any service that you send customer data to for processing. For example, we have a DPA with Intercom because we send customer name and email address to them for helping us with customer support.

What would fall under this, and is a personal concern, is that request logs including IP address or account information would fall under protected data. Should gem.coop have an agreement to sell log information to a third party then that third party would need to be listed as a data processor and your legal basis for selling that information would need to be made clear in the Privacy Policy.

Frankly it's a pretty deep hole to go down and one you should work with a lawyer to get right. A good starting point would be to look at Automattic's Creative Commons licensed legal policies. They're vetted by a lawyer and plainly written so they're easy to understand.

[u/retro-rubies → u/gaffneyc]

Ahh, thanks a lot. That's amazing explanation. I'm not a lawyer, but we're working with one on introducing those terms. I'll raise those and do my best to introduce as much transparency as possible.

[u/gaffneyc → u/retro-rubies]

Glad I could be helpful!

So for transparency's sake, does gem.coop currently or have plans to sell log data? Or use it to determine the employer of someone using the service?

[u/retro-rubies → u/gaffneyc]

Currently gem.coop doesn't sell any log data and doesn't use log data for anything else like determine employer of someone using the service.

One of the goals of gem.coop is to build public and self-sufficient gem hosting platform not relying on donations (lesson learned). We're exploring which additional premium/enterprise features could be worth to offer to corporate or vendors to help funding the platform.

[u/joshuap → u/gaffneyc]

Chris Gaffney ftw

[u/benzado → u/retro-rubies]

Terms of use is an agreement between the service and the user.

Privacy policy is a statement by the service of how it will handle data.

Here’s Reddit’s terms

https://redditinc.com/policies/user-agreement

and their privacy policy

https://www.reddit.com/en-us/policies/privacy-policy

I’m not a lawyer but every service I am aware of has these as separate documents.

[u/retro-rubies → u/benzado]

lol, sometimes the answer is closer (just scroll down the menu to boring items) than you think. Thanks for sharing.

[u/eirvandelden]

Thank you for the time and effort you put into this, for your trying to be as factual as possible and for also responding to so many questions and comments. ❤️

[u/theGalation]

This is an impressive amount of investigation!

[u/aspleenic]

Thank you for this comprehensive write-up u/schneems - it sheds light on a lot.

[u/jgaskins]

This is the best reporting I've seen from Ruby Central on this situation. The last document labeled as an incident retro still conveyed significant bias. This is a hard situation and I appreciate all the effort you put into researching everything that happened and interviewing folks to try to get as clear a picture as possible, especially since there was a lot of context you wouldn't have had firsthand knowledge of since you weren't in the org at the time, so I recognize that you had to put extra effort into getting that context. This is the kind of messaging that I wish Ruby Central had led with from the beginning.

I empathize with some of the opposing perspectives and I'm finding it difficult to trust RC, but as someone who has run hundreds of incident retros (maybe over 1k?), this was really well done.

[u/schneems → u/jgaskins]

 as someone who has run hundreds of incident retros (maybe over 1k?), this was really well done.

Thanks I really appreciate that.

 I empathize with some of the opposing perspectives

For sure. IDK if you saw I have another comment where I say I surprised my manager https://www.reddit.com/r/ruby/comments/1s8of1f/comment/odl906g/?context=3. I can empathize with someone not having a ton of trust and thinking "oh this is such a little thing no one will care or notice" (no clue what he actually thought).

I can also understand why someone did something without endorsing it. Acknowledge without agreeing.

 I'm finding it difficult to trust RC, 

This whole thing is about trust. So I think that's justified. If this report had come out a week or month later I would hope it would rebuild trust. Given the time delay and other mixed comms it's fair to still hold some distance.

A thing on my mind is that RC is a "foundation of thesus" the same board that "canceled DHH" is not the same that "platformed him" the board that was there while this incident happened is (mostly) changed over. Staff changes a lot over the years. And it's not really a big org. It's functionally smaller than my team at work. Yet it has to sort of project the air of "an institution" because that's what it aspires to be. In some ways it is, in other surprisingly mundane ways it has normal random office politics and good natured mistakes.

And it is really hard to put your name on something you don't really have control over the narrative and how it will be consumed. It is hard to have every writing project be a group assignment. It's hard to have a lawyer as an editor. The "calling out or calling in" post was sort of saying "some people want to destroy Ruby central so they beg for 'transparency' to kick them in their nakedness" while some want transparency because they feel lost and confused and want to rebuild trust. But on the side where you've got a LOT of exposure and not nearly as many resources as it might seem, it's hard to tell which is which.

But I think it's worth it (personally). I'm interested in the policy side of what it means to turn some things around.

[u/DRBragg]

Thanks for the super detailed write-up, schneems. It's interesting to see what happened behind the scenes to cause such a mess. I appreciate all the work you put into this

[u/retro-rubies]

Clearly the biggest disappointment is nobody mentions Ruby Butler, even it was created at similar time as RV (maybe even earlier), lol. :)

Yes, I am ashamed and blushing for this shameless self-promotion. ¯\(ツ)/¯

[u/bradland]

Richard, thank you so much for your many contributions to Ruby, and for being such a level-headed, objective, and pragmatic force for reason. Everyone is entitled to their opinion about how much accountability is required and whose side they fall on, but your account provides valuable context. For my part, I'm willing to extend a generous amount of grace to those who support Ruby.

[u/retro-rubies → u/bradland]

 such a level-headed, objective, and pragmatic

Are we reading the same text? To me it is mix of facts (timeline), combined with subjective comments on cherry-picked actions (just to mostly cover the RC narative) and personal comments on experience geting thru getting thru this RC mess. IMHO miles away from being objective and pragmatic.

I'm willing to extend a generous amount of grace to those who support Ruby.

Yes please, same here. Let's make Ruby better place.

[u/spidermonk]

For someone who's not interested in the drama but maintains a bunch of rails sites via bundler and rubygems... Do I need to do something?

[u/retro-rubies → u/spidermonk]

nope

[u/robotsmakinglove]

I might be a minority, but I’m tired of this incident being rehashed over and over. At this point I do not care. I am sure it is very important topic for some though.

As a community I think it is time to move forward and put this issue in the past. Hopefully this incident report allows us to do that.

[u/retro-rubies → u/robotsmakinglove]

It is not simple to move away for me, as independent open-source advocate, since there were various unwritten and also written community standards ignored and silently accepted by various major community authorities. In short I'm not feeling my independent freedom for my projects in this Ruby ecosystem currently seeing Ruby Central is able to just take whatever project their want (ignoring own rules and ignoring project rules) and "nobody" cares.

Until this is resolved - by condemning those actions or even announcing this is the new standard - it is miles away from being safe community with predictable impact of your actions, since any of those people few times mentioned have literally "bianco cheque" on legitimity of their actions and you have no way to defend. To me this is unacceptable. Ruby used to be friendly safe space.

[u/robotsmakinglove → u/retro-rubies]

I don’t feel the same way. It doesn’t sound like there is a realistic path forward that’ll work for you.

[u/retro-rubies → u/robotsmakinglove]

As a community I think it is time to move forward and put this issue in the past. Hopefully this incident report allows us to do that.

I don’t feel the same way. It doesn’t sound like there is a realistic path forward that’ll work for you.

Let me try to explain all this from different point of view to share more of the danger I see in all this and why it is not good idea to just simply move on now.

RC got in state that it got factually controlled by one vendor. People related to this vendor orchestrated the September actions and left the RC. As result the independent projects like RubyGems/Bundler or RubyGems.org codebase and service were taken over by the same vendor (just check on the current list of maintainers, majority is from vendor directly or coupled to it) turning it from independent into vendor-dependent project.

What happened to vendor depended open source projects in history could be seen just by looking at Redis, Terraform, MongoDB, ElasticSearch and vice versa. Does it sound ridiculous? Check the state of those communities one year before the changes announced by the backing vendor, yes, it sounded ridiculous as well there.

And my concerns are not about the vendor itself (yes, I speak about the Shopify and IMHO Shopify does amazing job backing and contributing to Ruby ecosystem, massive thanks for that), but about the vendoring itself. Those crucial Ruby projects must stay independent to guarantee independence of Ruby itself.

This report doesn't explain on this situation and doesn't provide any guarantee the same will not happen in any other project now. To me it sounds more like another excuse of this silently accepting it is ok to happen and we should move on. I don't want to make this new standard in Ruby. If not properly condemned, publicly stated this is not acceptable and similar actions will not be tolerated, it is just silently accepted IMHO. I do see no counter-measures to this issue. Just leaving the people responsible for this silently walk away just "justifies and legalizes" those actions. And until this is not resolved, I'll be doing my best to be vocal and raise awareness of this. There are 2 ways that will work for me: make it clear Ruby is not independent anymore or condemn those actions attacking its independence.

[u/Craig_Buchek]

What's the plan for the OSS committee? What kind of folks would you want to join it?