Jakson Securing Ruby's Future: Open Source Sustainability and RubyGems Innovation täydellinen litterointi

--> 00:01:59.359 It's interesting as you talk about that history and where it stands today. 00:01:59.519 --> 00:02:02.879 And we're going to get into RubyGems and the security work that you do. 00:02:03.120 --> 00:02:06.079 It seems like at least two full-time jobs that you're taking on right now. 00:02:06.159 --> 00:02:11.199 Is there any future plans for either replacing you at one or the other position? 00:02:11.520 --> 00:02:11.840 For sure. 00:02:12.159 --> 00:02:16.800 I joked for a while that I actually had three jobs or four jobs, depending on how you looked at it. 00:02:16.960 --> 00:02:21.840 Maybe not all of them are full-time, but it definitely is more than one person can do. 00:02:22.080 --> 00:02:33.919 It's been an exercise in delegation, in saying no or deferring work and really getting clear on what's the most important thing to get done to accomplish. 00:02:34.159 --> 00:02:37.280 Unfortunately, as the boss, that doesn't mean writing code. 00:02:37.360 --> 00:02:44.000 That doesn't mean running scans, as we'll we'll talk about, and other kind of more interesting things. 00:02:44.240 --> 00:02:55.439 One of the, I would say, surprising or kind of neat aspects of my job that may not be clear is I also run product, which you might think, product? 00:02:55.599 --> 00:02:56.400 That's weird, Marty. 00:02:56.479 --> 00:02:57.599 Like you're a nonprofit. 00:02:57.680 --> 00:02:59.120 Why would you think about product? 00:02:59.280 --> 00:03:06.240 Well, when I came into the role of overseeing Ruby Gyms, the first thing that was pretty clear is we have a money problem. 00:03:06.960 --> 00:03:12.400 This is a mission critical service that serves Ruby programmers around the world, and it's free. 00:03:12.560 --> 00:03:13.520 No one pays for it. 00:03:13.680 --> 00:03:14.960 Yet it's not free. 00:03:15.120 --> 00:03:18.319 It costs money, it costs staff to oversee it. 00:03:18.479 --> 00:03:28.800 It's sort of been in this just do what you can with what you have and leverage volunteers and people working weekends and nights to make it happen. 00:03:28.879 --> 00:03:30.159 And I'm like, that's not right. 00:03:30.240 --> 00:03:30.479 Right. 00:03:30.639 --> 00:03:36.159 We have to look at sustainability and rethink how we fund this service and how we operate it. 00:03:36.400 --> 00:03:37.919 First of all, I think you're 100% right. 00:03:38.080 --> 00:03:46.400 One thing that I want to understand a little better, or I want to hear from you, and you've told me that you've gone to the open source conference in Nova Scotia. 00:03:46.479 --> 00:03:48.479 I think you were there again this past September. 00:03:48.560 --> 00:03:49.039 Is that right? 00:03:49.439 --> 00:03:49.599 Yeah. 00:03:49.840 --> 00:03:55.360 What are the other open source languages doing with similar package management, similar situations? 00:03:55.759 --> 00:03:58.719 Turns out we're all in similar situations. 00:03:58.960 --> 00:04:01.439 Different foundations have different funding models. 00:04:01.599 --> 00:04:06.000 If you look at like Linux Foundation, they have a lot of corporate backers and they have plenty of money. 00:04:06.240 --> 00:04:07.360 They're very, very large. 00:04:07.599 --> 00:04:16.639 If you look at, say, Rust Foundation or Python Software Foundation or PHP Foundation or a number of these other foundations, Software Foundation, they have a similar problem. 00:04:16.800 --> 00:04:18.560 We're like, how do we pay for all this? 00:04:18.720 --> 00:04:20.720 And many of them operate their own registry. 00:04:20.879 --> 00:04:24.879 Thankfully, we don't have the scale that some of the other registries do. 00:04:25.040 --> 00:04:26.639 I feel very much for Pype I. 00:04:26.800 --> 00:04:27.759 They're getting hammered. 00:04:27.920 --> 00:04:28.079 Yeah. 00:04:28.240 --> 00:04:38.000 Uh MPM, although that's not open source sort of free registry, but there's a lot of problems at scale that we don't have to the degree that they have. 00:04:38.160 --> 00:04:42.240 But the fundamentals are still the same that we have to think about how we fund it. 00:04:42.319 --> 00:04:47.680 And there's actually a working group, the package registries working group, that is working on sustainability. 00:04:47.839 --> 00:04:52.480 And so, how as a collection of registries, how do we pay for our services? 00:04:52.639 --> 00:04:56.079 How do we pay for the staff and all the work that goes into it? 00:04:56.240 --> 00:05:05.680 And I think what was surprising to me when I stepped into this role was that there's a lot of things you have to think about that I never thought about before. 00:05:05.920 --> 00:05:17.040 And as I started to get connected to peers around other ecosystems, I was able to like talk through how they're approaching things and realize that we have a lot of the same problems. 00:05:17.120 --> 00:05:23.439 And so this working group is talking about sustainability, and part of it means you have to pay for the registries one way or another. 00:05:23.600 --> 00:05:36.000 And maybe that means there are limits, maybe there are paid accounts, maybe there's some sort of funding model where companies that depend on it pay for services or for better access or unlimited access. 00:05:36.160 --> 00:05:42.480 There's no real easy answers because if something's been free for decades, how do you now charge for that? 00:05:42.639 --> 00:05:50.319 And also, like most all these registries, we want to make it so that anyone can publish a package in your ecosystem and that anyone can download it. 00:05:50.399 --> 00:05:50.639 Right. 00:05:50.800 --> 00:05:52.959 We don't want to put that behind a paywall or something. 00:05:53.040 --> 00:05:53.920 That doesn't make any sense. 00:05:54.000 --> 00:05:56.720 That's definitely not the way that the open source mindset works. 00:05:56.879 --> 00:06:04.319 And so it's like, how do you find that business model that works that still preserves the spirit of that?

00:06:04.480 --> 00:06:06.639 And so this is where that product side comes in. 00:06:06.720 --> 00:06:13.680 So, like, hey, are there things that RubyGems as a service could offer to publishers that they would pay for? 00:06:13.759 --> 00:06:14.639 They'd happily pay for. 00:06:14.720 --> 00:06:18.160 I think when I've had conversations with many of these companies, they're like, we would love to help. 00:06:18.399 --> 00:06:20.959 We would love to help support this, let us know how. 00:06:21.199 --> 00:06:28.319 But there's not a ton of those companies, and the amounts that they're able to approve aren't significant enough to pay for everything. 00:06:28.480 --> 00:06:28.639 Right. 00:06:28.879 --> 00:06:30.240 Now we do get a lot of donations. 00:06:30.319 --> 00:06:33.360 We do get donations and we get infrastructure donated, which is massive. 00:06:33.519 --> 00:06:39.439 So we have, I would say, around$300,000 a year in services that are comp to us. 00:06:39.600 --> 00:06:43.519 So Fastly, AWS, and Datadog are top three. 00:06:43.600 --> 00:06:49.360 They're all free for us, and they're very, very important to the operation of the service. 00:06:49.600 --> 00:06:53.680 I feel like most people, maybe that deal with package managers, are just like, I just want to download stuff. 00:06:53.839 --> 00:06:56.639 You know, that's all they think about in the early days of an organization. 00:06:56.720 --> 00:07:00.560 You just think, well, yeah, I just want to keep downloading stuff and updating stuff. 00:07:00.720 --> 00:07:15.040 And you don't think about maybe all of the other stuff that comes up as the next step, which is, you know, the security and really security of using that service that's shared with everybody else that just wants to download. 00:07:15.199 --> 00:07:24.639 I guess what I'm getting at is like, how are you thinking about maybe like a dichotomy of a system where the graduated users work their way through? 00:07:24.720 --> 00:07:27.839 I imagine there's a bunch of tiered products that come out of this. 00:07:28.079 --> 00:07:29.040 Yeah, yeah, definitely. 00:07:29.279 --> 00:07:43.920 As the different registers sort of navigating how to pay for this, one of the models that came forward was this idea of organizations, meaning a company account, an organization account, that you would put all your packages under, all your users under, and that could be paid. 00:07:44.079 --> 00:07:51.920 So maybe the free tier only allows you so many packages and so many users, or maybe there's some other way that you limit that. 00:07:52.079 --> 00:07:59.839 But as you are more of a consumer, or I mean, I guess in this case a publisher, and you want to publish more, then there's tiers that you could pay for. 00:07:59.920 --> 00:08:07.920 And PyPI actually rolled this out, and I think some others already have this, but an NPM has a similar model where there's a paid model you can pay for that. 00:08:08.079 --> 00:08:15.680 And so what I looked at

from a publisher standpoint is that publishers are more likely to pay, especially companies that have an SDK. 00:08:15.839 --> 00:08:20.800 This is their product, and they provide a Ruby gem that allows you to connect to use their service. 00:08:20.959 --> 00:08:27.759 They are a for-profit company, they make money, and they're a perfect customer for a paid organization as a publisher. 00:08:27.920 --> 00:08:30.480 Our biggest publisher is AWS. 00:08:30.560 --> 00:08:34.879 They have over 600 gems, and they are power users of our platform. 00:08:35.120 --> 00:08:40.720 Actually, the organization's feature, which we do have, it's in private beta right now, was funded by Amazon. 00:08:40.799 --> 00:08:44.159 They're like, we really, really need this because we have some serious pain points. 00:08:44.320 --> 00:08:46.399 If we give you a bunch of money, would you build this feature? 00:08:46.559 --> 00:08:48.399 And we're like, yes, yes, we will. 00:08:48.639 --> 00:08:49.279 You are right. 00:08:49.440 --> 00:08:50.720 That is definitely a need. 00:08:50.960 --> 00:08:56.399 Because you can certainly publish for free on RubyGems like you have for the past 20 years. 00:08:56.559 --> 00:08:57.200 It's fine. 00:08:57.360 --> 00:08:58.399 It works pretty well. 00:08:58.559 --> 00:09:00.080 Except for when you get to scale. 00:09:00.159 --> 00:09:01.120 There's definitely some pain points. 00:09:01.200 --> 00:09:11.039 And you have the API, you can drive stuff, but hey, what if we build, you know, an organization feature that makes this easy, that gives you unlocks abilities that you didn't have before? 00:09:11.200 --> 00:09:12.720 And how much would you be able to pay for that? 00:09:12.960 --> 00:09:14.159 I wanted to get into this as well. 00:09:14.240 --> 00:09:15.120 I'm glad you brought it up. 00:09:15.200 --> 00:09:17.600 The organization, so it's in private beta right now. 00:09:17.840 --> 00:09:20.399 It came out in the I think the change log mentions it. 00:09:20.879 --> 00:09:21.360 It's interesting. 00:09:21.440 --> 00:09:23.120 I did not know about the AWS angle. 00:09:23.200 --> 00:09:24.799 So they paid for it, they want some features. 00:09:24.960 --> 00:09:28.799 What is it that they're going to get or that any organization that signs up will get? 00:09:29.200 --> 00:09:35.600 So imagine changing permissions or user access if you have dozens or hundreds of gyms. 00:09:36.240 --> 00:09:39.039 You have to go into each gym right now and change that. 00:09:39.279 --> 00:09:39.679 I see. 00:09:39.759 --> 00:09:39.919 Okay. 00:09:40.159 --> 00:09:44.399 Wouldn't it be nice to say, hey, this is like the table stakes feature that everyone's like, obviously. 00:09:44.480 --> 00:09:53.039 Like I run a business, I publish gyms, and I want someone to have administrative control over all the gyms we publish. 00:09:53.200 --> 00:10:00.799 And I may not be the person who publishes, but I need to have control of that because it's my business and these

are you know the IP for my business. 00:10:00.960 --> 00:10:01.279 Sure. 00:10:01.440 --> 00:10:04.480 Now I can then give permissions, limit permissions. 00:10:04.559 --> 00:10:09.679 So they can't say kick people out because there used to be like there's owner or contributor, and that was it. 00:10:09.840 --> 00:10:13.120 And you need to be owner to publish, but then you can also kick everybody else out. 00:10:13.519 --> 00:10:13.759 Right. 00:10:13.919 --> 00:10:14.879 That's not good, right? 00:10:14.960 --> 00:10:19.679 So you can see a whole bunch of risk factors that from a business standpoint you would want to limit. 00:10:19.840 --> 00:10:25.440 And I think a lot of them worked around by we'll create a single like service account that we'll share. 00:10:25.519 --> 00:10:25.679 Yeah. 00:10:25.919 --> 00:10:28.399 And then we'll change access to if we need to. 00:10:28.639 --> 00:10:29.840 That's kind of clunky. 00:10:30.000 --> 00:10:40.799 And also, once you get into kind of like supply chain security and like trusted publishing, that you want some different ways of controlling access and permissions. 00:10:40.960 --> 00:10:43.120 Organizations is the first thing that works. 00:10:43.200 --> 00:10:49.759 For AWS, they have a gems team that oversees the publishing of all the gems for all their SDKs. 00:10:50.000 --> 00:10:54.320 But each gym has a service team in AWS, and these are not Rubyus. 00:10:54.480 --> 00:11:07.440 They know nothing, or generally speaking, nothing about publishing a gym, maintaining a gym, but they do know about their APIs, they do know what their SDKs need to do, and they own the content, if you will, of those gems. 00:11:07.600 --> 00:11:08.559 And this is all generated. 00:11:08.639 --> 00:11:11.279 They have a system that does all this, it's all automated. 00:11:11.519 --> 00:11:13.360 But there's a team that oversees all this. 00:11:13.519 --> 00:11:20.879 The pain points they had was trying to manage these 600 gems when you're not the publishers, but they have to oversee it. 00:11:21.120 --> 00:11:22.240 So that's one example. 00:11:22.480 --> 00:11:27.840 Another would be someone comes and goes, you need to change access, you want that to be nice and easy. 00:11:28.000 --> 00:11:30.799 So it's kind of similar, but it's all part of that, like table sticks. 00:11:30.960 --> 00:11:31.120 Yeah. 00:11:31.360 --> 00:11:51.039 Some other features around prefix reservations, which is the idea that the way we would do namespacing in a flat namespace, which is what Ruby has, let's say you want all gyms with the name AWS-SDK-whatever to be owned only by this organization, AWS. 00:11:51.360 --> 00:12:01.519 Prefix reservations is the way to say, hey, if you're gonna create a gym and an organization owns this prefix, then only that organization can publish that gym. 00:12:01.679 --> 00:12:04.000 Someone else would get an error and wouldn't be able to publish. 00:12:04.240 --> 00:12:04.399 Okay. 00:12:04.559 --> 00:12:14.799 So that's sort of like a security-esque feature where you know this is a known trusted publisher, you know it's AWS, they're the ones who should be publishing these official SDK gems. 00:12:14.960 --> 00:12:15.200 Great. 00:12:15.360 --> 00:12:20.320 Now you know that if this gym has this naming convention, it's going to be an AWS gem. 00:12:20.559 --> 00:12:23.840 That doesn't, of course, prevent anyone else from saying Bob's AWS gem. 00:12:24.080 --> 00:12:24.240 Yeah. 00:12:24.399 --> 00:12:25.919 Because I think I have a better way of doing this. 00:12:26.080 --> 00:12:26.399 That's cool. 00:12:26.480 --> 00:12:30.480 You can do that, but you can't call it AWS-SDK-whatever the service is. 00:12:30.639 --> 00:12:32.000 You have to come up with a different name. 00:12:32.240 --> 00:12:41.120 Without that ability, you could have people squatting potential names for gems that really Amazon should own, but they claimed it first or whatever. 00:12:41.360 --> 00:12:42.799 Valentina, why didn't we think of this? 00:12:42.879 --> 00:12:45.759 We both squat webs websites all the time. 00:12:45.840 --> 00:12:48.000 We could be squatting on gem prefixes. 00:12:48.080 --> 00:12:48.240 Yeah. 00:12:48.320 --> 00:12:49.440 It's such a missed opportunity. 00:12:49.759 --> 00:12:50.639 It's very true. 00:12:51.200 --> 00:12:54.799 You know, I I've thought about reserving RubyGem names for a long time. 00:12:55.600 --> 00:12:56.960 Man, well, now we missed our window. 00:12:57.120 --> 00:12:59.519 You know, I also don't want to get banned by RubyGems either. 00:12:59.600 --> 00:13:02.639 It it is against the terms of service, the abuse policy, so Yeah, 00:13:02.720 --> 00:13:03.200 Exactly. 00:13:03.840 --> 00:13:05.360 You know, I've read them. 00:13:06.960 --> 00:13:08.480 But at the same time, you know. 00:13:08.799 --> 00:13:11.679 What's stopping Amazon from just creating their own gem server? 00:13:11.919 --> 00:13:15.679 What value do they get out of RubyGems as like a trusted publisher? 00:13:16.080 --> 00:13:17.840 Anybody can host their own gem publishing. 00:13:18.000 --> 00:13:18.240 Totally. 00:13:18.320 --> 00:13:21.279 And it's set up as like Mike Perham as an example, like for a long time. 00:13:21.440 --> 00:13:23.600 I don't know if he still does it, but like for Sidekick. 00:13:23.759 --> 00:13:23.919 Yeah. 00:13:24.080 --> 00:13:25.200 Yep, for Sidekick Pro. 00:13:25.600 --> 00:13:30.559 What value is there from Amazon joining RubyGems as their like trusted publisher? 00:13:30.879 --> 00:13:33.840 I'm just curious to unravel maybe the organizational aspect of this. 00:13:34.080 --> 00:13:34.320 Sure. 00:13:34.559 --> 00:13:36.080 Why not just like roll up their own? 00:13:36.559 --> 00:13:42.720 They could, but do they want to get in the business of hosting a registry and managing its security and its uptime? 00:13:42.960 --> 00:13:44.320 That's the first question I would ask. 00:13:44.399 --> 00:13:54.559 And this is kind of

like the question you ask as a business of like, do you do everything internally, or do you maybe leverage a library or a service because it's not your core business? 00:13:54.799 --> 00:14:02.080 That's why SaaS is so popular and so useful, is that like I don't want to become the expert of all these things that I need to do for my business. 00:14:02.240 --> 00:14:07.600 If you're an SDK publisher, do you really want to have to have a team dedicated to hosting your own gyms? 00:14:07.759 --> 00:14:08.480 I'm guessing not. 00:14:08.639 --> 00:14:08.799 Yeah. 00:14:08.960 --> 00:14:09.759 So that's one angle. 00:14:09.919 --> 00:14:12.240 The other one would be it's the default. 00:14:12.399 --> 00:14:15.120 So you install Ruby or it's already installed in your system. 00:14:15.200 --> 00:14:17.919 You have RubyGems already installed because it comes by default. 00:14:18.000 --> 00:14:19.039 You want to install RubyGem. 00:14:19.440 --> 00:14:22.000 You don't have to say, hey, I wonder where that gym is located. 00:14:22.159 --> 00:14:22.799 Where's the source? 00:14:22.960 --> 00:14:23.440 Oh, here it is. 00:14:23.600 --> 00:14:23.759 Great. 00:14:23.840 --> 00:14:28.559 I mean, you could do that, but you can also just say gym install gym name and it's done. 00:14:28.720 --> 00:14:34.960 So there's a lot to this is the canonical package registry for the Ruby ecosystem, has been since 2004. 00:14:35.120 --> 00:14:35.360 Yep. 00:14:35.440 --> 00:14:37.519 You know, they're like, why make it harder? 00:14:37.679 --> 00:14:40.240 We want to make it easy as possible to install our gym and go. 00:14:40.480 --> 00:14:47.519 Honestly, it's a testament to it working to have somebody like Amazon leaning into the canonical format rather than rolling their own. 00:14:47.600 --> 00:14:50.000 Because I know that some have done that in the past. 00:14:50.240 --> 00:14:50.480 Yeah. 00:14:50.559 --> 00:14:54.879 I'm curious, kind of like to our next foray here of security. 00:14:55.039 --> 00:14:55.600 Yeah. 00:14:55.759 --> 00:15:00.080 Uh, which is kind of like the big reason to use RubyGems ultimately. 00:15:00.399 --> 00:15:04.000 And another reason not to start your own registry in 2026. 00:15:04.080 --> 00:15:04.240 You know? 00:15:04.639 --> 00:15:05.519 Where do you want to start here? 00:15:05.679 --> 00:15:20.000 Because there's so many facets of this topic of where security fits in in all the layers of the package management and how RubyGems and Ruby Central and all these organizations maybe fit into this faceting. 00:15:20.159 --> 00:15:21.120 What do you want to start with? 00:15:21.360 --> 00:15:25.840 Let me give you a high-level list of security-related items here. 00:15:25.919 --> 00:15:33.679 So the first one is security of the service, so that RubyGems.org doesn't get compromised and you can trust that it's doing what it's doing. 00:15:33.759 --> 00:15:34.000 Okay. 00:15:34.159 --> 00:15:48.720 Then there's supply chain security, which is sort of like when you install a gym, it is from the gem author you thought it was, it is the gem version you thought it was, that it hasn't been compromised in some way in that process, and that it won't be compromised in the future. 00:15:48.799 --> 00:15:58.159 And that's actually probably the biggest risk factor is what if Rails or one of Rails gems got hacked or taken over? 00:15:58.320 --> 00:16:07.360 That is actually a massive problem that has happened in the past, not Rails specifically, but other packages like XE Utils a couple years back. 00:16:07.519 --> 00:16:08.559 But there's plenty of those. 00:16:08.639 --> 00:16:16.639 And so from a supply chain security standpoint, we want to make sure that you're getting what you think you're getting and not something malicious or something else. 00:16:16.879 --> 00:16:19.279 And so that's another aspect of security. 00:16:19.440 --> 00:16:33.919 There's a fourth aspect of security, which is this idea of we're going to proactively scan and find malicious or vulnerable code that's out there and then try to fix it. 00:16:34.000 --> 00:16:46.879 And that's been sort of the big topic this year is with the rise of advanced frontier models, they're able to find vulnerabilities that you never thought could be chained together and yet they're figured it out. 00:16:47.039 --> 00:16:53.440 And we've seen countless examples this year of that in the Ruby community, in the Ruby ecosystem, as well as outside. 00:16:53.600 --> 00:17:06.880 And so in the start of the year, once the Mythos model came out, because that was the first one where they realized, Anthropic realized, oh wow, this model is able to go deep and find things you can't imagine. 00:17:07.119 --> 00:17:18.319 And so now this conversation started privately across these open source ecosystems and with the Frontier Labs that it's a matter of time before somebody finds these. 00:17:18.559 --> 00:17:21.680 So can the good guys find them before the bad guys? 00:17:21.920 --> 00:17:25.359 Because these models, they're not going to stay restricted very long. 00:17:25.519 --> 00:17:32.400 It's not in the best interest of these labs companies to develop this amazing AI model and then not let people use it. 00:17:32.559 --> 00:17:40.480 So how do you now roll this out if it's so powerful that it can find vulnerabilities and exploits in almost all the software we use? 00:17:40.720 --> 00:17:48.000 And so at the beginning of the year, or by spring, this was running rampant through all the open source ecosystems and we were talking about it. 00:17:48.079 --> 00:17:56.720 And so the Security Engineers and Resonance program that we started in May was funded to basically try to get ahead of the curve. 00:17:56.960 --> 00:18:15.440 That's fascinating because how do you build a system and a set of processes and work with humans and AI models to effectively go through the hundreds and millions of packages out there that we depend on in our software and patch it all so

that we don't get hacked. 00:18:15.759 --> 00:18:17.119 So thank you for that description. 00:18:17.200 --> 00:18:24.319 And I also was fortunate enough I went to the workshop that you and the other security engineers and residents put on at RubyConf at the last RubyConf. 00:18:24.400 --> 00:18:26.640 And I it was really educational, it was really well done. 00:18:26.960 --> 00:18:27.119 Thank you. 00:18:27.279 --> 00:18:28.960 So we saw this stat, this was in the change log. 00:18:29.200 --> 00:18:30.559 It was published recently. 00:18:30.880 --> 00:18:33.839 619 gems were prioritized. 00:18:34.000 --> 00:18:40.400 This is out of 200,000, which makes a lot of sense because it's like 158 billion downloads across those 619 gems, right? 00:18:40.480 --> 00:18:40.640 Yeah. 00:18:40.880 --> 00:18:45.200 317 were scanned by this multi-step system. 00:18:45.279 --> 00:18:50.799 And I've seen this in action that running multiple AIs, you know, dozens of tool calls. 00:18:50.960 --> 00:18:51.200 Yes. 00:18:51.359 --> 00:18:54.559 There were 134 findings that needed to be reviewed by humans. 00:18:54.720 --> 00:18:57.839 14 deemed legitimate and pretty nasty. 00:18:58.079 --> 00:19:01.359 First, can you tell us a little bit about some of the success stories? 00:19:01.440 --> 00:19:03.200 I know Ruby NTLM was an example. 00:19:03.359 --> 00:19:04.960 No Kugir, I think, was an example. 00:19:05.039 --> 00:19:05.200 Yeah. 00:19:05.440 --> 00:19:06.079 Tell us about that. 00:19:06.319 --> 00:19:12.000 I'll talk broadly about it because I'll tell you, as you can imagine, I'm not in the details as much. 00:19:12.160 --> 00:19:20.319 And so, like Deshaun or Colby or Patrick or Matt, one of the other, basically the seers, that's what we call them for short, that are working on this can tell you more. 00:19:20.720 --> 00:19:21.119 Great name. 00:19:21.279 --> 00:19:21.599 Yeah. 00:19:21.920 --> 00:19:24.480 Fun little acronym, yes, uh S-E-I-R. 00:19:24.799 --> 00:19:25.119 Yeah. 00:19:25.440 --> 00:19:29.920 The process is first of all, you have to prioritize because it takes tokens. 00:19:30.000 --> 00:19:31.119 It takes a lot of tokens. 00:19:31.359 --> 00:19:33.359 We don't have an unlimited token budget. 00:19:33.440 --> 00:19:41.119 We're all using basically the free counts, like they used to call Max, I guess they're called Ultra, and we have a pro count on both sides of Anthropic or OpenAI. 00:19:41.279 --> 00:19:46.400 And you can scam, but there's a point where you run out of tokens and you hit your limits and you have to wait. 00:19:46.559 --> 00:19:52.960 So there's very much a okay, we have basically 200,000 gems that we might want to look at. 00:19:53.279 --> 00:19:56.960 Maybe only 10,000 are relevant or depending. 00:19:57.119 --> 00:20:06.880 There's a long tail of like they become less and less relevant, but there's probably some system somewhere that still uses it and could be hacked, but you have to prioritize and be smart because you have limited resources and time. 00:20:07.039 --> 00:20:12.799 And so we basically said here are the top 1,000 gems that need to be scanned first. 00:20:13.039 --> 00:20:16.960 And Rails and its dependencies are pretty obviously top of the list. 00:20:17.119 --> 00:20:21.279 And the obvious gems like that already have been looked at multiple, multiple times. 00:20:21.359 --> 00:20:23.759 And of course, the Rails security team are already thinking about this. 00:20:24.000 --> 00:20:30.480 The Ruby security team is already looking at Ruby in its standard libraries, included gems that come with Ruby. 00:20:30.640 --> 00:20:36.480 But there's a lot of gems that are used heavily that go beyond that that they may or may not scan. 00:20:36.640 --> 00:20:41.039 And so essentially, so that's the first place pick a reasonable number and try to work through them. 00:20:41.200 --> 00:20:42.960 These scans take time. 00:20:43.119 --> 00:20:46.960 As Joe mentioned, the harness, by the way, the scanning tool is called Scrutinier. 00:20:47.119 --> 00:20:50.079 We can provide a link to you all to share with others if they want to go see it. 00:20:50.160 --> 00:20:50.880 It's open source. 00:20:51.119 --> 00:20:52.000 It has been developed. 00:20:52.079 --> 00:20:54.640 Andrew Nesbitt wrote it and has been working at it. 00:20:54.720 --> 00:20:58.559 It's got many contributors now, including our teams contributed a lot to it as well. 00:20:58.799 --> 00:21:08.400 Because ultimately, you're trying to efficiently work through thousands or hundreds of thousands of packages and managing the findings. 00:21:08.559 --> 00:21:10.960 Once a scan's been done, you have findings. 00:21:11.039 --> 00:21:15.599 Well, they need to be investigated and determined if they can really be exploited. 00:21:15.759 --> 00:21:20.640 Because sure that's a medium or that's a high, but maybe that gem doesn't get called that way. 00:21:20.799 --> 00:21:26.000 So there's this judgment call of like, well, how would you exploit this vulnerability? 00:21:26.240 --> 00:21:32.160 Can you actively take over a system or do whatever if that was installed like in a Rails app or whatnot? 00:21:32.319 --> 00:21:37.519 And so there's this determination of like, okay, here's the level of the vulnerability and here's how it could be exploited. 00:21:37.599 --> 00:21:41.519 And we have a proof of concept where we build, like, here's how you can actually do this. 00:21:41.680 --> 00:21:42.319 So that takes time. 00:21:42.400 --> 00:21:50.160 And so then a human does review it and looks at it, then determines is this something worth pursuing with a maintainer. 00:21:50.480 --> 00:21:56.480 Now you get into a very fascinating space, which is working with other humans about a vulnerability. 00:21:56.559 --> 00:21:57.759 They're not expecting this. 00:21:58.079 --> 00:22:04.319 Right now, everyone that's doing Doing open source out there is getting inundated with these AI slot reports. 00:22:04.480 --> 00:22:06.079

Some of them are good, some of them are bad. 00:22:06.240 --> 00:22:07.119 There's a lot of noise. 00:22:07.200 --> 00:22:08.559 There's just a lot of activity. 00:22:08.640 --> 00:22:09.759 So it's overwhelming. 00:22:09.920 --> 00:22:16.079 In our program, we like, how can we, in a humane way, reach out, make sure we're not wasting their time. 00:22:16.319 --> 00:22:21.039 Like, this is a legit issue that we think needs some attention. 00:22:21.119 --> 00:22:25.599 Now, it's up to the maintainer to decide if, like, no, actually, that's not a real vulnerability. 00:22:25.680 --> 00:22:31.119 It can't be exploited because of these reasons, or they're using the gym in a way that was never intended. 00:22:31.359 --> 00:22:38.559 So there's gonna be a conversation that needs to happen whether we all agree this is something that's severe enough to be addressed or not. 00:22:38.720 --> 00:22:40.319 And we leave it in the hands of the maintainer. 00:22:40.400 --> 00:22:42.799 Like it's their library, they're responsible for it. 00:22:42.960 --> 00:22:44.720 But they may not even be around anymore. 00:22:44.880 --> 00:22:46.960 Like that person maybe hasn't done an update in years. 00:22:47.119 --> 00:22:53.279 So there's some very interesting edge cases of like, what do we do as an ecosystem and as a registry if no one responds or whatnot. 00:22:53.440 --> 00:23:00.799 So then there's the process of like issuing an advisory, security advisory, and rolling through that process and then getting it patched and then getting it out. 00:23:01.119 --> 00:23:02.240 This is all really fascinating. 00:23:02.319 --> 00:23:09.279 And the thing that I was actually just latching onto at the very end there was yeah, there are a lot of gems that are not actively maintained anymore. 00:23:09.440 --> 00:23:17.759 And you know, you've talked about the top 1,000, some of which are already maybe being monitored by Ruby security team, rail security teams, et cetera. 00:23:17.920 --> 00:23:23.279 Maybe the AWS gems are actively being monitored by AWS, let's just say, as an example. 00:23:23.440 --> 00:23:25.440 But there's about 200,000 gems out there. 00:23:25.599 --> 00:23:30.880 And of course, not all of them are useful or in use today, but there's still going to be a whole bunch that are. 00:23:31.039 --> 00:23:42.079 And, you know, we used to have organizations, we kind of still do, that might take over gems that have been sort of forgotten, you know, were built and maintained for a long time and became very useful, but then we're kind of left alone. 00:23:42.319 --> 00:23:46.480 But what do we do as a community with all of these others that are sort of left out there? 00:23:46.640 --> 00:23:51.599 And now maybe they've been working, chugging along for some definition of working, but now there's some real security threats. 00:23:51.839 --> 00:23:52.319 Yeah, yeah. 00:23:52.400 --> 00:23:53.440 It's a great question. 00:23:53.599 --> 00:23:57.440 We have thoughts about it and we have some approaches so far. 00:23:57.599 --> 00:24:04.079 We did write some policies about how we would navigate this because we knew that there'd probably be some tough calls. 00:24:04.240 --> 00:24:10.640 Like if there's a really heavily used gym, no one is maintaining anymore, and there's a really bad exploit in it. 00:24:11.039 --> 00:24:13.279 Can we really not do anything? 00:24:13.599 --> 00:24:14.319 Probably not. 00:24:14.400 --> 00:24:22.079 And the policy, by the way, for RubyGems is that if there is significant enough security concerns, the registry will take action. 00:24:22.240 --> 00:24:22.480 Okay. 00:24:22.640 --> 00:24:23.519 We might remove a gem. 00:24:23.759 --> 00:24:24.799 I guess we could patch it. 00:24:24.880 --> 00:24:41.839 I don't think we've ever done that, but we've talked about like maybe in the extreme case, we would patch a gem on the behalf of the owner, and it'd be like an obvious security patch done by the Ruby Gym security team for this purpose, and we're not taking over the gym, we're not maintaining it, but we'll issue it. 00:24:41.920 --> 00:24:43.680 So there's kind of interesting cases there. 00:24:43.920 --> 00:24:49.440 Yanking is the obvious solution that we've had and used over the years. 00:24:49.680 --> 00:24:49.839 Yeah. 00:24:50.160 --> 00:24:52.960 It's like this is malicious, this is bad, it's getting yanked. 00:24:53.119 --> 00:24:53.279 Okay. 00:24:53.440 --> 00:24:55.039 We have yank requests all the time. 00:24:55.200 --> 00:25:01.039 I would say on a weekly basis, multiple times a week, we're reviewing and taking action behind the scenes for yanks. 00:25:01.359 --> 00:25:01.920 Oh, interesting. 00:25:02.079 --> 00:25:02.720 I did not know that. 00:25:02.960 --> 00:25:07.680 And also, as an author, you can yank to a degree your versions, but we have limits. 00:25:07.759 --> 00:25:15.039 So like once the ecosystem is depending on your gym version, we're not going to just let you yank it unless there is significant reason. 00:25:15.359 --> 00:25:17.279 We have plenty of customer service requests coming in. 00:25:17.359 --> 00:25:18.799 Could you please yank this version? 00:25:18.880 --> 00:25:20.400 It's got these issues. 00:25:20.880 --> 00:25:23.680 We do that quite a lot on the request of maintainers. 00:25:23.839 --> 00:25:25.119 Okay, so that's that. 00:25:25.279 --> 00:25:37.599 I will talk about another what I think is important as a registry, is that we provide metadata about the health and quality and state of a gym. 00:25:37.759 --> 00:25:45.200 So for example, if a gym hasn't been maintained or maybe has vulnerabilities, like now we do report on vulnerabilities. 00:25:45.359 --> 00:25:51.839 So you can see in the RubyGems UI that there are known vulnerabilities for a version or versions of a gem. 00:25:52.319 --> 00:26:01.359 And soon we'll have that roll out to the client so that as when you do like a bundle install, you'll be warned, or perhaps it will fail if there

are certain vulnerabilities. 00:26:01.519 --> 00:26:05.359 And I don't know where the GIMS team is in terms of that implementation. 00:26:05.440 --> 00:26:10.240 But the idea is that you will be an informed consumer about what you're consuming from a registry. 00:26:10.400 --> 00:26:18.799 And so that could extend to we will now roll out the ability to indicate a gym is deprecated or unmaintained or is not safe. 00:26:19.200 --> 00:26:20.160 Now you can see that. 00:26:20.240 --> 00:26:23.200 You can be informed and you can decide what you do about that. 00:26:23.359 --> 00:26:28.640 The classic model over the years was like, this was the gym that people used for this type of activity. 00:26:28.799 --> 00:26:30.960 And now there's a new gym that does it better. 00:26:31.119 --> 00:26:31.200 Right. 00:26:31.359 --> 00:26:33.119 And people migrate and they switch to the new gym. 00:26:33.200 --> 00:26:33.359 Yeah. 00:26:33.519 --> 00:26:36.160 That's fine to say, look, this gym had its heyday. 00:26:36.240 --> 00:26:37.039 It was a great gym. 00:26:37.119 --> 00:26:37.599 We loved it. 00:26:37.759 --> 00:26:38.319 Had a good run. 00:26:38.559 --> 00:26:39.119 Had a good run. 00:26:39.200 --> 00:26:39.440 Yeah. 00:26:39.599 --> 00:26:41.359 And now you shouldn't be using this. 00:26:41.519 --> 00:26:46.720 And as a registry, we can first of all empower our maintainers to share that status. 00:26:46.799 --> 00:26:49.440 And so if they don't want to maintain a gym, you don't have to. 00:26:49.599 --> 00:26:55.359 But you should be able to say that, and that the registry and anyone consuming gyms now knows it. 00:26:55.440 --> 00:27:03.200 And they can say, ah, okay, I will look for some other package to do this activity for my application, and I'll switch to it. 00:27:03.279 --> 00:27:05.119 And they're actively maintained, yay. 00:27:05.200 --> 00:27:08.480 Or it could also be this gym has lacked security practices. 00:27:08.720 --> 00:27:09.839 And I'm a little worried. 00:27:09.920 --> 00:27:11.759 They aren't trusted published or whatever. 00:27:11.839 --> 00:27:17.759 I'm worried that this could be taken over because you know the they don't have MFA enabled for their account. 00:27:18.640 --> 00:27:25.759 So yeah, so I think the whole passing along metadata in the the true state of a gym is something the registry needs to do. 00:27:26.079 --> 00:27:32.240 Is there a follow-up to that of providing some kind of signal to people that can subscribe to maybe metadata events? 00:27:32.480 --> 00:27:32.799 Yeah. 00:27:33.440 --> 00:27:35.920 So that they can be notified when things change. 00:27:36.240 --> 00:27:40.960 You obviously could find out through a bundle install or bundle update or something like that. 00:27:41.119 --> 00:27:48.160 But you might also want to be like, hey, we know you are using these gems, and one of the gyms you use has a vulnerability. 00:27:48.400 --> 00:27:51.119 We recommend you upgrade to version X right now. 00:27:51.279

--> 00:27:51.519 Right. 00:27:51.680 --> 00:27:55.839 Like I think that that sort of feature is something that would be really powerful. 00:27:56.000 --> 00:28:03.039 And so getting back to that product hat of like, hey, could there be a way where someone could say, hey, these are the gems I depend on? 00:28:03.200 --> 00:28:04.720 I would like notifications of this. 00:28:04.880 --> 00:28:07.359 Now we don't have something like that, but could we build it? 00:28:07.519 --> 00:28:07.839 Definitely. 00:28:08.160 --> 00:28:10.319 That's a service I know people already pay for. 00:28:10.799 --> 00:28:11.920 There are security companies that do that. 00:28:12.319 --> 00:28:12.559 They do. 00:28:12.880 --> 00:28:13.119 Yeah. 00:28:13.440 --> 00:28:16.880 Should the language ecosystem registry get in the business of that? 00:28:17.039 --> 00:28:22.480 Because there's a whole bunch of security companies out there that provide these sort of features on top of registries. 00:28:22.799 --> 00:28:23.839 Should we get in that space? 00:28:24.079 --> 00:28:28.160 Maybe this should be a uh Ruby AI podcast side quest. 00:28:28.640 --> 00:28:31.279 I can see this being the next thing that you have AI build. 00:28:31.599 --> 00:28:33.920 It's a metadata notifier proxy. 00:28:34.319 --> 00:28:34.559 Yeah. 00:28:35.279 --> 00:28:37.279 I like I like this idea for us. 00:28:38.000 --> 00:28:39.839 I mean, that does look we look trustworthy. 00:28:39.920 --> 00:28:40.559 I'm working out. 00:28:42.240 --> 00:28:42.799 Trust us. 00:28:43.039 --> 00:28:43.759 Trust us. 00:28:45.200 --> 00:28:46.640 Word of mouth is fine. 00:28:47.599 --> 00:28:53.440 You know, this makes me wonder like a lot of people love federation, Mastodon, and there's been a hype. 00:28:53.519 --> 00:28:54.880 I don't know if it's still a hype. 00:28:55.039 --> 00:28:58.079 From an organizational perspective, I mean you've seen it from the high level. 00:28:58.160 --> 00:29:05.279 Like, is there really value in like the language adopting a federated approach to some of these products? 00:29:05.519 --> 00:29:08.720 Or is it better to try and keep things in the organization? 00:29:08.960 --> 00:29:10.880 Where do things fall apart from that angle? 00:29:11.119 --> 00:29:16.720 Because a lot of people's answer would be just federate it and let people pay for it in a broken apart way. 00:29:16.960 --> 00:29:17.200 Right. 00:29:17.279 --> 00:29:29.839 There's I think most large software companies have a way of vendoring or keeping all their dependencies in their own, like an R factory type service, CloudSmith, that they're paying for. 00:29:30.079 --> 00:29:37.039 They trust that if, say, RubyGems goes away tomorrow or went down for a week, they could still deploy. 00:29:37.279 --> 00:29:39.039 They could still do all that. 00:29:39.279 --> 00:29:40.960 But how do you get updates? 00:29:41.200 --> 00:29:42.720 Think of it from an ecosystem standpoint. 00:29:42.799 --> 00:29:44.960 So Federation, I think, is great. 00:29:45.119 --> 00:29:47.359 I think there are probably some challenges with it. 00:29:47.519 --> 00:29:50.640 Certainly from a Ruby ecosystem standpoint, we support it. 00:29:50.880 --> 00:29:57.759 However, you're when you do a gem command, you know, it's gonna look for the default source and you can change that, but it's gonna go there. 00:29:57.839 --> 00:30:00.160 It's gonna go to one place, and that's a place you trust. 00:30:00.319 --> 00:30:01.920 So now, can we change that? 00:30:02.000 --> 00:30:02.240 Sure. 00:30:02.400 --> 00:30:08.960 But I think you still have an interesting challenge of how do you get updates to a package? 00:30:09.119 --> 00:30:12.880 How do you trust those updates so that part doesn't go away? 00:30:13.200 --> 00:30:16.880 Back to that second security problem of like supply chain security. 00:30:16.960 --> 00:30:22.720 And are you downloading and installing what you think you are installing and from the people you think you're getting it from? 00:30:22.880 --> 00:30:24.799 That problem doesn't go away with federation. 00:30:24.880 --> 00:30:26.640 And most likely it becomes harder. 00:30:26.720 --> 00:30:47.920 But there is a sort of advantage in RubyGems.org as a service that, like, if you trust us to do this right and we have the security precautions in place and the systems in place, you might rest easy knowing that it's unlikely that any of the gems we serve are going to be compromised because we have a team dedicated to that and thinks about that. 00:30:48.079 --> 00:30:54.640 So if you go to the federated model, would one of those endpoints, would they have the same security? 00:30:54.880 --> 00:30:56.880 Could they be compromised and now you're hosed? 00:30:56.960 --> 00:30:59.759 Because you thought you're getting the trusted gem and actually no. 00:30:59.920 --> 00:31:00.720 They said it was. 00:31:00.960 --> 00:31:02.400 Oh, trust us, it's fine. 00:31:02.559 --> 00:31:06.400 Now, there are definitely ways to build this uh cryptographically, you can verify things. 00:31:06.559 --> 00:31:07.359 Is the future that? 00:31:07.519 --> 00:31:08.319 I would hope so. 00:31:08.480 --> 00:31:18.960 From our standpoint, there's still this central coming together of people publishing in Ruby and people consuming that, and they know that they're getting the versions from the people they think they're getting. 00:31:19.200 --> 00:31:20.799 Yeah, I think there's a lot of value in that too. 00:31:20.880 --> 00:31:25.839 I think of it certificate authorities and containers, where the hub pulls from. 00:31:26.000 --> 00:31:37.680 There's so many similar things that are already already there, working the similar ways, and having a central trust of organizations that can be trusted amongst themselves is pretty critical. 00:31:37.839 --> 00:31:40.079 And it makes me think about crypto, to be honest. 00:31:40.400 --> 00:31:49.599 You know, there's the trusted chain, and you know, everybody keeps pushing onto

it as a mechanism to make sure that nothing is broken across the distribution of the network. 00:31:49.839 --> 00:31:50.000 Right. 00:31:50.160 --> 00:31:54.319 So, where do you see the greatest needs from like an organizational perspective? 00:31:54.559 --> 00:31:59.759 Is it still security and building out the product to keep the lights on? 00:31:59.920 --> 00:32:10.160 Or yeah, I think we still have a ways to go, although we're doing pretty well in terms of like the security features and the systems in place. 00:32:10.319 --> 00:32:12.559 We've come a long way over the last several years. 00:32:12.799 --> 00:32:15.759 It's been like we've had a lot of funding come in. 00:32:16.079 --> 00:32:18.240 Alpha Mega has been a massive partner. 00:32:18.480 --> 00:32:26.319 They're focused on security and open source, and they've been funding us for the last three years, and we expect that they'll continue to fund us into next year. 00:32:26.400 --> 00:32:32.160 But they're seeing the risks to ecosystems, and they support many, many ecosystems. 00:32:32.319 --> 00:32:34.480 And so I think that's helping dramatically. 00:32:34.640 --> 00:32:44.480 I think Shopify started the Shield program back in I think 2022, giving a quarter million each year to improve supply chain security in the Ruby ecosystem. 00:32:44.640 --> 00:32:46.960 And that's had a massive effect for us. 00:32:47.039 --> 00:33:08.240 So I think as an organization, when Ruby Together merged into Ruby Central and money started to flow in from foundations from companies, that it took it from like a best effort, it's fine, I guess, to oh, let's now think about a roadmap of reliability, of security, of sustainability, and let's start working towards that. 00:33:08.480 --> 00:33:11.039 And so we're multiple years into that journey. 00:33:11.279 --> 00:33:14.079 I think we're doing pretty well, but it's not all solved. 00:33:14.240 --> 00:33:18.799 I still don't have recurring revenue that pays for operations. 00:33:18.960 --> 00:33:26.799 So pretty much every year myself or someone else in this position has to go and find the money to fund everything for next year. 00:33:27.039 --> 00:33:39.039 It's difficult because I mean I I don't know how many of you, oh I mean Joe would, but uh Valentine, I don't know if you have the exercise of doing budgets and staffing and thinking about that for next year or for the future. 00:33:39.119 --> 00:33:44.319 And so you can imagine if like, how much money will we have to staff our services? 00:33:44.559 --> 00:33:45.680 Oh, you don't know. 00:33:45.839 --> 00:33:48.559 You have to figure it out and hope that you'll get there. 00:33:48.720 --> 00:33:50.319 And that's kind of how it's been. 00:33:50.480 --> 00:33:58.319 And so, like, wouldn't it be great if I knew, oh, for next year I have this much money, it's a reasonable amount of money, I can actually staff the services. 00:33:58.559 --> 00:33:59.599 That would be amazing. 00:33:59.759 --> 00:34:00.640 I don't have that. 00:34:00.799 --> 00:34:16.239 I am like, I think I'm like 80% sure these foundations, these corporations will fund us and we'll have that money, but that's not great to not have 100% certainty of that or higher certainty. 00:34:16.320 --> 00:34:24.000 And so it's like that's the whole like product revenue side is like, wouldn't it be great if the service generated enough money to pay for its own operations? 00:34:24.159 --> 00:34:26.239 Then I could easily do the budget process. 00:34:26.480 --> 00:34:26.800 Absolutely. 00:34:27.039 --> 00:34:36.079 Sounds a lot like the proliferation of the conference world where you're not sure if the conference is gonna make enough to cover what costs to run the conference until you get enough people to buy tickets. 00:34:36.400 --> 00:34:39.920 And then at that point, you've already made the reservations, or you get enough sponsors to sponsor. 00:34:40.320 --> 00:34:43.199 And of course, you know, as an organization, we live that world as well. 00:34:43.519 --> 00:34:53.280 And what people didn't know, or I'm sure we talked about it enough that people do know now, but for many years pre-COVID, Ruby Central made money at conferences and it paid for these things. 00:34:53.599 --> 00:34:55.519 So we didn't have to figure out how to fund it. 00:34:55.599 --> 00:34:58.559 And since COVID, since the pandemic, that's all changed. 00:34:58.639 --> 00:35:04.719 And so the organization's been scrambling to like, oh, now we don't have a funding model that is sustainable or functions. 00:35:04.880 --> 00:35:10.000 And so every year it's like, let's try this or let's you know make this plea or whatever it is. 00:35:10.159 --> 00:35:17.119 And so I think I would say now we're in a way better spot in the last five years than we've ever been. 00:35:17.280 --> 00:35:23.679 I can see where the next two years or three years goes to where whoever's in this role, and I hope to not always be in this role. 00:35:24.000 --> 00:35:26.880 Back to your original question, Joe, is do you see other people helping out? 00:35:26.960 --> 00:35:27.840 Like, absolutely. 00:35:28.000 --> 00:35:33.119 I kind of need money though, and reliable money before I'd ask someone to step into this role and do this. 00:35:33.360 --> 00:35:37.280 Because what do you mean you don't know if you have enough money next year to have the same staff? 00:35:37.519 --> 00:35:37.679 Yeah. 00:35:37.840 --> 00:35:42.559 Well, the head of a nonprofit, my experience, that person is typically trying to raise money. 00:35:42.639 --> 00:35:43.760 That's the biggest part of the role. 00:35:43.840 --> 00:35:45.599 It's a sales job in a lot of ways, right? 00:35:45.679 --> 00:35:47.199 Isn't that accurate here as well? 00:35:47.360 --> 00:35:48.400 Maybe more so than it used to be. 00:35:48.639 --> 00:35:48.880 100%. 00:35:49.199 --> 00:35:50.400 Also, I don't have a playbook. 00:35:50.480 --> 00:35:53.039 And also, I'm not a sales guy, and I've not done this

before. 00:35:53.199 --> 00:35:56.960 So you're uh engineering leader and you know how to build systems the right software. 00:35:57.119 --> 00:35:57.360 Great. 00:35:57.519 --> 00:35:59.360 Now, actually, that's not your main problem. 00:35:59.440 --> 00:36:01.039 Yeah, that's the easy problem. 00:36:01.280 --> 00:36:04.639 Here's the real problem going convincing people that you need to fund this. 00:36:04.719 --> 00:36:06.320 And like, so I'm learning so much. 00:36:06.400 --> 00:36:11.199 So, like the last two years, yeah, it's like, ah, now this is a skill I need to get better at. 00:36:11.280 --> 00:36:12.719 And oh, I need help with this. 00:36:12.880 --> 00:36:17.599 And so a lot of what I think about now is like, who can I have come in and help? 00:36:17.760 --> 00:36:28.800 Like they own this piece or they are helping me get better at this aspect that I'm not that skilled at, and then basically build the system, build the team, build the system so that it becomes easier. 00:36:29.119 --> 00:36:33.920 You seem like you can fit really well into a lot of different responsibilities and roles. 00:36:34.159 --> 00:36:35.920 What I see is it's a capacity problem. 00:36:36.079 --> 00:36:40.639 It doesn't matter how good you are at sales, you can't dedicate your full time to it because you've also got to run RubyGems. 00:36:40.719 --> 00:36:40.880 Right. 00:36:41.039 --> 00:36:45.679 That's gonna hurt us as people that depend on Ruby Central, you know, until such time as you can build up a little bit. 00:36:45.760 --> 00:36:49.440 And I know how that goes too, because I've I've run a big smoke company and I've run a small company. 00:36:49.519 --> 00:36:50.000 And guess what? 00:36:50.079 --> 00:36:50.800 They're the same company. 00:36:50.960 --> 00:36:52.960 You know, sometimes you just have to make do with what you got. 00:36:53.119 --> 00:36:53.199 Yeah. 00:36:53.280 --> 00:36:57.440 And then factor in like, what if you hired someone and they didn't work out? 00:36:58.000 --> 00:36:59.519 Think about the cost of that. 00:36:59.679 --> 00:37:05.840 And matter of fact, you can look at the last five years and you can see indications of that wasn't a great hire. 00:37:06.000 --> 00:37:06.800 That wasn't a fit. 00:37:06.960 --> 00:37:07.920 It didn't work out. 00:37:08.480 --> 00:37:12.079 And the cost of like how quickly do you react? 00:37:12.159 --> 00:37:14.480 And this is the whole like the advice fire fast. 00:37:14.639 --> 00:37:16.719 If someone's not a fit, you gotta get them out. 00:37:16.880 --> 00:37:17.119 Yeah. 00:37:17.280 --> 00:37:21.840 And sometimes we're too nice or we think, oh, it'll just give them time, it'll work out. 00:37:22.079 --> 00:37:22.559 Never works out. 00:37:22.800 --> 00:37:23.920 And you pay a higher price. 00:37:24.079 --> 00:37:24.320 I know. 00:37:24.480 --> 00:37:26.960 Like this point, I'm like, I would love to go faster. 00:37:27.119 --> 00:37:33.599 I would love to have that help, but I'm also I need the right people because if I bring the wrong person in, it's gonna cost me more. 00:37:33.840 --> 00:37:35.519 Yeah, and it costs you more right now, right? 00:37:35.599 --> 00:37:39.440 When the organization is small, the next hire is more critical than when it's large. 00:37:39.519 --> 00:37:45.760 You know, a large organization can recover quickly from a bad hire, usually because there are other great people in the door. 00:37:45.840 --> 00:37:48.159 And that right now you're small, and you know, I get that. 00:37:48.239 --> 00:37:49.360 The next person is critical. 00:37:49.599 --> 00:37:55.039 Well, when you look at Ruby Central as a whole, you've got Ruby gems, and it's all we've been talking about practically for an hour. 00:37:55.199 --> 00:37:55.360 Yeah. 00:37:55.519 --> 00:37:58.559 And then, you know, you've got the conference, which people still feel like is important. 00:37:58.639 --> 00:38:01.039 And I know we're at least going to have one in 2027. 00:38:01.119 --> 00:38:02.559 So I'm excited about that. 00:38:02.800 --> 00:38:07.039 What else would you say is in the mandate of Ruby Central? 00:38:07.280 --> 00:38:08.480 Yeah, I mean, that's a great question. 00:38:08.719 --> 00:38:14.559 So the organization started very humbly in that, like, it was really just created to it was to put on the conference. 00:38:14.800 --> 00:38:15.440 Put on the conference. 00:38:15.519 --> 00:38:15.679 Yeah. 00:38:15.840 --> 00:38:22.000 But they're like, look, you know, and they got a 501c3, by the way, which is virtually impossible to get in tech these days. 00:38:22.239 --> 00:38:24.159 Like to be a charitable organization. 00:38:24.400 --> 00:38:31.760 I don't know how many C3s are happening anymore in the tech space, but it's like the advocacy of the Ruby ecosystem, of its community. 00:38:32.000 --> 00:38:35.519 The board has like, here's our mission, our vision, all that sort of stuff. 00:38:35.599 --> 00:38:39.280 And we do in our paperwork, this is why the nonprofit was created. 00:38:39.440 --> 00:38:41.840 So we have to measure ourselves against that. 00:38:42.000 --> 00:38:43.519 Are we actually fulfilling our mission? 00:38:43.920 --> 00:38:45.360 What exactly does that mean? 00:38:45.519 --> 00:38:54.159 I think the conference works quite well that way because we are out there, we're promoting Ruby, we're supporting Ruby as an ecosystem. 00:38:54.400 --> 00:38:56.079 There are other ways we could look at that. 00:38:56.239 --> 00:39:03.119 Obviously, RubyGems as a service is critical in terms of like allowing people to install Ruby and sort of publish RubyGems. 00:39:03.280 --> 00:39:04.000 So that's great. 00:39:04.239 --> 00:39:12.639 You know, we wonder like, is there something around education or bringing in new programmers and helping them come up to speed on Ruby? 00:39:12.800 --> 00:39:21.199 You know, like that could very much be part of that type of supporting community organizations like you know, different local meetups

and regional conferences. 00:39:21.440 --> 00:39:23.760 Like that's also something we've supported over the years. 00:39:23.840 --> 00:39:25.920 And so I think that's pretty clear. 00:39:26.000 --> 00:39:27.440 But what else could there be? 00:39:27.519 --> 00:39:35.039 You know, is there an education component that we could start to get helping, you know, provide educational resources for writing Ruby? 00:39:35.280 --> 00:39:41.760 Is there other services that the ecosystem would do well if it had, if it was provided? 00:39:41.920 --> 00:39:42.400 I don't know. 00:39:42.480 --> 00:39:43.840 I think there's tons of potential. 00:39:44.000 --> 00:39:50.079 But I think with everything like this, it's like, okay, who's gonna own it, who's gonna get involved, who's gonna oversee it, what's it gonna cost? 00:39:50.480 --> 00:39:54.320 Both from a financial standpoint, but also people's time, volunteers' time. 00:39:54.480 --> 00:39:54.719 Yep. 00:39:54.880 --> 00:40:03.039 I think there have been times where the board's been pretty gung-ho to go and do stuff, but it's like, hang on, as an organization, what can we actually execute on? 00:40:03.199 --> 00:40:04.480 What do we have the capacity for? 00:40:04.639 --> 00:40:13.280 And so I think as we figure out the funding model, as we sort of get clear about being efficient with execution and getting good at volunteers, that's the other thing. 00:40:13.360 --> 00:40:14.639 You have to get good at volunteers. 00:40:14.800 --> 00:40:18.800 So as we build these systems, I think we can start to expand and go in different directions. 00:40:19.119 --> 00:40:21.920 How much is community driven versus organizational driven? 00:40:22.159 --> 00:40:30.880 Back in the like original days where the group was small, it was very much community-driven because people tried wacky stuff and then eventually certain things stuck. 00:40:30.960 --> 00:40:33.599 And now it's like too big to have that happen. 00:40:33.840 --> 00:40:41.119 Where like smaller numbers can't necessarily drive the direction of the organization because there's so many larger things sitting on top of it. 00:40:41.280 --> 00:40:45.599 Where do you see maybe the community like fitting in and pushing the direction more? 00:40:45.679 --> 00:40:47.840 And maybe how do we help encourage that more? 00:40:48.000 --> 00:40:50.079 I don't know if that's even the right thing. 00:40:50.320 --> 00:41:05.119 Yeah, so I would push back slightly on that, but there is an element of truth in sort of like how you framed it, which is the Ruby Central has from its start is founded and sort of operated, run by people in the community. 00:41:05.360 --> 00:41:13.199 And so back in the day, and I got involved in 2005, so I don't know what it was like in 2002 or 2003, but I'm sure it was like a hey, we're at the annual conference. 00:41:13.360 --> 00:41:15.679 Hey, Chad, hey David, what if we did this? 00:41:15.840 --> 00:41:18.400 And I think actually Ruby Gyms was like, you

know what we need? 00:41:18.559 --> 00:41:20.079 A better way of sharing code. 00:41:20.320 --> 00:41:21.599 What about a gym? 00:41:21.760 --> 00:41:22.719 And how would we do that? 00:41:22.880 --> 00:41:23.119 I don't know. 00:41:23.199 --> 00:41:25.599 And they just hacked it out at RubyConf in 2003. 00:41:25.679 --> 00:41:25.840 Right. 00:41:26.000 --> 00:41:27.440 Hey, we built it this weekend. 00:41:27.599 --> 00:41:28.079 Awesome. 00:41:28.239 --> 00:41:29.840 We just shared a gym on stage. 00:41:30.079 --> 00:41:33.360 As long as the people running Ruby Central are in the community. 00:41:33.519 --> 00:41:35.199 Well, one, that changes every year. 00:41:35.280 --> 00:41:39.360 So the board brings in new people, and they will say, Hey, you know what? 00:41:39.440 --> 00:41:40.559 What if we did this? 00:41:40.800 --> 00:41:43.280 So that already exists to a degree. 00:41:43.519 --> 00:41:46.320 But we also have obligations. 00:41:46.480 --> 00:41:47.679 We now have Ruby gems. 00:41:47.840 --> 00:41:48.719 There's a lot there. 00:41:48.880 --> 00:41:49.840 You don't just turn that off. 00:41:49.920 --> 00:41:50.480 Like, you know what? 00:41:50.719 --> 00:41:51.760 Think we need to do gyms anymore. 00:41:51.840 --> 00:41:52.719 Let's do something else. 00:41:52.800 --> 00:41:54.159 No, it's like you've got this. 00:41:54.239 --> 00:41:55.360 You're you're obligated. 00:41:55.440 --> 00:42:02.400 And the world, the Ruby world is counting on you to keep it secure, keep it up and innovating perhaps, maybe not. 00:42:02.559 --> 00:42:09.840 So practically, how does someone now today help influence or inspire Ruby Central to go in one direction or not? 00:42:09.920 --> 00:42:10.000 Yeah. 00:42:10.159 --> 00:42:16.000 I think the first thing is volunteer, reach out and say, Hey, you know Ruby Central, I would like to help, or I want to be on the board. 00:42:16.159 --> 00:42:19.519 Every year there's always a call for board members or volunteers. 00:42:19.679 --> 00:42:27.119 Now, I will say with volunteers, and we've done this multiple times, where they said, hey, go volunteer, go over to the Ruby Central desk and say you're ready to help. 00:42:27.280 --> 00:42:32.480 And the problem is sometimes we're not really ready for 20, 30 people to say, hey, can I help? 00:42:32.639 --> 00:42:40.000 Because every volunteer that comes in, there needs to be some sort of system or support to now give them the opportunity, manage that process. 00:42:40.159 --> 00:42:45.920 And so the thing I talked about with the team this year is like we have to be really good at managing volunteers. 00:42:46.079 --> 00:42:49.199 That onboarding process has to be solid, has to be consistent. 00:42:49.280 --> 00:42:53.519 If someone says, hey, I want to volunteer, and then we never respond, well, that's a terrible experience. 00:42:53.599 --> 00:42:56.480 They'll be like, tried to help, and no one got back to me. 00:42:56.559 --> 00:42:57.199 This is terrible. 00:42:57.280

--> 00:42:59.280 And we still, by the way, don't do great at that. 00:42:59.440 --> 00:43:04.559 So there is a volunteers are awesome, but like, what's our capacity to support volunteers? 00:43:04.719 --> 00:43:05.519 I think that's that. 00:43:05.599 --> 00:43:07.519 You can also just like share your thoughts. 00:43:07.679 --> 00:43:08.960 We have a community Slack. 00:43:09.039 --> 00:43:12.400 You can always say, Hey, Ruby Central, you know, what if you did this? 00:43:12.639 --> 00:43:13.840 Oh, that's an interesting idea. 00:43:14.000 --> 00:43:18.239 So they could be like a hey, would you like to like pitch how that would work? 00:43:18.400 --> 00:43:24.320 Maybe find another person or two that wants to make that happen and you basically bring a plan. 00:43:24.480 --> 00:43:26.159 That's actually well thought through. 00:43:26.239 --> 00:43:28.239 So now how do we do we need money for this? 00:43:28.400 --> 00:43:29.519 Who's gonna do the work? 00:43:29.679 --> 00:43:33.599 We could have like a little playbook of like, cool, you want to fire up a new program, Brew Central? 00:43:33.760 --> 00:43:37.920 Here's the new program playbook, and you could just start with that and make it happen. 00:43:38.079 --> 00:43:39.199 That's fantastic to hear. 00:43:39.360 --> 00:43:45.280 I'm glad that it's still a tenant of the organization in a way of embracing that that openness to get involved. 00:43:45.440 --> 00:43:46.719 I have been hesitant in the past. 00:43:46.800 --> 00:43:47.519 Maybe that'll change. 00:43:47.599 --> 00:43:48.000 I don't know. 00:43:48.159 --> 00:43:49.840 It seems like you can just reach out. 00:43:50.079 --> 00:43:52.800 Just if you reach out, understand that we might be a little busy. 00:43:52.880 --> 00:43:54.880 So give us some grace on response time. 00:43:55.119 --> 00:44:00.400 I could also say from my own experience, I think it's a good idea to be specific about what you want to help out with. 00:44:00.559 --> 00:44:05.360 I have had the experience of coming over to over to somebody and be like, hey, I really want to help. 00:44:05.440 --> 00:44:06.159 This is a couple of years ago. 00:44:06.239 --> 00:44:07.360 And then be like, oh, all right, great. 00:44:07.440 --> 00:44:08.079 What do you want to help with? 00:44:08.239 --> 00:44:08.719 Like, I don't know. 00:44:08.800 --> 00:44:09.440 What do you guys think? 00:44:09.599 --> 00:44:09.760 Right. 00:44:10.079 --> 00:44:12.800 When the answer is everything, it's a volunteer-driven organization. 00:44:12.960 --> 00:44:14.079 So we need help with everything. 00:44:14.159 --> 00:44:15.440 We don't know exactly where to put you. 00:44:15.599 --> 00:44:20.000 We don't know how exactly how to match your desires plus skill set to what we need. 00:44:20.159 --> 00:44:26.639 I would suggest to add to your routes of making a difference, Marty and Ruby Central is yeah, come with an idea. 00:44:26.719 --> 00:44:26.880 Yeah. 00:44:27.199 --> 00:44:32.480 What are you seeing that

looks interesting that you might want to support, you might want to help out, or that you're not seeing and you'd like to see? 00:44:32.719 --> 00:44:36.480 Once you build a system of like, hey, you have board members that have capacity. 00:44:36.639 --> 00:44:41.119 Maybe you spin up a committee that's dedicated to some program or some idea. 00:44:41.280 --> 00:44:44.480 And now you have someone who maybe has staff support. 00:44:44.559 --> 00:44:47.360 So then you have enough staffing that someone can help with that. 00:44:47.440 --> 00:44:51.599 And you have someone with the idea, the vision, and now you get people involved from the community. 00:44:51.760 --> 00:44:55.039 All of a sudden now you got five or six people driving a new thing. 00:44:55.199 --> 00:44:56.559 You can do quite a lot with that. 00:44:56.639 --> 00:44:59.280 And there's plenty of organizations out there that do this well. 00:44:59.360 --> 00:45:05.360 And we just need to like not reinvent the wheel and go and say, hey, can we borrow your playbook and then build that up? 00:45:05.519 --> 00:45:06.880 I mean, that's how what it should be, right? 00:45:06.960 --> 00:45:07.760 Like, we're here. 00:45:07.840 --> 00:45:12.079 The whole point of this organization is to serve the Ruby community, the Ruby ecosystem. 00:45:12.239 --> 00:45:13.679 We can do that in lots of ways. 00:45:13.920 --> 00:45:16.719 We have to get good at that itself. 00:45:17.039 --> 00:45:17.599 I like that. 00:45:17.760 --> 00:45:21.760 A place for us to improve as a community and a place for Ruby Central to continue to improve. 00:45:22.079 --> 00:45:25.199 Marty, thanks so much for coming onto the show with us today. 00:45:25.360 --> 00:45:26.239 This has been really great. 00:45:26.320 --> 00:45:27.119 It's been educational. 00:45:27.440 --> 00:45:27.840 Thank you. 00:45:28.000 --> 00:45:28.239 Yeah. 00:45:28.400 --> 00:45:35.840 And I think really instructive and educational for our listeners as well, who kind of want to know what's going on in the community and what's happening at the highest level. 00:45:36.159 --> 00:45:39.280 Well, thank you to both of you for inviting me, and it's been a great conversation. 00:45:39.440 --> 00:45:43.039 If anyone wants to help out with Ruby Central, we've given you some ideas today. 00:45:43.199 --> 00:45:45.119 So uh please do share your thoughts. 00:45:45.440 --> 00:45:46.480 Please continue supporting. 00:45:46.559 --> 00:45:49.199 While I haven't hit every conference, I do enjoy them when I go. 00:45:49.599 --> 00:45:53.039 Please keep supporting Ruby Gems because I use that every day. 00:45:53.199 --> 00:45:54.559 I hope everybody listening does this. 00:45:54.960 --> 00:45:56.000 Or Valentino's thing. 00:45:57.280 --> 00:45:58.480 Ruby Gems. 00:45:59.920 --> 00:46:00.559 Yeah. 00:46:00.880 --> 00:46:01.360 All right. 00:46:01.440 --> 00:46:02.159 Well, thanks a lot. 00:46:02.239 --> 00:46:03.519 And uh and take care, everybody. 00:46:03.599 --> 00:46:04.719 We'll talk to you again next week.