SPEAKER_01 0:00

Hey everybody, welcome back to another episode of the Ruby AI Podcast. I am one of your hosts today, Valentino Stoll, joined by.

SPEAKER_02 0:06

Hey, I'm the other host. I'm Joe Leo. We're really excited today because we've got a boss on the show. We don't always have a boss, but today we've got a boss. Welcome to the show, RubyGems, Ruby Central, and other things Ruby lead. Marty Hott. Welcome to the show, Marty. Thank you, Joe. Thank you so much. Maybe you could tell us because I was just on a call with you a couple of days ago and I was maybe it shouldn't have surprised me, but you were kind of rattling off the things that you are in charge of right now. And it's kind of a laundry list. So what do you tell us?

SPEAKER_00 0:36

Yeah, it is true. I am the boss of many things, which is kind of funny. So at Ruby Central, my official position is the director of open source, but I'm also the acting executive director, which means I oversee everything that happens at Ruby Central. Now, Ruby Central is a nonprofit. So we have a 501c3. We have a board of directors that is responsible for the organization, but they're volunteers, they're not working individuals. So they set like direction and oversee policies and just the governance of the organization. But when it comes to actual all the execution of the organization, that falls to the executive director, which is I am at this point. And I've been since April when there was a change. For any listeners who have been following Ruby Central or the Ruby community, probably already know a lot of that. So they've they've read the blog posts. But there is so much going on. It has been this way for really since I came to Ruby Central in 2024 as a staff member. Now, history-wise, I've been involved in the organization since 2012. So I was on the board of directors with Evan Phoenix and Ben Schofield back in 2012. Stayed on the board until 2023, and then I stepped down.

SPEAKER_03 1:46

Okay.

SPEAKER_00 1:46

But then I got brought back in to help run the RubyGems open source program to oversee the RubyGems service.

SPEAKER_02 1:54

It's interesting as you talk about that history and where it stands today. And we're going to get into RubyGems and the security work that you do. It seems like at least two full-time jobs that you're taking on right now. Is there any future plans for either replacing you at one or the other position?

SPEAKER_00 2:11

For sure. I joked for a while that I actually had three jobs or four jobs, depending on how you looked at it. Maybe not all of them are full-time, but it definitely is more than one person can do. 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. Unfortunately, as the boss, that doesn't mean writing code. That doesn't mean running scans, as we'll we'll talk about, and other kind of more interesting things. 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? That's weird, Marty. Like you're a nonprofit. Why would you think about product? Well, when I came into the role of overseeing Ruby Gyms, the first thing that was pretty clear is we have a money problem. This is a mission critical service that serves Ruby programmers around the world, and it's free. No one pays for it. Yet it's not free. It costs money, it costs staff to oversee it. 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. And I'm like, that's not right. Right. We have to look at sustainability and rethink how we fund this service and how we operate it.

SPEAKER_02 3:36

First of all, I think you're 100% right. 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. I think you were there again this past September. Is that right? Yeah. What are the other open source languages doing with similar package management, similar situations?

SPEAKER_00 3:55

Turns out we're all in similar situations. Different foundations have different funding models. If you look at like Linux Foundation, they have a lot of corporate backers and they have plenty of money. They're very, very large. 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. We're like, how do we pay for all this? And many of them operate their own registry. Thankfully, we don't have the scale that some of the other registries do. I feel very much for Pype I. They're getting hammered. Yeah. 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. But the fundamentals are still the same that we have to think about how we fund it. And there's actually a working group, the package registries working group, that is working on sustainability. And so, how as a collection of registries, how do we pay for our services? How do we pay for the staff and all the work that goes into it? 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. 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. 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. 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. There's no real easy answers because if something's been free for decades, how do you now charge for that? 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. Right. We don't want to put that behind a paywall or something. That doesn't make any sense. That's definitely not the way that the open source mindset works. And so it's like, how do you find that business model that works that still preserves the spirit of that? And so this is where that product side comes in. So, like, hey, are there things that RubyGems as a service could offer to publishers that they would pay for? They'd happily pay for. I think when I've had conversations with many of these companies, they're like, we would love to help. We would love to help support this, let us know how. 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. Right. Now we do get a lot of donations. We do get donations and we get infrastructure donated, which is massive. So we have, I would say, around $300,000 a year in services that are comp to us. So Fastly, AWS, and Datadog are top three. They're all free for us, and they're very, very important to the operation of the service.

SPEAKER_01 6:49

I feel like most people, maybe that deal with package managers, are just like, I just want to download stuff. You know, that's all they think about in the early days of an organization. You just think, well, yeah, I just want to keep downloading stuff and updating stuff. 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. 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? I imagine there's a bunch of tiered products that come out of this.

SPEAKER_00 7:28

Yeah, yeah, definitely. 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. 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. 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. 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. And so what I looked at from a publisher standpoint is that publishers are more likely to pay, especially companies that have an SDK. This is their product, and they provide a Ruby gem that allows you to connect to use their service. They are a for-profit company, they make money, and they're a perfect customer for a paid organization as a publisher. Our biggest publisher is AWS. They have over 600 gems, and they are power users of our platform. Actually, the organization's feature, which we do have, it's in private beta right now, was funded by Amazon. They're like, we really, really need this because we have some serious pain points. If we give you a bunch of money, would you build this feature? And we're like, yes, yes, we will. You are right. That is definitely a need. Because you can certainly publish for free on RubyGems like you have for the past 20 years. It's fine. It works pretty well. Except for when you get to scale. There's definitely some pain points. 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? And how much would you be able to pay for that?

SPEAKER_02 9:12

I wanted to get into this as well. I'm glad you brought it up. The organization, so it's in private beta right now. It came out in the I think the change log mentions it. It's interesting. I did not know about the AWS angle. So they paid for it, they want some features. What is it that they're going to get or that any organization that signs up will get?

SPEAKER_00 9:29

So imagine changing permissions or user access if you have dozens or hundreds of gyms. You have to go into each gym right now and change that. I see. Okay. Wouldn't it be nice to say, hey, this is like the table stakes feature that everyone's like, obviously. Like I run a business, I publish gyms, and I want someone to have administrative control over all the gyms we publish. 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. Sure. Now I can then give permissions, limit permissions. So they can't say kick people out because there used to be like there's owner or contributor, and that was it. And you need to be owner to publish, but then you can also kick everybody else out. Right. That's not good, right? So you can see a whole bunch of risk factors that from a business standpoint you would want to limit. And I think a lot of them worked around by we'll create a single like service account that we'll share. Yeah. And then we'll change access to if we need to. That's kind of clunky. 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. Organizations is the first thing that works. For AWS, they have a gems team that oversees the publishing of all the gems for all their SDKs. But each gym has a service team in AWS, and these are not Rubyus. 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. And this is all generated. They have a system that does all this, it's all automated. But there's a team that oversees all this. The pain points they had was trying to manage these 600 gems when you're not the publishers, but they have to oversee it. So that's one example. Another would be someone comes and goes, you need to change access, you want that to be nice and easy. So it's kind of similar, but it's all part of that, like table sticks. Yeah. 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. 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. Someone else would get an error and wouldn't be able to publish. Okay. 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. Great. Now you know that if this gym has this naming convention, it's going to be an AWS gem. That doesn't, of course, prevent anyone else from saying Bob's AWS gem. Yeah. Because I think I have a better way of doing this. That's cool. You can do that, but you can't call it AWS-SDK-whatever the service is. You have to come up with a different name. Without that ability, you could have people squatting potential names for gems that really Amazon should own, but they claimed it first or whatever.

SPEAKER_02 12:41

Valentina, why didn't we think of this? We both squat webs websites all the time. We could be squatting on gem prefixes. Yeah. It's such a missed opportunity.

SPEAKER_01 12:49

It's very true. You know, I I've thought about reserving RubyGem names for a long time.

SPEAKER_02 12:55

Man, well, now we missed our window.

SPEAKER_01 12:57

You know, I also don't want to get banned by RubyGems either. It it is against the terms of service, the abuse policy, so Yeah,

SPEAKER_00 13:02

Exactly.

SPEAKER_01 13:03

You know, I've read them. But at the same time, you know. What's stopping Amazon from just creating their own gem server? What value do they get out of RubyGems as like a trusted publisher? Anybody can host their own gem publishing. Totally. And it's set up as like Mike Perham as an example, like for a long time. I don't know if he still does it, but like for Sidekick.

SPEAKER_03 13:23

Yeah.

SPEAKER_01 13:24

Yep, for Sidekick Pro. What value is there from Amazon joining RubyGems as their like trusted publisher? I'm just curious to unravel maybe the organizational aspect of this. Sure. Why not just like roll up their own?

SPEAKER_00 13:36

They could, but do they want to get in the business of hosting a registry and managing its security and its uptime? That's the first question I would ask. 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? 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. If you're an SDK publisher, do you really want to have to have a team dedicated to hosting your own gyms? I'm guessing not. Yeah. So that's one angle. The other one would be it's the default. So you install Ruby or it's already installed in your system. You have RubyGems already installed because it comes by default. You want to install RubyGem. You don't have to say, hey, I wonder where that gym is located. Where's the source? Oh, here it is. Great. I mean, you could do that, but you can also just say gym install gym name and it's done. So there's a lot to this is the canonical package registry for the Ruby ecosystem, has been since 2004. Yep. You know, they're like, why make it harder? We want to make it easy as possible to install our gym and go.

SPEAKER_01 14:40

Honestly, it's a testament to it working to have somebody like Amazon leaning into the canonical format rather than rolling their own. Because I know that some have done that in the past.

SPEAKER_03 14:50

Yeah.

SPEAKER_01 14:50

I'm curious, kind of like to our next foray here of security. Yeah. Uh, which is kind of like the big reason to use RubyGems ultimately.

SPEAKER_02 15:00

And another reason not to start your own registry in 2026. You know?

SPEAKER_01 15:04

Where do you want to start here? 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. What do you want to start with?

SPEAKER_00 15:21

Let me give you a high-level list of security-related items here. 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. Okay. 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. And that's actually probably the biggest risk factor is what if Rails or one of Rails gems got hacked or taken over? 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. But there's plenty of those. 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. And so that's another aspect of security. 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. 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. And we've seen countless examples this year of that in the Ruby community, in the Ruby ecosystem, as well as outside. 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. 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. So can the good guys find them before the bad guys? Because these models, they're not going to stay restricted very long. It's not in the best interest of these labs companies to develop this amazing AI model and then not let people use it. 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? 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. And so the Security Engineers and Resonance program that we started in May was funded to basically try to get ahead of the curve. 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.

SPEAKER_02 18:15

So thank you for that description. 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. And I it was really educational, it was really well done. Thank you. So we saw this stat, this was in the change log. It was published recently. 619 gems were prioritized. This is out of 200,000, which makes a lot of sense because it's like 158 billion downloads across those 619 gems, right?

SPEAKER_03 18:40

Yeah.

SPEAKER_02 18:40

317 were scanned by this multi-step system. And I've seen this in action that running multiple AIs, you know, dozens of tool calls. Yes. There were 134 findings that needed to be reviewed by humans. 14 deemed legitimate and pretty nasty. First, can you tell us a little bit about some of the success stories? I know Ruby NTLM was an example. No Kugir, I think, was an example. Yeah. Tell us about that.

SPEAKER_00 19:06

I'll talk broadly about it because I'll tell you, as you can imagine, I'm not in the details as much. 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. Great name. Yeah. Fun little acronym, yes, uh S-E-I-R. Yeah. The process is first of all, you have to prioritize because it takes tokens. It takes a lot of tokens. We don't have an unlimited token budget. 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. 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. So there's very much a okay, we have basically 200,000 gems that we might want to look at. Maybe only 10,000 are relevant or depending. 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. And so we basically said here are the top 1,000 gems that need to be scanned first. And Rails and its dependencies are pretty obviously top of the list. And the obvious gems like that already have been looked at multiple, multiple times. And of course, the Rails security team are already thinking about this. The Ruby security team is already looking at Ruby in its standard libraries, included gems that come with Ruby. But there's a lot of gems that are used heavily that go beyond that that they may or may not scan. And so essentially, so that's the first place pick a reasonable number and try to work through them. These scans take time. As Joe mentioned, the harness, by the way, the scanning tool is called Scrutinier. We can provide a link to you all to share with others if they want to go see it. It's open source. It has been developed. Andrew Nesbitt wrote it and has been working at it. It's got many contributors now, including our teams contributed a lot to it as well. Because ultimately, you're trying to efficiently work through thousands or hundreds of thousands of packages and managing the findings. Once a scan's been done, you have findings. Well, they need to be investigated and determined if they can really be exploited. Because sure that's a medium or that's a high, but maybe that gem doesn't get called that way. So there's this judgment call of like, well, how would you exploit this vulnerability? Can you actively take over a system or do whatever if that was installed like in a Rails app or whatnot? And so there's this determination of like, okay, here's the level of the vulnerability and here's how it could be exploited. And we have a proof of concept where we build, like, here's how you can actually do this. So that takes time. And so then a human does review it and looks at it, then determines is this something worth pursuing with a maintainer. Now you get into a very fascinating space, which is working with other humans about a vulnerability. They're not expecting this. Right now, everyone that's doing Doing open source out there is getting inundated with these AI slot reports. Some of them are good, some of them are bad. There's a lot of noise. There's just a lot of activity. So it's overwhelming. In our program, we like, how can we, in a humane way, reach out, make sure we're not wasting their time. Like, this is a legit issue that we think needs some attention. Now, it's up to the maintainer to decide if, like, no, actually, that's not a real vulnerability. It can't be exploited because of these reasons, or they're using the gym in a way that was never intended. 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. And we leave it in the hands of the maintainer. Like it's their library, they're responsible for it. But they may not even be around anymore. Like that person maybe hasn't done an update in years. 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. 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.

SPEAKER_02 23:01

This is all really fascinating. 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. 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. Maybe the AWS gems are actively being monitored by AWS, let's just say, as an example. But there's about 200,000 gems out there. 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. 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. But what do we do as a community with all of these others that are sort of left out there? And now maybe they've been working, chugging along for some definition of working, but now there's some real security threats.

SPEAKER_00 23:51

Yeah, yeah. It's a great question. We have thoughts about it and we have some approaches so far. We did write some policies about how we would navigate this because we knew that there'd probably be some tough calls. Like if there's a really heavily used gym, no one is maintaining anymore, and there's a really bad exploit in it. Can we really not do anything? Probably not. And the policy, by the way, for RubyGems is that if there is significant enough security concerns, the registry will take action. Okay. We might remove a gem. I guess we could patch it. 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. So there's kind of interesting cases there. Yanking is the obvious solution that we've had and used over the years. Yeah. It's like this is malicious, this is bad, it's getting yanked.

SPEAKER_02 24:53

Okay.

SPEAKER_00 24:53

We have yank requests all the time. I would say on a weekly basis, multiple times a week, we're reviewing and taking action behind the scenes for yanks.

SPEAKER_02 25:01

Oh, interesting. I did not know that.

SPEAKER_00 25:02

And also, as an author, you can yank to a degree your versions, but we have limits. 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. We have plenty of customer service requests coming in. Could you please yank this version? It's got these issues. We do that quite a lot on the request of maintainers. Okay, so that's that. 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. So for example, if a gym hasn't been maintained or maybe has vulnerabilities, like now we do report on vulnerabilities. So you can see in the RubyGems UI that there are known vulnerabilities for a version or versions of a gem. 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. And I don't know where the GIMS team is in terms of that implementation. But the idea is that you will be an informed consumer about what you're consuming from a registry. 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. Now you can see that. You can be informed and you can decide what you do about that. The classic model over the years was like, this was the gym that people used for this type of activity. And now there's a new gym that does it better. Right. And people migrate and they switch to the new gym.

SPEAKER_02 26:33

Yeah.

SPEAKER_00 26:33

That's fine to say, look, this gym had its heyday. It was a great gym. We loved it.

SPEAKER_02 26:37

Had a good run.

SPEAKER_00 26:38

Had a good run.

SPEAKER_02 26:39

Yeah.

SPEAKER_00 26:39

And now you shouldn't be using this. And as a registry, we can first of all empower our maintainers to share that status. And so if they don't want to maintain a gym, you don't have to. But you should be able to say that, and that the registry and anyone consuming gyms now knows it. 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. And they're actively maintained, yay. Or it could also be this gym has lacked security practices. And I'm a little worried. They aren't trusted published or whatever. I'm worried that this could be taken over because you know the they don't have MFA enabled for their account. 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.

SPEAKER_01 27:26

Is there a follow-up to that of providing some kind of signal to people that can subscribe to maybe metadata events?

SPEAKER_00 27:32

Yeah.

SPEAKER_01 27:33

So that they can be notified when things change.

SPEAKER_00 27:36

You obviously could find out through a bundle install or bundle update or something like that. 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. We recommend you upgrade to version X right now. Right. Like I think that that sort of feature is something that would be really powerful. 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? I would like notifications of this. Now we don't have something like that, but could we build it? Definitely.

SPEAKER_01 28:08

That's a service I know people already pay for.

SPEAKER_00 28:10

There are security companies that do that. They do. Yeah. Should the language ecosystem registry get in the business of that? Because there's a whole bunch of security companies out there that provide these sort of features on top of registries. Should we get in that space?

SPEAKER_02 28:24

Maybe this should be a uh Ruby AI podcast side quest. I can see this being the next thing that you have AI build.

SPEAKER_01 28:31

It's a metadata notifier proxy. Yeah. I like I like this idea for us. I mean, that does look we look trustworthy.

SPEAKER_02 28:39

I'm working out.

SPEAKER_01 28:42

Trust us. Trust us. Word of mouth is fine. You know, this makes me wonder like a lot of people love federation, Mastodon, and there's been a hype. I don't know if it's still a hype. From an organizational perspective, I mean you've seen it from the high level. Like, is there really value in like the language adopting a federated approach to some of these products? Or is it better to try and keep things in the organization? Where do things fall apart from that angle? Because a lot of people's answer would be just federate it and let people pay for it in a broken apart way.

SPEAKER_00 29:16

Right. 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. They trust that if, say, RubyGems goes away tomorrow or went down for a week, they could still deploy. They could still do all that. But how do you get updates? Think of it from an ecosystem standpoint. So Federation, I think, is great. I think there are probably some challenges with it. Certainly from a Ruby ecosystem standpoint, we support it. 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. It's gonna go to one place, and that's a place you trust. So now, can we change that? Sure. But I think you still have an interesting challenge of how do you get updates to a package? How do you trust those updates so that part doesn't go away? Back to that second security problem of like supply chain security. And are you downloading and installing what you think you are installing and from the people you think you're getting it from? That problem doesn't go away with federation. And most likely it becomes harder. 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. So if you go to the federated model, would one of those endpoints, would they have the same security? Could they be compromised and now you're hosed? Because you thought you're getting the trusted gem and actually no. They said it was. Oh, trust us, it's fine. Now, there are definitely ways to build this uh cryptographically, you can verify things. Is the future that? I would hope so. 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.

SPEAKER_01 31:19

Yeah, I think there's a lot of value in that too. I think of it certificate authorities and containers, where the hub pulls from. 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. And it makes me think about crypto, to be honest. 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. Right. So, where do you see the greatest needs from like an organizational perspective? Is it still security and building out the product to keep the lights on?

SPEAKER_00 31:59

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. We've come a long way over the last several years. It's been like we've had a lot of funding come in. Alpha Mega has been a massive partner. 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. But they're seeing the risks to ecosystems, and they support many, many ecosystems. And so I think that's helping dramatically. 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. And that's had a massive effect for us. 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. And so we're multiple years into that journey. I think we're doing pretty well, but it's not all solved. I still don't have recurring revenue that pays for operations. 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. 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. And so you can imagine if like, how much money will we have to staff our services? Oh, you don't know. You have to figure it out and hope that you'll get there. And that's kind of how it's been. 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. That would be amazing. I don't have that. 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. 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? Then I could easily do the budget process. Absolutely.

SPEAKER_01 34:27

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. And then at that point, you've already made the reservations, or you get enough sponsors to sponsor.

SPEAKER_00 34:40

And of course, you know, as an organization, we live that world as well. 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. So we didn't have to figure out how to fund it. And since COVID, since the pandemic, that's all changed. And so the organization's been scrambling to like, oh, now we don't have a funding model that is sustainable or functions. And so every year it's like, let's try this or let's you know make this plea or whatever it is. 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. 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. Back to your original question, Joe, is do you see other people helping out? Like, absolutely. I kind of need money though, and reliable money before I'd ask someone to step into this role and do this. Because what do you mean you don't know if you have enough money next year to have the same staff?

SPEAKER_02 35:37

Yeah. Well, the head of a nonprofit, my experience, that person is typically trying to raise money. That's the biggest part of the role. It's a sales job in a lot of ways, right? Isn't that accurate here as well? Maybe more so than it used to be. 100%.

SPEAKER_00 35:49

Also, I don't have a playbook. And also, I'm not a sales guy, and I've not done this before. So you're uh engineering leader and you know how to build systems the right software. Great. Now, actually, that's not your main problem. Yeah, that's the easy problem. Here's the real problem going convincing people that you need to fund this. And like, so I'm learning so much. So, like the last two years, yeah, it's like, ah, now this is a skill I need to get better at. And oh, I need help with this. And so a lot of what I think about now is like, who can I have come in and help? 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.

SPEAKER_02 36:29

You seem like you can fit really well into a lot of different responsibilities and roles. What I see is it's a capacity problem. 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. Right. 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. And I know how that goes too, because I've I've run a big smoke company and I've run a small company. And guess what? They're the same company. You know, sometimes you just have to make do with what you got.

SPEAKER_00 36:53

Yeah. And then factor in like, what if you hired someone and they didn't work out? Think about the cost of that. And matter of fact, you can look at the last five years and you can see indications of that wasn't a great hire. That wasn't a fit. It didn't work out. And the cost of like how quickly do you react? And this is the whole like the advice fire fast. If someone's not a fit, you gotta get them out.

SPEAKER_03 37:16

Yeah.

SPEAKER_00 37:17

And sometimes we're too nice or we think, oh, it'll just give them time, it'll work out. Never works out. And you pay a higher price. I know. Like this point, I'm like, I would love to go faster. 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.

SPEAKER_02 37:33

Yeah, and it costs you more right now, right? When the organization is small, the next hire is more critical than when it's large. You know, a large organization can recover quickly from a bad hire, usually because there are other great people in the door. And that right now you're small, and you know, I get that. The next person is critical. 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.

SPEAKER_03 37:55

Yeah.

SPEAKER_02 37:55

And then, you know, you've got the conference, which people still feel like is important. And I know we're at least going to have one in 2027. So I'm excited about that. What else would you say is in the mandate of Ruby Central?

SPEAKER_00 38:07

Yeah, I mean, that's a great question. So the organization started very humbly in that, like, it was really just created to it was to put on the conference. Put on the conference. Yeah. 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. Like to be a charitable organization. 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. The board has like, here's our mission, our vision, all that sort of stuff. And we do in our paperwork, this is why the nonprofit was created. So we have to measure ourselves against that. Are we actually fulfilling our mission? What exactly does that mean? 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. There are other ways we could look at that. Obviously, RubyGems as a service is critical in terms of like allowing people to install Ruby and sort of publish RubyGems. So that's great. You know, we wonder like, is there something around education or bringing in new programmers and helping them come up to speed on Ruby? 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. Like that's also something we've supported over the years. And so I think that's pretty clear. But what else could there be? You know, is there an education component that we could start to get helping, you know, provide educational resources for writing Ruby? Is there other services that the ecosystem would do well if it had, if it was provided? I don't know. I think there's tons of potential. 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? Both from a financial standpoint, but also people's time, volunteers' time. Yep. 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? What do we have the capacity for? 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. You have to get good at volunteers. So as we build these systems, I think we can start to expand and go in different directions.

SPEAKER_01 40:19

How much is community driven versus organizational driven? 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. And now it's like too big to have that happen. 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. Where do you see maybe the community like fitting in and pushing the direction more? And maybe how do we help encourage that more? I don't know if that's even the right thing.

SPEAKER_00 40:50

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. 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. Hey, Chad, hey David, what if we did this? And I think actually Ruby Gyms was like, you know what we need? A better way of sharing code. What about a gym? And how would we do that? I don't know. And they just hacked it out at RubyConf in 2003. Right. Hey, we built it this weekend. Awesome. We just shared a gym on stage. As long as the people running Ruby Central are in the community. Well, one, that changes every year. So the board brings in new people, and they will say, Hey, you know what? What if we did this? So that already exists to a degree. But we also have obligations. We now have Ruby gems. There's a lot there. You don't just turn that off. Like, you know what? Think we need to do gyms anymore. Let's do something else. No, it's like you've got this. You're you're obligated. And the world, the Ruby world is counting on you to keep it secure, keep it up and innovating perhaps, maybe not. So practically, how does someone now today help influence or inspire Ruby Central to go in one direction or not? Yeah. 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. Every year there's always a call for board members or volunteers. 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. And the problem is sometimes we're not really ready for 20, 30 people to say, hey, can I help? 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. And so the thing I talked about with the team this year is like we have to be really good at managing volunteers. That onboarding process has to be solid, has to be consistent. If someone says, hey, I want to volunteer, and then we never respond, well, that's a terrible experience. They'll be like, tried to help, and no one got back to me. This is terrible. And we still, by the way, don't do great at that. So there is a volunteers are awesome, but like, what's our capacity to support volunteers? I think that's that. You can also just like share your thoughts. We have a community Slack. You can always say, Hey, Ruby Central, you know, what if you did this? Oh, that's an interesting idea. So they could be like a hey, would you like to like pitch how that would work? Maybe find another person or two that wants to make that happen and you basically bring a plan. That's actually well thought through. So now how do we do we need money for this? Who's gonna do the work? We could have like a little playbook of like, cool, you want to fire up a new program, Brew Central? Here's the new program playbook, and you could just start with that and make it happen.

SPEAKER_01 43:38

That's fantastic to hear. I'm glad that it's still a tenant of the organization in a way of embracing that that openness to get involved. I have been hesitant in the past. Maybe that'll change. I don't know. It seems like you can just reach out.

SPEAKER_00 43:50

Just if you reach out, understand that we might be a little busy. So give us some grace on response time.

SPEAKER_02 43:55

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. I have had the experience of coming over to over to somebody and be like, hey, I really want to help. This is a couple of years ago. And then be like, oh, all right, great. What do you want to help with? Like, I don't know. What do you guys think? Right. When the answer is everything, it's a volunteer-driven organization. So we need help with everything. We don't know exactly where to put you. We don't know how exactly how to match your desires plus skill set to what we need. I would suggest to add to your routes of making a difference, Marty and Ruby Central is yeah, come with an idea. Yeah. 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?

SPEAKER_00 44:32

Once you build a system of like, hey, you have board members that have capacity. Maybe you spin up a committee that's dedicated to some program or some idea. And now you have someone who maybe has staff support. So then you have enough staffing that someone can help with that. And you have someone with the idea, the vision, and now you get people involved from the community. All of a sudden now you got five or six people driving a new thing. You can do quite a lot with that. And there's plenty of organizations out there that do this well. 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? I mean, that's how what it should be, right? Like, we're here. The whole point of this organization is to serve the Ruby community, the Ruby ecosystem. We can do that in lots of ways. We have to get good at that itself.

SPEAKER_02 45:17

I like that. A place for us to improve as a community and a place for Ruby Central to continue to improve. Marty, thanks so much for coming onto the show with us today. This has been really great. It's been educational. Thank you. Yeah. 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.

SPEAKER_00 45:36

Well, thank you to both of you for inviting me, and it's been a great conversation. If anyone wants to help out with Ruby Central, we've given you some ideas today. So uh please do share your thoughts.

SPEAKER_01 45:45

Please continue supporting. While I haven't hit every conference, I do enjoy them when I go. Please keep supporting Ruby Gems because I use that every day. I hope everybody listening does this. Or Valentino's thing. Ruby Gems. Yeah. All right.

SPEAKER_02 46:01

Well, thanks a lot. And uh and take care, everybody. We'll talk to you again next week.