Ruby’s Trustquake

In this episode of C4, Andrew Mason and Rachael Wright-Munn join Drew to unpack recent controversies surrounding Ruby Central and its alleged takeover of Ruby Gems and Bundler. The trio delves into the timeline of events, conflicting narratives, communication failures, and the underlying security concerns. They address theories and facts, scrutinize the governance of Ruby Central, and discuss the implications for the Ruby community. The episode emphasizes the importance of asking questions and seeking clarity, while advocating for a balanced and constructive approach to resolving the community's issues.

Sources discussed*:

• Ellen's first post on the RubyGems controversy 
• A board member's perspective on the RubyGems controversy
• An Update From Ruby Central (Video)
• Investigation (allegedly) reveals Shopify manipulated Ruby Central to force takeover of Bundler and RubyGems
• Strengthening the Stewardship of RubyGems and Bundler
• Martin Emde's post on Bluesky
• Reddit post for "An update from Ruby Central" 
• Bundler Policies on GitHub  
• Ruby Central "About" page  
• Advocacy for Reduced Rails Usage  
• Alpha-Omega Project
• Organization & Structure of Open Source Software Development Initiatives - Cyberlaw Clinic
• Ruby Central News Post: Alpha-Omega support
• StepSecurity: npm supply chain compromise
• Socket: npm supply chain attack
• Palo Alto Networks Unit 42: npm supply chain attack

* Some sources include unverified information being presented as fact. Read with caution.

Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Chapters

• 0:00 Setting The Stage: Ruby Drama
• 0:16 Guests And Goals For The Talk
• 1:09 How We Got Here: Early Merger Context
• 2:26 Competing Timelines And Claims
• 2:57 The September Timeline: Removals And Restorations
• 4:26 Theories, Facts, And Misinformation
• 5:04 Operator Agreements And Governance PR
• 6:03 Funding Loss, Sponsors, And Dependence
• 7:20 Communication Breakdowns And Public Perception
• 9:06 Security As Justification
• 11:19 Nonprofit Compliance And New Leadership
• 12:50 Alpha-Omega, Shopify, And Policies
• 14:39 Is This A Hostile Takeover?
• 16:27 Ownership: Service Versus Code
• 17:59 Governance Gaps And Single-Point Risks
• 19:49 Maintainers Leaving And Coverage Claims
• 21:12 Forking Versus Lockdown
• 22:42 Emotion, Burnout, And Trust
• 24:00 Board Structure And Community Voice
• 25:44 A Gray Situation, Not Villains
• 27:45 What Now: Accountability Without Drama
• 28:51 Final Thoughts And Ways Forward

Transcript

SPEAKER_03: 0:00

Welcome to a special code and the coding coders who code it. I'm your host, AI Drew Bragg. The real Drew is on the road this week. So here's a Remote Ruby Collab podcast that Drew was on talking about all the Ruby central drama. Enjoy.

SPEAKER_02: 0:15

Hello everyone. Welcome back to Remote Ruby. I am Chrisless today, which feels weird. I feel almost naked because I have never done this without Chris, I don't think, or Jason. But in order to not be truly exposed today, I have brought two friends to the show and I will let them both introduce themselves now, starting with Drew.

SPEAKER_03: 0:36

Hello, everyone. I'm Drew. You may know me from the host of Code and the Code Encoders Who Code It. I will be releasing this episode also on my timeline. So maybe you're hearing me from that timeline. But if not, you're listening to Remote Ruby, my favorite podcast. So welcome.

SPEAKER_00: 0:54

Hi, I'm Rachel Reitman. I go by Chail Codes Online, longtime listener, first time on the podcast.

SPEAKER_02: 0:59

I met Rachel at a conference recently, and I was like, you're a cool person. I'm gonna keep you in the back of my mind for like whenever a situation like this arises. So it's perfect. So we're just gonna kind of be going over what's been happening in Ruby the past few weeks. Why did something happen?

SPEAKER_03: 1:18

Maybe I'll give a quick timeline of what happened and then whose timeline? This is my problem with what's been going on is depending on your source, the timeline is a little different every time. So I'm interested to hear your timeline. And then I want to hear Rachel's timeline. And we'll give the public timeline. Okay. Go ahead, Rachel.

SPEAKER_02: 1:41

What were you gonna say?

SPEAKER_00: 1:42

I was gonna say I feel like the timeline for this starts way before any of these people are setting it, way back when when the merger between Ruby Together and Ruby Central happened.

SPEAKER_02: 1:51

I would agree with that. That's why I also wanted more people on the show because there's a lot of context to this that like I don't have because of how long I've been in the community. And there's a lot of context, let me tell you, depending on who I've been talking to people for the past two weeks about this. And depending on who you talk to, depending on how long they've been in the community, depending on who they know, you hear very different things. It's and that's why we're here to talk about it. But here's what happened timeline. All right. So with air quotes, don't forget with air quotes. Yep. Like Rachel said, there's a lot of stuff that happened prior to this, right? But what happened? So Ruby Central is being accused of a hostile takeover on RubyGems and Bundler. On September 9th, a maintainer of RubyGems renamed RubyGems on GitHub, the GitHub organization to Ruby Central and added Marty Hot to the admins, and all the other admins were removed. All the other maintainers were removed. On the 15th, permissions were mostly restored after some outcry. And Marty still retained ownership of the GitHub Enterprise account. On September 18th, permissions were revoked for all maintainers for the repos and the packages. And that's when we started seeing posts from Ellen where they're like Ruby Central has just executed a hostile takeover over RubyGems and Bundler. That's the timeline-ish of what happened, quote unquote.

SPEAKER_03: 3:23

And then everyone went crazy. I feel like was the next step because that's where things got a little weird afterwards, where it wasn't just this happened, all of a sudden everyone had a thought, an opinion, a theory on why this was happening, but they were presenting it like this is what happened, this is why Ruby Central did this, but with no source, no, here is who I spoke to at this organization, that organization that confirmed this. It was just theories, and it became really difficult to determine what actually was going on because there were so many people that are pretty well known in the community that had a thought and opinion, but was presenting it as fact. And that's where I think most of you and and me talking was about like, hey, did you read this? What do you think about that? Because it contradicts this report or that. What were you seeing, Rachel?

SPEAKER_00: 4:23

I saw a lot. I think one of the big things, at least for me, is like tracking back even like prior timeline stuff, going back to like the Ruby Together merger. Like there was talk about like, oh, the Ruby Together merger doesn't have like Ruby gems in it and stuff like that. I think one of the things that we haven't talked about is supposedly Joel Draper has, and I kind of believe this, a recorded video from a meeting that happened on September 17th between the maintainers and Marty, where Marty kind of steps in and says, Hey, y'all need to sign an operator agreement. And they claim that RubyGems and RubyGems.org are two separate entities, that they don't need to sign the operator agreement. And that happened a day before the existing maintainers were removed permanently for the second time. That one is one they agree with. But also there's like another one that I think is actually kind of important here. September 14th is when that RubyGems governance PR shows up, the one that they're working on with Mike McQuaid. I think that's an important point as well. I would also say that that one occurred after everybody was removed from the repository.

SPEAKER_02: 5:33

The reason that Ruby Central said that they did this was for supply chain security. That's their thing. They've been sticking to it. They're like, we are doing this to ensure the supply chain security. Now there's financial things behind the scenes that we'll get into, but also going back not only to the Ruby Central Ruby Together merger, but also Ruby Central lost a large$250,000 a year sponsorship that they were getting. And that sponsorship then left them pretty much solely dependent on Shopify as the sole bank, I guess, for like a lot of these services and like what Ruby Central is doing.

SPEAKER_00: 6:16

I think that's agreed upon by pretty much both sides. Everybody agrees. Ruby Central put out a blog post basically on August 1st saying that they're relying on Shopify sidekick and grants as their main source of income. They were straight up like, hey, we need individual sponsors. And I think it's somewhere was the$1,000,$3,000,$5,000 tiers where they were like, hey, if you as an individual company can chip in this way, that would help support us. And from what I've heard, they did not get the support that they needed from that.

SPEAKER_02: 6:46

Well, then you can take this all the way back to the Atlanta Rails Conf where at the very final keynote, Ruby Central got on stage and they're like, hey, by the way, we have this like personal sponsorship thing. If you do it, like you'll get access to this Discord. And it kind of left everyone like, what the heck just happened? Like, is there a problem? Is like Ruby Central need funding? Like this was like out of nowhere. There was no communication about it, which I feel like no matter how you're gonna slice this story of who's at fault for what and like who did what, Ruby Central poorly communicated at every aspect. And that's not something new, like that's something that has been an ongoing thing.

SPEAKER_03: 7:24

Yeah, big time. I think Ruby Central's communication issues is sort of what got them anywhere close to a funding issue from the get-go. Like when I found out that what Ruby Central was doing with the funds they were raising from conferences or sponsorships, I was surprised as a member of the Ruby community, not knowing and understanding what they did. And I started assuming no one else knew. And it turned out I was pretty much right because almost everyone I spoke to about why conference tickets were expensive, why supporting Ruby Central was important, all of this stuff. When I was like, oh yeah, they help pay for the RubyGem service and they help pay maintainers of RubyGem and Bundler and support the development, people were like, Oh, I didn't know that. And it was like, Yeah, neither did I, because Ruby Central was really bad about communicating why they're important. So it's not necessarily surprising that this whole debacle, even if you believe every version of the story out there, even the false ones, like they all stem from Ruby Central did a shit job communicating that something was happening and needed to be done and all this stuff. And then it was like all after the fact. There was a blog post, then there was a recording, and then like two weeks later, there was another blog post. And everything they said in the blog post seemed reasonable, but it was just so far after the fact, it was like, did you guys need to come up with the excuse of why this was important? Not that like you said, Andrew, they said this was supply chain security stuff, which I think is super important. I don't think that's an excuse, but saying it so far out, like, hey, before we remove anyone's access, in the next few weeks, we're gonna be cracking down on security, just a heads up. Oh well, I don't know why that wasn't said from the get-go.

SPEAKER_00: 9:55

And I feel like the supply chain security, I feel like that's very valid. And I'm also of the opinion, and I know this is something that's been really hotly debated, and like I know this is a controversial take, but I strongly believe that RubyGems, Bunler, and RubyGems.org all belong to Ruby Central since the Ruby Together merger. If they didn't, then that means that Ruby Together misrepresented to the community what they were doing and the responsibilities they had. I would even go so far as to say that the merger, which happened because RubyTogether ran out of money. I would even go so far as to say that that merger probably would not, may not have happened if RubyTogether hadn't represented themselves as the maintainers of Bunler and RubyGems. Whether or not Ruby Together's ownership is valid, I strongly believe that Ruby Central, when they took on Ruby Together, believed that RubyGems and Bunler and RubyGems.org were entering their responsibility and ownership.

SPEAKER_02: 11:01

So that's one of the reasons why I wanted some people on who had more time in the community, shall we say? Because in my mind, as someone who has been in this community since 2018-2019, Ruby Central is in charge of RubyGems and Bundler. From my understanding, like they pay for the service, they pay the maintainers, they contract maintainers, this and that. And it wasn't until this whole debacle where it was like, oh, well, there's a difference between the RubyGems.org service and the RubyGems.org code and the Bundler and the RubyGems code. I'm like, wait, wait, what, what, what, what? So, and like Drew said, like, depending on who you talk to, like, some of them may know that, or some of them may not. And from Ruby Central side, what they've said specifically is that they carry all the legal liability, the financial exposure, and the operational risk of the RubyGems service. And to me, it's like, okay, well, the service is directly tied to the code, is it not? So that was like my initial take on it. It was like, we saw what happened with NPM recently. They went under massive supply chain attacks, right? So Ruby Central is claiming that look, our corporate sponsors, and we now know they kind of only have one, are pressuring us into doing like we have this system of governance where it's like this is a community, people have been doing it for a long time. A lot of things are unspoken. You know, people are in the positions they are, not because they were elected necessarily, but because of like time in the community or like just novelty or experience or whatever. And RubyGem seems to be pushing much more to this corporate governance structure where like we need SLAs, we need these things, we need contributor agreements, and we need these things because corporations are requiring us to be able to prove that we are secure and not open these supply chain attacks, and we have a timeline, and that's why we have to do this now. That was another thing that was debated, which was maintainers were saying we were blindsided by this, but Ruby Central have been saying, no, we were in talks with them, and this was supposed to be temporary, but these talks had stalled out and this deadline was approaching, and like people weren't giving in, and there was some ego in there, and we had to take this drastic action because we just didn't get to a consensus. And our hope is that all these people who no longer have access get their access back, but they need to sign these contributor agreements, these SLAs, all these things to like have access to these things, so much more corporate governance structure.

SPEAKER_03: 13:33

Which sounds, I don't know, as stupid, might be the wrong term, but like you hear like this corporate red tape BS and you kind of get frustrated with it. But I think it's also important to note that like many of the executive directors of Ruby Central in the past have been Rubyists who just loved the community and wanted to help and were willing to step up into this ridiculously difficult role and do the best they could. They're engineers and they're developers, and they're not someone familiar with running a nonprofit organization. And now, since Adarsh left, we now have a new executive director who's less than a year in, who is much less technical than past directors, but is way more experienced with running nonprofits and all of the compliance that comes along, not just from like, hey, we're taking money from corporate sponsors and stuff, but just, hey, we have money, and here's how we have to keep our books, and here's how we have to ensure that we maintain our nonprofit status and stuff. So there are things that Ruby Central may not have been in compliance for some of these things for the longest time. And she comes in and goes, Oh, we need to fix stuff. That could be one of the main motivators here, too. In addition to, yeah, hey, we're down to like one major sponsor, and they've got their like, you need to get your compliance in order by X date. Because I'm sure Shopify uses RubyGems a lot.

SPEAKER_00: 15:02

Well, it's interesting because we're talking about Shopify and we're talking about compliance, but there's actually another really big sponsor at play here, which is Alpha Omega, and they're really focused on security. Also, Alpha Omega is part of like a group that talks about the stewardship of open source package managers. So they signed on on January 1st, and that's when Marty actually became full-time director of open source and full-time started working on Bundler and RubyGems and became the lead of those two projects. And they also ensured that Sam Giddens could stay on. But we're talking about compliance and like bringing things up to compliance. March 20th was when they added a terms of service privacy notice, acceptable use and copyright policy to RubyGems.org. That's wild to me because I have like a little side project that has like 15 users, and I'm looking at a terms of service. So the fact that RubyGems, which is like the backbone of our Ruby infrastructure, did not have this prior to March of this year. I really want to point out that Marty is the one who like started working with legal and like started to bring that in and operationalize this. So clearly he does have a responsibility and he is working on security and he is engaging with these teams and talking to them. He's not an outsider. Like he is involved with RubyGems and Bundler and making sure that they are secure and bringing them into the secure policy position.

SPEAKER_03: 16:36

And for what it's worth, and this is completely personal opinion, but Marty's been in the community forever and cares deeply about the community. So when people were talking about it being a hostile takeover and that Marty was involved, I was like, there is no way that it was like this malicious, hostile takeover. I curse on my show, so I'm gonna curse on this one. Fuck you all. Move if Marty was involved, because he cares deeply about this community and he cares deeply about the ecosystem and keeping Ruby an extremely accessible language for everybody. And there's just no way he would be part of any kind of like malicious intent takeover. Not saying that there wasn't communication breakdowns or that it could have been done better, but again, Marty is an engineer by trade. He's not necessarily, I believe, is his first time being like an open source manager director of anything. It sometimes learning hurts.

SPEAKER_02: 17:35

Yeah, I think when this all started to unfurl, like I know Marty. Like I've talked to Marty, I've met him at conferences, like I've seen him at every conference. I just didn't believe right out the gate, it was like I just don't see Marty as a malicious person at all. Do I think that he could have done what he did because he was told to, because of a board vote that was possibly malicious, maybe, but I don't believe that anything Marty did was out of maliciousness at all. So once everything got revoked, people started posting online, we started hearing claims about this is happening. I think everyone in the community first got an idea, like, oh crap, this is even a thing. Like I didn't even know this is a thing because it kind of came out of nowhere. And then we got a lot of discussion about whether or not people behind the scenes are doing this for security, or if this is actually a front for taking over the repositories, for kicking out certain maintainers, for doing something. And I've seen a lot of takes on that, and I guess they're plausible. I've yet to see a convincing argument as to why the motivation behind why that would be something they would want to do.

SPEAKER_03: 18:50

Some of those takes feel conspiracy theory-like, where it's like, oh, this person and that person never got along. So if this person is now involved or contributing money, they might be contributing enough money to say, I'll only contribute this if you get rid of this maintainer. And I don't know. Maybe there's a level of money that someone could contribute to make that happen, but it doesn't really sound like something that would happen at Ruby Central scale. Maybe I'm wrong, but again, without proof, without someone from Ruby Central confirming, yeah, we were getting rid of this person because our new sponsor doesn't like them, that's your theory. That's not a fact. And I think that's an important thing that everyone needs to remember as they're commenting on this is like anything you think may be going on is your theory. It is not a fact until you get it verified from multiple sources.

SPEAKER_02: 19:49

Right out the gate, there was a lot of claims, there was a lot of emotion is seen mixed into it. And at the end of the day, we don't know who the trustworthy narrators are. We know some of these people who are putting out this stuff, we've had interactions with other people, we've heard things about them. So, depending on who posts what, I take a very different like stance because of built-in biases towards that person. So we don't really know. Like, we've had a lot of claims. Now, I think like one of the main things was that this kind of all comes down to who owns this community project. Ruby Central claims that they have the responsibility after the Ruby Together merger, and that's directly contradicted. There's like this weird distinction between the service and owning the code, and like the service not being the code, which to me, the service is the code that you just put on a server somewhere. So that was the other thing that got really confusing about all this. It was like, well, you guys don't own the code, the community owns the code, or we own the code. And it's like, but who's responsible for it? And that's where this all got weird. It's like, well, Ruby Central runs a service, and that's not the same as the code. And that's gotten really confusing for me.

unknown: 21:02

Yeah.

SPEAKER_00: 21:03

To me, that governance PR and its timing is really an important point in the timeline because that governance PR was added after they were removed and Mike McQuaid stepped in to like speak on behalf of the maintainers, which to me signals that there was no governance in place, which matches kind of like what we're seeing, where there are some operational issues with RubyGems and RubyGems.org, where people have elevated permissions that they really shouldn't have for something that can like. I want to be like super clear here. If RubyGems.org goes down, Bundler does not work, and the entire Ruby ecosystem stops until it comes back up again. None of the GitHub actions are running, none of the like CI is running, people can't set up a code base for the first time. Really, the whole Ruby ecosystem grinds to a halt when this is down. And we actually saw that happen a few years back where there was an issue where it went down and everything. I'm trying to remember exactly when it was, but we did actually see it go down and how that impacted it.

SPEAKER_02: 22:09

And governments relying on this code, right? Like, let's be very clear. Like, there is Ruby running in satellites, there's Ruby powering government websites and like across the world. It's not a small thing to be like, oh, well, it's down.

SPEAKER_03: 22:24

It's like that XKCD comic where it's like the entirety of the internet and it's a stack of blocks, and it's this one little block over here. It's like some unknown, unpaid, underappreciated maintainer. We had this, what was it? The was it the left pad incident where like someone yanked a version of a I think it was an NPM package, and it just blew up half the internet. It was crazy. And we can't let that happen with RubyGems. To be clear, I'm very much pro hey, security and compliance and like reasonable security measures for RubyGems the service, RubyGems the code, bundler code, and all that. My concern in this entire situation is like the communication, what actually happened? Why was it done the way that it was? I don't know if we're ever going to get those answers. I hope we do, but it's been a crazy couple of weeks.

SPEAKER_00: 23:22

Yeah, I think the communication around this was really rough. And the execution could probably have been improved as well, because it looks like one of those previous maintainers still remained retained access to production systems. But I think the idea of locking down security and I think the ownership of Ruby jumps belonging to Ruby Central, like both of those are incredibly reasonable things.

SPEAKER_02: 23:44

When I was thinking about this more, I was like, when you think about it, one single maintainer was allowed to rename the GitHub organization, the Enterprise Organization. They were allowed to remove every other person from the project and install a new admin. And that by itself is problematic to me, right? Because if that person had accidentally clicked on the wrong link one day, that could be executed maliciously. But that's just kind of argument to the fact of like, look, there are some holes in the security of the system, and like there's definitely valid reasoning for wanting to like clamp down on that. Now, is that valid reasoning just an excuse, or is that just what is actually happening?

SPEAKER_00: 24:31

And I think that we can use Ruby Central's past actions, adding that terms of service, ensuring they have a security engineer, all of that. We can use that to indicate that Ruby Central was focused on securing RubyGems and they have this prior work that proves that that is what they've been doing. And actually, if you go look at their blog and you look at their posts, ever since Marty Joy and they've started like really upping the posts that they have about RubyGems.org and what they're doing and the changes that they're making. So we're seeing a lot more insight into what was happening than we were before.

SPEAKER_02: 25:05

It's just a shame the marketing person that they had recently left. And you, Rachel, you mentioned Sam Gidden the other earlier as the like main security person. He's also left from Ruby Central. And one of the arguments was that doing this, you did this all in the claim of security, but you've actually made everything less secure because you've let go of the people who had the most knowledge of that security, not just Sam, but like specific maintainers who are like, they know the security of RubyGems. Like that's what their thing. So you've let go of these people, and people are claiming that RubyGems is effectively unmaintained right now. Ruby Central is claiming the opposite. There were claims that Shopify engineers were put on call at Ruby Central to like handle these services, but I don't think we really know whether that was true or not. But at the end of the day, like everyone was removed, so you kind of have to start fresh. And if you need these contributor agreements signed, then if people don't want to sign them, which I've seen takes from people who are like, I'm not signing that, and I don't really understand that, but whatever floats your boat, I guess. Then it kind of all boils down to like, I think Ruby is in general kind of consider themselves to be like this scrappy little hobby language, and we're on the frontier and we're cowboys and we do whatever we want. But at the end of the day, like it's kind of grown a lot more than that. Like there are corporations depending on this. There's money involved, there's litigation involved, there's responsibility involved, and it's almost like, oh, remember back in my day when people are like, this was a community thing. Well, it's not anymore because things rely on this. We have to have this up, and it has to be secure.

SPEAKER_03: 26:47

We also used to install gems by running a curl command that would just bring stuff from the internet to our system and run a shell script to install it. So maybe some progress here would be a good thing for security. Also, from a couple of the different timelines I read, Sam left prior to this incident, right? He left early September before this all happened.

SPEAKER_02: 27:11

I think he actually might have even left in late August. Okay.

SPEAKER_00: 27:15

I haven't on my timeline at September 5th.

SPEAKER_02: 27:18

September? Okay. Okay. I think he announced that he was leaving in August and had like served out like a month or something. Yeah.

SPEAKER_00: 27:26

I'd like to step back to this idea that Ruby Jams is unmaintained. They have kept two people who were employed by Ruby Central, Hiroshi and Colby for sure. And I think they were talking about others. But from what I can tell, from the list of maintainers that I got, and the problem is like there's a group of maintainers that's got like 38 people on it, and there's a shorter maintainers.txt. And if you look at the short list of maintainers, the shortest one I could find, pretty much all of them were paid by Ruby Central at some point. Which means that like the ones that were removed were people who were like ex-Ruby Central or left afterwards. But at least two of them are former maintainers. They do have the coverage. And Marty himself has actually made merge some PRs. Not many, but a couple. Did y'all see the posts that Mike McQuaid posted where he went through each of the contributors and like basically ran homebrew stats on them?

SPEAKER_03: 28:24

No, I didn't. Yes, I did. I didn't go deep into his post kind of like ran the numbers and then sort of stopped. And I didn't do my own analysis on the numbers. I was sort of like waiting for post number two where he's like, here's from my very experienced perspective what this means. But I did see the post, yeah.

SPEAKER_00: 28:47

Yeah, his summary was basically like there were people in all groups, people that were removed that shouldn't have been, people that weren't removed that should have been, people that were removed and shouldn't have been. Basically, like according to homebrew's rules of who a maintainer is, there were people in all of those categories.

SPEAKER_02: 29:06

It seems like at least the three of us agree that security is important. Right? We can all agree.

SPEAKER_03: 29:15

I'd like to think more than just the three of us would agree on that, but is that not the argument?

SPEAKER_02: 29:21

Is the argument like, okay, what they did isn't necessarily so much the problem as how they did it.

SPEAKER_03: 29:28

Sure. I mean, that definitely could be an argument. And I think it even goes back to more of did Ruby Central have the right to do what they did? That depends on how the ownership of RubyGems and Bundler was described to Ruby Central during the RubyTogether merger, which there are conflicting reports on whether or not RubyGems and Bundler were included in that merger if Ruby Together had the right to include it in the merger. All I know is for as long as I can remember, Ruby Central has been putting money towards the maintenance and ongoing development and security of RubyGems and Bundler. So it sounds to me like they had at least a reasonable claim.

SPEAKER_00: 30:21

Yeah, and the README for both RubyGems and Bundler, both of those, and by the way, Bundler is inside RubyGems, but the README says that this project is managed by Ruby Central. To me, in the Absence of additional governance documents that say, like, this belongs to these people, and here's how we define these people, and here's how we remove these people. To me, that says what it is. And also, I've seen reports from people who are like, Yeah, I found out that I still had AWS access, or through this, I was actually removed as well, and I hadn't worked on this in years. So this does sound like it was a permissions cleanup. It does follow right on the heels of two major project leaders leaving Ruby Central. And so I think in my eyes, that's kind of what triggered this is they sat there and they're like, hey, we have these people who are leaving Ruby Central. We should really lock down security over who owns this and who can take over this repo. Because, like you said, Andrew, it's kind of scary that like one maintainer was able to take over the backbone of the Ruby ecosystem. Everybody was just like, okay, I guess we're locked out now. According to principles of least privilege, that's how it should go. And also, from a security mindset, I think sitting there and looking and saying, like, hey, these are ex employees of Ruby Central, we should really make sure that they don't have access if they don't need it.

SPEAKER_02: 31:43

I mean, I keep harking back to this point that Ruby Central carries the legal liability, the financial exposure, and the operational risk for it. But like he's it's a weird, it's a one of those things, you know. It's like there's this community aspect of it, and that kind of seems to have been basically desecrated and destroyed by this player. We've had key maintainers are gone. It seems like a lot of trust is broken. And Ruby Central knew they had alternatives to do this, right? Because they even talked about forking the repo. Now, when I think about that, that to me seems like a bigger problem/slash hassle than what they did. Like to me, forking the repo is almost even a bigger issue of like something's wrong, wrong here. But we have to pay for the service. And if companies aren't sponsoring Ruby Central to pay for this service, which it obviously seems like there's not, if they're basically beholden to one main sponsor, then we either accept that corporate governance or I even hesitate to say this, build an alternative.

SPEAKER_00: 33:44

A lot of people have talked about a hard fork. This is purely like my opinion on this one. I think that if they'd done a hard fork, people would have been just as upset because they basically would have stepped in and said, like, we've hard forked, and I think people would have claimed that they were stealing the code. And I think it would have also lent legitimacy to the idea that Ruby Central does not have ownership over Ruby Gems in one layer. I think that people probably would have said, like, oh, you know, that's their code, you need to continue doing that. And I think part of this is like, I think you're right. I think it's the communication aspect. And I think the containers were like really upset to be locked out of this. But I don't think a hard fork would have fixed anything. I think part of it is like, you're locked out, you're no longer responsible for this. You spent a large portion of your life working on it. And I think they would have felt that way if it was just like, we forked it, we've taken the code, you're no longer invited, and we're deploying this version of it, and Ruby is pulling this version in. So now you're over there working on an outdated fork that isn't being used or deployed or pulled by anyone.

SPEAKER_02: 34:51

Yeah, and then that code could diverge. Who knows? That just opens up a whole new swath of issues versus the ones that they opened by doing this.

SPEAKER_03: 35:01

Right. It's the same intense emotions governing everyone's reactions rather than looking at it as this needed to get done for security, for compliance. There's money to pay maintainers and run the service involved here. And not saying that the way they went around doing it was the best way, their communication obviously sucked and they probably shot themselves in the foot, hopefully, not in an unrecoverable way, but definitely in the short term, in a big way. But I think that if you look at it without the emotion of I've poured my blood, sweat, and tears into this repo, and you just yanked my permissions, that emotion's going to exist, whether the permissions are removed or we hard fork it. If you avoid the emotions that come along with that, I think it becomes a lot more of a wow, Ruby Central, you kind of suck at communicating. Please do better and less of a hostile takeover.

SPEAKER_02: 36:00

Yeah, because now you have these maintainers who are burnt out and they feel alienated from this long, like they're maybe even life work, but they're at least long-term work. I've also heard a bunch of people say there's this big disconnect between the Ruby Central board, Ruby Central leadership, and then the people actually doing the work at Ruby Central.

SPEAKER_03: 36:23

Yeah, I can definitely understand that. It's been brought up before how whenever there's a spot open on the board, it's the leadership team that kind of goes through the applicants and kind of picks the one that they think fills the role the best, which I can understand, but also to a point where it's like maybe that's not how it should be done. Maybe the board should be community vote of we want this person on the board to represent us as the community so that the leadership team is not also controlling the board. And maybe that will help improve things. I don't know. I've never run a nonprofit before. I'm just a developer.

SPEAKER_02: 37:03

It is a good point to the argument that a lot of people are claiming, like, I'm not even gonna sugarcoat it, that Shopify is doing all this, that they're creating these things, and that DHH is behind the scenes because he's on the Shopify board. And I'm not even gonna bring him into this because he's got nothing to do with this. He's got nothing to do with the immediate facts of this, as far as I can tell. But a lot of the people on leadership or on the board, people are arguing are from a certain company that also happens to sponsor, basically pay for this service. Well, how did they get there? Is it not impossible to get on the board? Like, I don't know.

SPEAKER_00: 37:44

Ruby Central has actually done two different rounds of like recruiting board members. Because if you think about it, this is unpaid work. Like, this is all volunteer work being on the board. When Ruby Central actually had money, there was like a small stipend that they would kind of like offer people, but that's been gone for the last couple of years because they haven't had money. Everybody on the board is volunteered. Also, Ruby Central like cannot do right in the eyes of the community, basically. People are either ignoring what they're doing or they're angry about what they're doing. There's no in-between. There's no like, hey, you know, we would like, no, it's just we're super angry or we don't know what you're doing, we don't pay attention, we're not buying memberships.

SPEAKER_03: 38:25

Because everything's working.

SPEAKER_00: 38:26

Exactly. And I'm kind of sitting here and like you're talking about having a vote for board members. I'm kind of sitting here thinking, like, if we were to do a vote, maybe it would make sense for that to be a vote from members of Ruby Central over who should represent them. And maybe that offers a compelling reason to have that$20 Ruby Central membership.

SPEAKER_02: 38:48

I could agree with that. I could definitely get on board with that. That's a really good point. Someone should be taking notes on that. Unless I'm missing anything, and I'm both of y'all can chime in if I have, I think we've kind of reached the overall like kind of timeline of like what's happened and the theories as to why.

SPEAKER_03: 39:08

I mean, at least from my understanding and the things that I've read. Again, I haven't talked to anyone one-on-one that was directly involved with this. All I'm basing all of my thoughts and theories on are all of the blog posts that I've read, whether they were hardcore Ruby Central's the villain, or hardcore you all need to understand Ruby Central's not the villain, this person's the villain, or you're just not understanding, or some mix in between and my understandings of the people involved. I see it as a very gray situation where a lot of people involved screwed up and it could have been done better at multiple levels, but I have yet to see evidence supporting that this was malicious. So that's my take.

SPEAKER_00: 40:01

I think a lot of people are painting this as like a takeover. It's hostile, it's this, it's that. I do think it was security focused. And also, I think we should probably cut Ruby Central some slack because I'm even seeing people call for like the end of Ruby Central or a replacement for Ruby Central. And like I'm on board for like adding more to the Ruby community, more funding organizations, more support, more package managers, all that sort of stuff. When it comes to ending Ruby Central, I'm kind of like, I don't think that they should be destroyed for having poor communication around something that they did have the right to do.

SPEAKER_03: 40:38

Agreed. And I would love to see one person calling for the end of Ruby Central who has been willing to step up in the past and serve in that executive director position that they were hiring for, who has tried to get on the board, who's made any kind of good faith effort to participate in Ruby Central in order to help steer it in the direction they want this new organization to go towards. I don't know. A lot of people have a lot of opinions, and some of them suck.

SPEAKER_02: 41:15

When I started this, I was like, look, I'm gonna try to give an unbiased take on what happened, and I think we've mostly done that. And I guess my core takeaway is like this is sad. It doesn't feel as big as the Python two to three like debacle, but it feels like this is definitely created a rift in the community. The dust has definitely not settled on this, things are still up in the air. Like, I had been talking about doing this episode since like last week, right? And I'm glad that we waited till now to actually do it because so much has come out in that time from both sides. So, like, this is an ongoing thing. There's a lot of emotions and there's ego involved, there's money involved, there's corporate sponsors involved, there's a lot of questions and like motives that we are getting hypotheses on, but don't truly know. There's a lot of people trying to stir up drama, and some of that it makes a lot of sense based on who they are. But at the end of the day, this is kind of like it feels like a cautionary tale for any open source ecosystem that relies on corporate funding. Because at the end of the day, whether they're being forced to or they're just being like, hey, you should do this, and maybe if you don't, we'll revoke that funding. It forces us to ask this uncomfortable question about the power and the money and who truly gets to decide over the future of these tools, who truly owns code that's been built by the community. And I guess I'm just kind of like, what's next? Are we going to be able to recover from this? Is this going to continue to be a rift? At the end of the day, it's a net loss for the community overall because we've lost all these maintainers. There are other people who are like, Yeah, I was a provider operator and I'm no longer willing to do that. I'm not willing to sign the contributor agreements or whatever. So at the end of the day, it's just sad all around that this had to happen. I don't know who's at fault. It seems like everyone's at fault so far. And everyone's just pointing the fingers at each other.

SPEAKER_03: 43:18

And to your point of like, we waited at least a week, if not longer, from when we first talked about potentially recording our take, not even our take, just like our interpretation of the timelines and blog posts and everything. So much has come out. I'm sure more stuff's going to come out. I reserve the right to change my opinion and my take on everything that I've said, because this is just my understanding based on the information I've been receiving. If some of that information comes out and it's like, this was wildly false, and here's contradictory real evidence. I a hundred percent reserve my right to change my opinion. It's a strong opinion, but it's very loosely held. And I think that's an important stance for everyone to take is like read all you can, take everything with a grain of salt, question everything, and be ready to change your opinion on this very continually ongoing situation.

SPEAKER_00: 44:12

I think everyone involved is like a good person who's trying their best for the Ruby community. On one side, we have people that are trying to make it more secure. On the other side, we have maintainers who've contributed their lives and like a huge chunk of their careers to improving this service. It's just in this particular case what they wanted and what their goals were were in conflict. Ruby Central is over there and they're like, we need to secure this. We need operator agreements, we need to make sure that nobody can come in and take over this repo and we need to protect it as strongly as possible. Ruby already has this reputation as a dead language, as a slow language, and we cannot afford to be an insecure language as well. And I think on the other side, you have maintainers who care about who we're paid to, right? So there's a job aspect of this as well, and who wanted to drive this forward and make it better. And maybe there was some poor judgment involved on the best way to do that. And also some poor communication. Like I'm sure having your access revoked and then having someone come in and say, like, hey, we'd like you to sign contributor agreements to get it back. That's not a fun way to have that happen. And I think that we don't have the full timeline from Ruby Central either. And there's been some like conflict around what communication they did do. We know one recording exists of this meeting. We don't know what other meetings happened before it or what other conversations happened before or around it. We just know that this one meeting exists, and we know it exists from the side that is upset at Ruby Central as well.

SPEAKER_02: 45:56

Why aren't these board meetings public? Why don't we know about them? Like, why can't we know what's going on?

SPEAKER_03: 46:06

I don't know the answer to that. Maybe because of the sensitive nature of the development of I don't know.

SPEAKER_02: 46:14

See, I would want to but see that would open up more questions. But again, like I said, they're very gonna no matter what, Ruby Central has a communication issue. No matter what, no matter how you slice this, they fucked up. I'm sorry to the children listening. You leave my F-bombs in there, Paul.

SPEAKER_01: 46:35

Those kids, they're just hungry for Ruby drama, they care deeply about like package managers and the security of the community, those six-year-olds, Andrew.

SPEAKER_02: 46:45

I just specifically remember a comment that Jason harped on one time because it was like, I listened to this show with my kids in the car and y'all cussing, blah, blah, blah, blah, blah. Anyway, we can bring this train into the station. Drew, do you have any final thoughts? And if not, tell people where they can find you online and keep up with you.

SPEAKER_03: 47:07

My final thought is less of a thought because I feel like I've made my thoughts clear, but a more of a request, and it kind of piggybacks off of something you were saying. Is like there's still a lot of questions. So ask questions, keep asking questions, keep asking questions of both sides. Ask the questions in good faith, but don't run with wild accusations. Don't have a theory and post it like it's a fact. Don't post a timeline where you put something in that is unverified because you're just muddying the water. You're making everything more difficult. And we as the community need to get this figured out so we can move forward. Whatever that looks like, I don't know. I'm not that smart, but we do need to move forward in whatever way that looks like. And wild baseless accusations aren't helping, but questions do. I can be found. My website's drbrag2gs.dev. I have a podcast code and the code encoders who code it. I help run Philly RB. I work at podia with Andrew. I can be found a variety of ways.

SPEAKER_00: 48:14

Had everybody a little bit of Slack. If you want the Ruby Central Board to start sharing minutes, give them a little bit of space and a little bit of trust and a little bit of slack so that they feel safe enough to do so. Everybody in this cares about the Ruby community and they want to make it a better place. So give them a little bit of trust in that. If you agree with my takes, you can find me at Shell Codes on Blue Sky and Twitch. If you disagree with my takes, you can find me at Andrew M. Codes.

SPEAKER_02: 48:47

Oh that's good. That's a good one. Whoa. That's a Jason level troll right there. I want to thank both of y'all for coming on like immensely. Like, I have been thinking about this for a while, and I was like, I don't want to do this alone. And you both were like, yeah, I'll do it with you. So I just want to say thank you both for coming on and sharing your takes and doing the research and I don't know, just caring, I guess. We all three of us care about Ruby and RubyGems and Bundler, and we care about these maintainers because we know how much we owe them. And we also care about security and the service staying up. So I guess my final take is that things are still up in the air. Drew, I think said it perfectly. Like you are allowed to demand accountability and to ask questions. And I don't think that's unhealthy at all. But a lot of the drama fear-mongering stuff, I think, is unhelpful. But at the end of the day, this is something that is important, right? Because this could fundamentally tear the ecosystem if we're not careful. And I don't think any of us want that to happen. So I think more people need to stop blogging about things and start trying to figure out what they can actually do to help improve the community, improve the situation, improve the services, et cetera, et cetera. So that's the end of this. Hopefully, Chris comes back soon because I miss him, but I hope he is enjoying his time off. Thank you everyone to listening for Ruby, and I will catch you all next week.