There Will Be Bleeps  ## Metadata - Author: [[Changelog Master Feed]] - Full Title: There Will Be Bleeps - Category: #podcasts - URL: https://share.snipd.com/episode/a1549d70-b794-4b4d-a943-fa5985f2b6aa ## Document Notes ## Highlights - **Access And Governance Sparked The Crisis** - RubyGems governance and access issues escalated into a public crisis after maintainers lost operational access. - The result fractured trust and prompted maintainers to create alternatives like gem.coop. Transcript: Mike McQuaid Yeah, so I guess things kicked off probably what we are we're october 15th at the time of recording so this time a month ago things seemed to all be fairly normal and stable and whatever No one seemed to really know much like i guess my first personal involvement was there was like a governance pr on ruby gems that was based on the homebrew one. I was pulled in and asked to kind of give my thoughts on that. And then a few people started messaging me and whatever. But essentially what went down is Ruby Central, for the main parties involved here, is the nonprofit organization that controls rubygems.org. They had as employees and contractors at various points various maintainers of rubygems the open source projects and those people were involved with rubygems.org kind of on-call Rotations and whatever so essentially kind of i guess last month you know we're talking i think sept the 18th or whatever. From then onwards over the kind of following few weeks, Ruby Central notified RubyGems maintainers, including, I guess, Andre Arco. Like, I guess if you want to read the two differences of accounts, I guess the starkest extremes here are Andre's written a few things on his blog. RubyGems have written a few things on their blog and basically from september the 18th onwards andre and some other ruby gems maintainers were removed from the uncool rotation they Were removed from their github access and various bits and pieces went down there's kind of back and forward and arguments and disputes about what was communicated exactly by who and When and what happened and what didn't happen and whatever but essentially we're at the point today where almost no one who is involved with rubygems open source project has access To be involved with it today and andre and a bunch of the other ruby gems maintainers have created their own thing called gem.coop which right now is essentially like a modified version Fork whatever you want to call it of rubygems.org it's run as like separate infrastructure and andre has personally been involved with kind of some competitors to like Bundler and RubyGems and whatever. I think there's a tool called RV. And what seems to be now public knowledge is that both parties are writing various blog posts targeting the other. And it sounds like there's some kind of lawsuits in action between various parties as well. ([Time 0:04:16](https://share.snipd.com/snip/b67ecd9a-883c-4e77-a461-4c8bd6f8d4e8)) - **Root Account Complication Triggered Incident Response** - Ruby Central treated the event as a security incident after a blog post revealed lingering AWS root access. - They found an unauthorized login that changed the root password and began an investigation. Transcript: Justin Searls Was it the 30th? No, it was it was more recently. It was about the event on the third. Jerod Santo It was published October 9th, October 9th. Thanks. The event might have been the 30th. I'm not. Yes, the event. No, on the 30th was the blog post that raised concerns. That's right. Justin Searls So part of why this is confusing is the post is a timeline, but the timeline is like three timelines in reverse order. To first talk about like the last thing that happened and in what order things happened when the last thing happened. And then the next section explains like the why that the why behind that. And then the next last section the why behind that uh and if you were to like and i and this is why as soon as i read it i put up my own blog post i kind of tried to unspool it to explain like what Are the stakes what this reads like to me when you when you go through it so i'll first try to like summarize the it's characterized as a post-mortem of a security incident response where On september 30th a person named joel draper or draper posts a blog post that says uh yo andre arco still has all these systems accesses like the only person who he's the only owner of a Particular github organization uh he's still got these AWS accesses. And I think that the, if not expressly stated, implication of the post is, this is how incompetent Ruby Central is, that here we are weeks after supposedly having these accesses removed. He actually still has this access, and so look at how insecure this is. Jerod Santo This is Ruby Central not having their act together. Right, because they had taken access away from Andre as well as other rubygems.org maintainers prior however andre still had access according to joel draper's draper draper it's Two p's i don't two p's but joel draper just sounds more natural so i don't know yeah and my wife and i are rewatching Mad Men coincidentally. Justin Searls Don Draper. Yes. And so it's just like, it's really hard to separate. I agree. I haven't seen it for years, but I'm still saying Draper. Jerod Santo Anywho, this post that he says on September 30th is that they're so, I mean, the implication is that the incompetence of Ruby Central, who is the, is it a foundation? Is it a nonprofit? Help us understand some of the entities here. Ruby Central, is it a for-profit? Mike McQuaid My understanding is it's a 501c3, which I frankly, I really wish I didn't know about US nonprofit organizations, considering I don't live there and I never will. But yet I've been involved with like open source nonprofit stuff long enough that I'm sadly intimately aware. So a 5.1 they're somewhat hard to establish nowadays because various government agencies have decided that like open source software is a bit too easy to look businessy, right? So basically it's an organization that exists to own the assets of Ruby Gems. It merged previously with Ruby Together, which was started by Andre. I don't know who started Ruby Central personally, but basically it exists as an entity to provide legal ownership of the service, to provide the ability to receive tax-free donations From individuals and companies, and then redistribute those to whatever nonprofit-appropriate areas that they do, which has been RubyGems maintenance, RubyGems on call, some Conferences, et cetera. Jerod Santo And there's a lot of moving parts, which makes us hard to track. There's like the repos on GitHub. There's the servers that are actually running said code. There's the access to the servers. There's databases. There's other things that make this just really hard to track. But back to, so that's Ruby Central, the entity. Back to where Justin was, they published this post about Joel Drapper's post saying that Andre still had access or implying that there was. Right. Yeah. Justin Searls So so so before the post post, don't worry, like like they actually were notified of of this permissions exposure. So it wasn't a zero day announcement. No, yeah. It looks like seven minutes where Andre emailed them that he still had these accesses and that this was the only disclosure. Joel Post goes up, you know, at 530 UTC, you know, and now this is Justin, the guy just reading a blog post. So forgive me if my characterizations are at all inaccurate. You know, at that point, Ruby Central has to treat it like a security incident. So they go into emergency mode, try to lock down all these systems, initiate password reset, and then begin a relatively long, you know, investigation of all these other knock on systems First over the next few hours and then the next few days. When let's see when they backtrack, right? So that's September 30th. Then there's an analysis of events that goes back and says, hey, look, on September 18th, Ruby Central notified Mr. Arco via email that he was going to have his access removed or that it had been removed. And while they removed his particular IAM, I assume, like AWS account that presumably would be tied to his email address, they did not rotate the password on the AWS root account. So, you know, like if you're familiar with AWS, there's typically an email address and a root password or an email address that is effectively the root account. And it's bad practice to use that thing right and log in as it because you don't have any of the sort of like you know policies and procedures available to you but because andre was like Kind of the core one of one of if not the core operator of ruby uh gems.org for so long uh it appears that even though that he was removed from whatever their password vault system was, presumably Like a 1Password, he had a separate copy of that password or that login item somewhere. Because even though his, you know, email was, his individual AWS account was apparently, according to Ruby Central, disabled. It looks like roughly eight hours after that notice sent, they state that an unauthorized actor from San Francisco logged into that AWS account, into the root AWS account, and then Proceeded to change the password. And as far as they know, didn't do anything else. ([Time 0:09:04](https://share.snipd.com/snip/b6ce341e-85e7-484b-9175-21ad82e6467a)) - **Repair Trust With Honest, Practical Transparency** - Be transparent and admit mistakes publicly to rebuild trust after security or governance failures. - Share lessons learned and recommended practices to help others avoid the same errors. Transcript: Mike McQuaid So like from, guess andre's perspective what's been published is he says like well i thought this was i didn't have enough information to go on that this wasn't was a legitimate event And it wasn't like someone at ruby central's email or kithub account or whatever had been hacked so i was trying to do what i could to preserve the integrity of the service but i think like What is hard for me with the communication of both sides, right. Is I think particularly unsurprisingly now that maybe some lawyers are involved is that I would love to, maybe it's the, just cause I'm British. I would love like a bit more from both sides and saying like, Hey, turns out in hindsight, I didn't do the best thing here right and going forward if you find yourself in the situation i Was in my advice to you is to do x instead of y and i did y right and i i think that's the hard thing with all this is that it we're now at a point where there seems to be some degree of stability, And it doesn't seem like Ruby Central is going to be inviting the folks who have left, including Andre, back into the fold anytime soon. It doesn't seem that Andre and co are going to take control over RubyGems, GitHub.org, or whatever anytime soon. ([Time 0:16:37](https://share.snipd.com/snip/f258a672-978e-4d8d-b918-185d03b10c64)) - **Money And Contracts Drove Tightened Access** - Budget changes and removal of paid on-call work precipitated stricter access controls. - Ruby Central sought contracts and agreements to formalize operational access after an August exchange. Transcript: Justin Searls Regardless of the actual mechanics and what that would look like, it was pretty clearly not something in the privacy policy currently or the terms of service. And so that email is received on August 3rd. And then it looks like the board and leadership team. And I'm imagining now, and this is just speculation on my part, Shan is executive director, who's not, you know, still trying to get her bearings and trying to button the stuff up probably Sees that as like, and this is the person who has all of the access to all these systems and could just take it anyway, and is upset that, you know, we're cutting the budget. Like, that's probably the precipitating event. And that's how they characterize it in this email of the thing that leads to, we got to tighten up the security and these accesses and get to, we don't have an operator agreement signed For all these people who have the, you know, operational access. And we don't have committer license agreements for all the people who are committing to this code base and could cause, you know, disputes later. And so we got to get those in place. So like first cut everyone's access, get the agreements in place, and then we can start to rebuild on a, you know, firmer footing is my understanding of the timeline. ([Time 0:24:48](https://share.snipd.com/snip/1ecfc224-e5a5-4589-adf1-415f877af225)) - **Funding Changes Incentives And Governance Needs** - Large influxes of money change incentives and create governance complexity in open source. - Projects need mature governance, transparency, and nonprofit experience to handle paid maintainers safely. Transcript: Mike McQuaid But notably, Homeward does not have a dedicated nonprofit. We do not have any dedicated employees or anything like that. We have an open collective which essentially if you've never used open collective before is like a online banking app but is in the spirit of open source public right so you can go and See two homebrew maintainers went out for lunch about a month and a half ago in Singapore together as our expenses public docs say that they do and they had lunch they talked about homebrew And they expensed that to the project and we i approved that expense right so like essentially all the money coming in and out of the project you can just go and look right with without Even logging in and see like what's going on here you can't see people's specific receipts with their credit card numbers for hopefully obvious reasons but the thing i i struggle with With a lot of this stuff is right like okay like homebrew and ruby gems would be going for about the same amount of time i ruby gems has definitely received dramatically more money in that Time i would bet than homebrew it would surprise me if it was as little as 10x more than homebrew but yet we a group of volunteers scattered around the world have been able to have transparent Governance transparent finances for like five plus years and you know i appreciate like this is all part of a kind of tightening process and whatever but i the thing that to me that all Of these kind of blog posts and a lot of the discussion is missing is like okay who got what money from who and when right like that goes as far as Ruby Central employees Ruby Central board Members Ruby Central contractors it goes like you know there's been a lot of conspiracy about like how much Mike Purim like has provided or removed funding DHH has provided or removed Funding Shopify has provided or removed funding right and I don't even want to speculate on one of those because i don't know what's true or not true but the thing i find slightly depressing About it all is like it would be very easy to have all that information be at least semi-public right but it's not so it becomes like an exercise and i do think again like with the like what Access andre had to what and when and how and whatever i also think again what i said earlier about the open source maintenance or you nothing thing it's like at that point is he an unpaid Volunteer working on a service right and providing that to the best of his abilities like if i certainly think from the accounts we're looking at had Andre never received a cent from Ruby Central ever, I think you would read his narrative and be like, that is 100% defensible, like what he did. And Ruby Central are 100% of the wrong because they are a well-funded organization with full-time employees who, like, sorry, the bar is just much, much higher for them than it is for Unpaid volunteers. ([Time 0:26:51](https://share.snipd.com/snip/2d68861c-87ab-42c8-8ea9-295413c263a6)) - **Treat Open Source Income As Supplementary** - Don't assume sponsorships or tips will make open source a reliable full-time career. - Build complementary income (consulting, employer support, product work) rather than depending solely on donations. Transcript: Mike McQuaid And I think the shortest, pithiest version I got was like, open source is not a career, right? Like, and what I mean from that is that I think there's plenty of ways to be an open source maintainer and make a lot of money, right? Like I've done fairly well for myself financially. I have had some doors open for me that would not have been opened otherwise were it not for my open source work, for sure, right? I mean, arguably, maybe bar my first job out of university, college, whatever, like, I think every other job, my open source maintenance has influenced me getting that job. But also, every other job has never has my paid main work been working on open source right like that and particularly working on homebrew right like i've right when i was at github i was A girl for 10 years i had like a couple of months in which i was you know given permission to help migrate us urgently from bin tray to uh github packages right and i i worked on a bunch of internal Code for that i went to a bunch of external code for that in homebrew but like bar that like that was not my job i i did homebrew stuff in bits of spare time in evenings and weekends in time Between meetings whatever it may be right and that was not what i was paid for or promoted for or whatever, right? I built stuff internally, right? I guess not unrelatedly, I was one of the first people to, first four engineers to build GitHub sponsors, right? So that was an interesting thing for me because it was being on the front line of like, well, what happens if we put a bit more a bunch more money into open source and i think like github sponsors Again it was telling because if you looked and a lot of this is all public knowledge right if you look at the people who have made the most money out of github sponsors they are not the best Open source maintainers and they would not be offended in me stating that they are not the best open source maintainers they are the people who have done the best job selling themselves And selling something which other people value through github sponsors as like a payment provider essentially right and good on them that's that's great that they do right but but There's a lot of people myself included who just slap up a github sponsors right like i do a lot of homebrew stuff and have done for 16 years. My monthly GitHub sponsors payment is $22 a month, right? That's not me going and saying, I want to get a bunch more. I get, you know, a bit more than that. I get $300 a month from homebrew as like our kind of maintainer stipend. But, you know, the reason why I don't get a load of money that way is because I have not dedicated time and energy into building essentially a sales process for my sponsorship pipeline And that's how it works right if you want to be an open source maintainer that gets funded primarily through sponsorships and money and whatever it doesn't look like a tip jar it looks Like you are now running essentially like you know in the same way that other influencers might have an influencer economy or whatever and there's various routes of making that money And paying those bills and getting that open source work right but there's not a single easily treaded path that is not without compromises and it makes me very cross to see a bunch of Particularly younger maintainers being told like no this is the way. If you follow this, you will both be rich and you can work on whatever source you ever want whenever you want. Right. That's just a lie. ([Time 0:36:33](https://share.snipd.com/snip/42f99d63-1f9a-47ce-a26e-b5e7dc7bec4e)) - **Scratch Your Own Itch First** - Solve your own problems first: build open source tools that help your paid work. - Use employer benefit as the primary incentive, then share the solution publicly if useful. Transcript: Justin Searls So they'd say, Hey, how do I break into open source? And I'm like, that's a real weird goal. Cause like I do open source because i'm trying to get something done that makes me money like working out for a client and like we got a you know the first real project i did was like i was A java client and like we had a whole lot of javascript and no way to run tests against it in ci and i was like that won't do and so like started unit testing our javascript with jasmine like Locally well how do you get that running in ci i was like oh i had to figure out a you know this is back in 2010 or whatever like run uh a pseudo html and javascript like fake environment in A java runtime and and then make a maven plugin that we could incorporate into the build like and i did that on my own time on a weekend or, you know, late at night or something. And then I just plugged it into the client code the next day. Right. Now, here you go. A gift free of charge because it makes my life easier at work and we're going to ship your code better. Right. And almost every one of my open source projects was that it was, I have a job that pays me money. That job would be massively improved in terms of the outcomes or my life at that job by writing some open source. So I'm going to solve my problem and I'm going to make it open because that's that's easier than getting approval to make it closed internally. Right. Like if I if I have some like, you know, asinine idea for how I can make things a little bit better. Forgiveness is way better than permission. Maybe it won't work. Like why, why would I fight for like budget and time to go on some, you know, escapade to like, Hey, I can vaguely improve things in a way that you don't understand when I could just go on My own GitHub, publish something publicly, and then go and consume that at work. And if it turns out that it's useful, then work is happy to like, let me spend some hours building it because then I've got a virtuous, you know, I've got at least one person depending on It and that's the person paying me. So then I can keep working on it a little bit and make it a little bit better, respond to issues and feedback. ([Time 0:42:23](https://share.snipd.com/snip/fea86cb0-9f7b-488a-9791-c784595c78c0)) - **Intrinsic Motivation Outlasts Funding** - Intrinsic motivation often sustains long-term maintainers more than external funding. - Many top maintainers started from passion, not sponsorship or training. Transcript: Mike McQuaid That's the thing, like for me, genuinely open source for free as a hobby is a beautiful thing. Like, and we should think very carefully before we decide to kill that by either paying everyone which won't happen or by making people who aren't being paid feel like they are being Exploited right like i again it really me off no end when you have people often with minimal involvement in open source themselves going around telling open source maintainers big Companies are exploiting your labor and i said well if only there was a way to get a big company to pay me to write software for them oh wait we have lots of that but the reason why lots of people Including me enjoy open source software and have continued to work on it for a very long time is it's like I don't have an engineering manager or product manager or technical project Manager being like, please sign your TPS reports. When will this be done? Is this a yellow T-shirt or a green T-shirt sized project? Like being able to just opt out from all of that bureaucracy is, you know, that bureaucracy is important and necessary sometimes, but it's also nice to not have to do that. Right. And when you don't have to do that, you can operate in a different way and work in a different way. And that's fine. And again, we go back to the open source maintainers owe you nothing, where it's like if someone doesn't like it, like, I mean, there's legitimately issues on Homebrew that people file. And it's like, this a legit issue but you're being a head about it so i'm just going to close your issue and when they're like oh but then i'm like well tough tough luck i can do what i want Right but if i'm a paid employee and if that person is a paid customer right in some companies you can do that right sure right but that's not terribly advisable. And I think this goes back to what we were saying about perverse incentives and like who gets paid and who doesn't get paid. It's like, well, open source maintainers owe you nothing. Sure, people who are being paid to do something owe someone something, right? Right. And again, in Homebrew's case, we specifically do, we have like all open tooling and open documentation and blah, blah, blah. And we pay maintainers that hit a certain threshold, $300 a month. We call it a stipend. There are people for whom I'm sure the average, you know, American child delivering newspapers, if that's still a thing that happens, like is making significantly better hourly wage Than some of these open source maintainers are but it's fine because that's just a token amount for appreciation for them right and we're not like but even then we have had it's not we've Not done anything publicly or whatever because we try and in homebrew do a reasonable job at keeping some of our drama behind closed doors but even in that case for a very small amount Of money we had a person with a very well-paid day job who was doing the wrong thing essentially because they wanted to hit a threshold to get an extra 300 bucks a month right and that made Us reconsider how we do this stuff but to go way back to something that justin said right at the beginning right like about you know he did open source to solve his own problems right went Back when i got involved first with open source in the heady days of the linux desktop back in like 2007 when i did my first google summer of code and met a lot of these kde people and i was Like a linux guy like the thing that people used to say all the time then that i never hear anyone say now is open source is about scratching your own itch right and what people meant by that Then was like open source is primarily about solving your own problems and then releasing it in a way that other people can benefit from you doing that right and that's why I did it and It's why I do it because when I work on homebrew and I make homebrew a little bit better it's usually because something in homebrew annoys me and i use homebrew therefore i make it better And that's completely the opposite from the attitude justin was saying of like how do i break it into open source it's like well whenever anyone's asked me that i'm like well find a tool That you use find something annoying with that tool and then go fix it right and they're like oh but you know i don't know javascript yet or i don't know this or i haven't contributed to That code base or i can't find a mentor or whatever. And again, as we're being a bit more spicy on this podcast, it's like, well, congratulations, you lose. You're never going to be a successful open source maintainer. I've never seen someone who's been a good open source maintainer who has been taught into being so, or encouraged or given enough money that they kind of finally get over a line or whatever. That helps people contribute, and it's great, and we shouldn't discount that as being a thing that we do for some people sometimes. ([Time 0:46:46](https://share.snipd.com/snip/fc453b85-6b82-474a-9206-51231e8a3a48)) - **Monetization Can Kill The Hobby Flame** - Monetization changes relationships and can destroy the hobby joy that sustains projects. - Turning passion into paid work often introduces bureaucracy and stress that reduce long-term happiness. Transcript: Mike McQuaid Me, it's not even monetization versus not, it's like direct monetization versus indirect monetization. Right. And I, sure i can't remember what it was i'm sure it's some much wisened old philosopher or whatever who said this i'm going to paraphrase it and butcher it horribly but basically like The idea of like the best things in life are achieved indirectly right so like let's not be overly crude uh i'll try and be relatively diplomatic but basically you know for example if Your goal is romantic companionship right there's ways of getting elements of that very quickly in exchange for money right but most people would say that actually that's probably Not the most fulfilling long-term option and the most fulfilling long-term option you know i've been with my now wife for 23 years like we have a perfect marriage and relationship i'm Very very happy that takes a lot of time and effort right and again i i have almost like a pending blog post brewing about just being patient feels like it pays a lot of dividends on this Stuff like i was at github for 10 years i've been with my wife for 23. My best friend who comes around to my house, we're currently watching Alien Earth. It's very good. We've been friends- Right now you're watching it? Well, I mean, not right now because I'm on a podcast. Jerod Santo Okay, well, you said your best friend coming over and you're currently watching Alien Earth. I'm like, dang, this guy can multitask. I'll do my best to multitask. Mike McQuaid But yeah, I mean, we've been friends for like 30 years right and most and homebrew for 16 years like most of the good things in my life are things that i have done for more than 10 years right And there has been ups and downs in those times and there's been times where if you were to look at some tiny microcosm of like the first you know months or weeks or whatever or a particular Segment you'd be like oh well this isn't worth it i'm gonna bail i'm gonna quit i'm gonna move on right but again like all of these things are things that i've got and i've have made me very Very happy and i'm delighted with not because i wanted to make as much money as possible or have as much whatever as possible human relationship interaction whatever but just because Like i enjoy the process going along and i still enjoy the process going along and that tends to get you to a very good place if every day you enjoy your life and you keep doing that and keep Enjoying your life and at the same time you know stuff like money you're like okay well i need to pay the bills i need to make sure that i make enough money to provide for me and my family and Whatever but you're also really excited about what you're doing then that tends to work pretty well and if you go and chase like maximum financial return for anything right on the short-term Basis like okay you might make a bunch of money like often you don't but you're probably going to be miserable in the longer term. And you're going to be like, why am I doing this? And I need to quit and whatever, right? ([Time 0:54:06](https://share.snipd.com/snip/8a6a396c-af39-49b3-89c5-320e9d1ad5d5)) - **AI Lowers First-Pass Coding Costs** - AI agents and Copilot-like tools are shifting who produces first-pass code and lower the cost of boilerplate work. - Maintainers may shift to reviewing and refining AI-generated contributions. Transcript: Mike McQuaid So i mean it's funny because a lot there's a lot of copilot related stuff i was one of the first people to test an internal beta of that it's alpha technically um and the reason why lots of People inside github would like me to test things is because i seem to be allergic to telling people that things were good when I thought they were a heap of shit even when it was strategically And politically advisable for me to say like this person's pet project is wonderful and so yeah my feedback on Copilot pretty early on was like wow this is surprisingly not a piece of Shit like when you describe I mean you have to remember like when Copilot came out before ChatGPT and stuff, right? Or at least it was being alpha'd before that. So this sounded, like, ridiculous, right, that we would, like, use AI, whatever. And I was like, wow, this is a better auto-completion for Ruby than I've ever seen using any ID or indexing or whatever, right? And it immediately made me more productive. So fast forward to the kind of Copilot coding agent stuff. Again i saw the kind of memes on hack and use of like microsoft employees being encouraged or forced to use this publicly and it just being an absolute disaster and i was like lol i'm gonna Try this out and again like maybe because umbrew has borderline fascistic issue templates that demand everything of you and essentially like force you into mike mcquade's opinionated Way of how you file a bug right but if you follow that template properly it's actually really great context for an lm particularly when it has all the comments of us discussing it right And i i basically just i think a couple months ago assigned every bug in the homebrew package manager to copilot agents and then you know it took a couple of weeks some of them got their 99 percent their first time some of them got 50 percent of the way and i finished off a lot of the stuff but like essentially in two weeks those were all fixed right and you can go and look At the public record and see how well that went or didn't go or whatever but like anyone who says like this stuff is not productivity boost is like in any circumstance is massively kidding Themselves and the awkward reality of it again back to the conversation is i would say is copilot agent great does it avoid hand-holding no definitely not is it better than the standards Dried by a homebrew contributor jury's out right it's certainly comparable and i i definitely think at this point like the first iteration of pr i would struggle to tell the difference Between co-pilot and a first-time contributor right a homebrew maintainer and indeed myself who's worked on homebrew longer than anyone else will do a much better job but even then Like, I find myself leaning on it because sometimes it's like, there's 10 ways of fixing this. Copilot, go f***ing pick one, right? And whatever mess you make, I will clean that up and get it over the line. But it's that, like, empty page problem. ([Time 1:24:55](https://share.snipd.com/snip/2e142f4b-0a81-4266-8deb-9f3c27d1d452)) - **Pay For The Tedious But Critical Work** - Fund the boring, tedious maintenance and security work rather than only rewarding visible features. - Prioritize funding or automation for supply-chain and reliability tasks that volunteers avoid. Transcript: Mike McQuaid Like if we have a team internally or we have LLMs that mean that we don't have to pay this tax, then maybe that's what we do now. Justin Searls I've seen some people on the internet be critical of like in way back to this ruby central that organization we're talking about at the beginning of this conversation it kind of incited This back and forth that shan the new executive director is not technical and not from technical communities but rather is like more there for her non-profit experience you know i i Remember Ruby Central was just Ben and Evan, and then they added Marty, like in 2012 or whatever. And it was just the three of them as the chair people, I guess. And all Rubyists, all programmers, and that felt right. And back then, in that era that we kind of keep hearkening back to the writing of the code, the building of the tool that like, you know, the brilliant API and the, just the, the, the blood, Sweat and tears to get it over the finish line at a high enough level of quality, whether it's a CLI or whatever it is, a library. And then to publish it, that was like where all the action was. That was the work. That was the thing that required brilliance. And that's what the market was, you know, rewarding so handsomely in terms of great tech salaries. If it's the case that it is now no longer, you know, an incredibly rare thing to have capacity for writing replacement level, decent code, that means everything else now is more valuable. So to mike's point if i'm run if i'm operating a service and you know jared was scared he said he said he bleeped it out no i'm kidding i believe the whole i must have bleeped the whole sentence Out because i don't remember i want a more bleep uh uh more bleeps for a minute i want to beat mike i was lying earlier i do want to be oh gosh he's got you down he he does but like if i if i'm running A service and i'm going to be scared you know bleepless to have uh uh a root level security event occur at the place that i'm downloading all of my gems which could then be root kidding my Computer for all of i know for i don't know what what it was 12 days. Like I'm actually really glad that the executive director has a, like the hat on now to finally like shore up the governance, make sure that like their regulatory and their, their finances And their tax situation is all buttoned up. And probably I think at the end of the day, we'll probably end up being much more transparent than they've been in the past, which was just the result of negligence, I'm sure, and not malevolence Up to this point. Like those are actually the skills that are more valuable because you can't just easily replace them. It requires good judgment and diligence and like experience and oversight. So like, you know, of this is a story of just an organization maturing, but I think part of it is also like a reflection of like the change in what's, what's valuable and important right Now. And as you look at open source or your conversation with Feras, which I thought was excellent, you know, Feras is a real smart guy. This is where the new locus of, of, of, of control goes when, when the writing of the code is no longer the most important thing. ([Time 1:30:01](https://share.snipd.com/snip/3cdff719-099b-44c4-86e2-11744ed25646)) - **Choose Sustainable Participation** - Prioritize personal sustainability: do work that keeps you happy and able to continue long-term. - If open source harms your well-being, step back or quit to preserve health and productivity. Transcript: Mike McQuaid Well, I guess in some ways I would divide the statement in two right so from the open source side of things do open source if you want to do open source right if you don't want to do it anymore Don't do it anymore this is when like when this podcast gets published and like 99 of open source maintainers quit and we have a world crisis i'm like oh well but like genuinely like and We i very strongly encourage people in homebrew to be like hey the day you're not using homebrew anymore thanks for all your work stop using it move on get on with your life there's been People kicked out of homebrew who are doing a good job but clearly homebrew has been very bad for their mental health so we kicked them out of homebrew, right? Like ultimately this stuff needs to be fun and it needs to be something that you enjoy. And if you care about sustainability and burnout and open source, you want that stuff to be better. Like go, you know, if you're an open source maintainer, go get some therapy, right? You probably have some you need to deal with, like chances are. ([Time 1:35:53](https://share.snipd.com/snip/50bfe034-ca83-4fb1-ad6c-03eb316d8957)) - **Ruby Core Takes Stewardship Of Gems** - The Ruby core team decided to assume stewardship of RubyGems and Bundler to ensure long-term stability. - This move aims to centralize stewardship under the language maintainers after the dispute. Transcript: Jerod Santo Bundled with the Ruby language for many years and functioning as part of the standard library, despite this crucial role, Ruby Gems and Bundler have historically been developed outside The Ruby organization on GitHub, unlike other major components of the Ruby ecosystem. To provide the community with long-term stability and continuity, the Ruby core team, led by Mats, has decided to assume stewardship of these projects from Ruby Central, end quote. He goes on from there, lots of details, link in the show notes. ([Time 1:39:45](https://share.snipd.com/snip/fc440ef0-0536-4a43-9236-c69e4e791e36))