David Hill: 0:00

Shout out to GoRails for sponsoring Ode to RailsConf. If you or your team wants to learn the latest Ruby on Rails features Hotwire Ruby and more check out GoRailscom. Use code ODETORAILSCONF at checkout to get 10% off. You're listening to the Ode to RailsConf podcast, where we reminisce about RailsConf over the years, and joining me for a return visit is Marty Hught. Welcome back to the podcast, marty. Thank you, david. It's great to be here. You're a returning guest. You're pretty visible in the Ruby community. What have you been up to lately?

Marty Haught: 0:37

My world is very focused on how we advance open source in Ruby. My position, as we talked about last time, is director of open source at Ruby Central. Ruby Central oversees the operation of the RubyGems service and works with the open source team that maintains RubyGems and Bumbler, so there's a lot that goes into overseeing that program. We also think more about where should Ruby Central's support and efforts go that advance open source broadly across the Ruby ecosystem. While we're the stewards of RubyGems and Bundler, how else can we help the community and the ecosystem of maintainers with that? One of the things that I'm thinking about is well, there's really three things in sort of the framing of open source. First is security and open source. We've been doing a fair amount of work around supply chain security within RubyGems, and there's additional things coming up with the EU Cyber Resilience Act, which will bring cybersecurity as a concern for anyone who has a product in the EU market.

Marty Haught: 1:49

The next piece is reliability. Obviously, rubygems is a mission critical piece for everyone who runs Ruby apps, and so what does reliability look like? Where are the gaps? How should we plan ahead? And these are things that have been thought about but are now part of my job to pay attention to and develop. And the final piece is sustainability. How do we keep all these things going strong for years going forward? So what does it look like in 10 years or five years from now? Will we have robust systems? Will we have engineers that oversee this work, and how do we fund that reliably and sustainably over that course of time?

David Hill: 2:32

You are thinking about way weightier things that I'm thinking about on a daily basis. That sounds a little bit overwhelming, honestly.

Marty Haught: 2:40

It is, and there's not really a clear roadmap.

David Hill: 2:45

If this was easy, everybody would do all this stuff right.

Marty Haught: 2:49

Right.

Marty Haught: 2:49

So I think some things like reliability and security are fairly obvious. I think. For reliability of running systems, that's pretty clear. But you fold in the part-time nature of the team, you fold in the funding challenges and it goes next level in terms of one. You have to be clear about your priorities. You have to think about how you fund the work and can you maintain staffing long-term. That's a bit of a challenge, though reliability from an operations standpoint is pretty clear cut, it is definitely a little more challenging that way.

Marty Haught: 3:26

The security angle there's a lot of work to be done and Samuel Giddens is doing great work. They're sponsored by Alpha Omega, one of our larger backers, funding-wise, on improving security through the RubyGems. He's working on pre-compiling binaries in RubyGems. So instead of native extensions being compiled when you install them, that will be pre-compiling binaries in RubyGems. So instead of native extensions being compiled when you install them, that'll be pre-compiled on our system, so that won't be something you have to do and that removes the attack vector for supply chain attacks. Like I said, there's no script for this and a lot of it is. Where is the support in the community? What is the highest priority? What can we meaningfully impact now? What should we be planting seeds for for the future? That maybe next year becomes possible, and it's very fascinating. Definitely interesting work, wow.

David Hill: 4:16

Well, thank you for all of the work that you and your team are doing Because, like you said, all of us rely on it in some way, shape or form, so we're really happy to have you guys doing that work for us. So let's transition a little bit into our conversation about RailsConf. But this final batch of episodes wanting to gear the conversation less about reminiscing for past RailsComps and more what we're looking forward to in the future with this final RailsConf and maybe even beyond, if there's anything we want to talk about in there. In our pre-recording chat, you mentioned the hack spaces and the community day and how that's evolving and continuing to evolve. What can you tell us about?

Marty Haught: 4:56

that. First of all, this is the one aspect of the conference that I'm involved with. As you know, I used to organize RailsConf and RubyConf when I was a director and I no longer do that anymore. So other parts of the conference are in good hands, but this part, the hack space I think a fair amount of that. The RubyGems bundler team will be there, several of our members will be there and we'll have a space to interact with attendees, get people interested, answer their questions. So there's thoughts about like how will we use our time? What sort of prep do we want to put in beforehand to make that approachable and accessible for attendees? Rubygems and Bundler depending on which part of the code you're getting into can get really complex and maybe a little intimidating to certain attendees, but there are aspects of the service that are in rubygemsorg, which is a Rails app. So I think anyone who's comfortable with Ruby or with Rails will have something for them that they could dig into, and so doing some pre-work in terms of having that available and ready for folks to dig into is top of mind for us.

Marty Haught: 6:03

The other piece that is important with HackSpaces is how do we encourage the Ruby community to show up and get involved with all these different projects and show their support during the community day.

Marty Haught: 6:16

The idea of setting a block of time for each project is going to be fun to see how that plays out. The last few times it's basically been all day. The maintainers are sitting at their space and interacting with people, and one of the bits of feedback we heard from that was like I would have liked to have gone over and talked to that maintainer or on that table, but I couldn't leave my table so I wasn't able to interact with them. And so the hope is by setting two-hour blocks, then people can feel more able to roam around and visit and we hope it focuses folks' time into okay, here's a two hour block. I'll go and seek out this maintainer and their project at this time before doing something else. So those are sort of some current thoughts. I'll pause there, but the next thing would be how does this evolve and what are we missing from this?

David Hill: 7:08

No, feel free to continue down that track. I'm curious to hear your thoughts on exactly that. What's missing and how can this evolve further to better serve the community?

Marty Haught: 7:19

So long ago when I started going to these conferences and we talked about the first RailsConf in 2006 when I was on, and more so at the Ruby conferences in those early years, there was very much a lot of time and sort of the expectation that people would just get together and hack wherever hotel lobby, the hallway, wherever.

Marty Haught: 7:42

So my thinking with hack spaces and how this evolves is how can we be more intentional about sitting at that space and allowing that to organically happen and not distract from the conference or not try to pit open source hacking time or whatever collaboration time against other elements of the conference, because it's tough when you see, oh, these talks are going on or this workshop, gosh, I really don't want to miss those, and so I'll pick that over having a conversation with a maintainer or helping out with a project, and so I wonder about that and one of the things that I saw at RubyKaigi because I was at RubyKaigi in April and it was a fantastic conference.

Marty Haught: 8:23

Highly recommend it if you're ever inclined to go to Japan for a conference One of the things they had the last night was they had a code party, but it was similar to what we think about when we get together and hack, and wouldn't that be fun to incorporate that into our events in the future? And it was put on by a company Ampad sponsored this and they had much too small of a space because when I went to it there was no open seats. There's all these tables packed with people packing and talking and working through things, and it was after the conference, so it was like in the evening and it had just a great energy that would be interesting.

David Hill: 9:02

I usually attend a conference alone. I don't typically have a group of people co-workers or friends that I'm attending with, and so for after hours activities, I usually just kind of end up wandering back to my hotel room because I don't like imposing my presence on people if I don't have like an invitation to go do something. So yeah, having more activities like that, where it's like a clear, open invitation to come and participate in this code party activity, I'm all for those types of things of just like continuing to get people involved and invited into the community that way.

Marty Haught: 9:38

Yeah, I think in the evening time there is perhaps an angst of what do I do If there's not a structured event? Do I try to meet up with people? What if it doesn't work out? What if I end up just going to dinner by myself or with maybe some coworkers? And I kind of wonder about how can we remove some of that so that there's like an opt-in approach where people can kind of get together if they want to do more. And I think, like the code party could be a wonderful way that is code centric to do that. You're there at the conference, like this is an opportunity to interact with others and I get. Well, if you've had enough and you're ready to go back to your room, that's great. It's an option you always have. But sometimes you want to keep it going. Maybe you don't know where that's going to be, or maybe it's just going to be a loud bar where people are drinking, and maybe that's not exactly what you'd want to do, and so how, as organizers, can we facilitate that a bit more?

David Hill: 10:37

I like that idea. I hope that those conversations happen to lead towards something like that. That would be great.

Marty Haught: 10:43

I think the other thing that is on my mind with the last RailsConf is what's next? We know that RubyConf is going to be next year in the spring. It's not happening this fall like normal, and I think we've already kind of talked about the reasons for that. So Ruby Central is really focused on RubyConf next year. But there's an open question about how does web-related content Rails, hanami, whatever fit into RubyConf, into its format?

Marty Haught: 11:15

Because for many years the idea was well, we have RailsConf, we have RubyConf. That's a clear separation of concerns. It's very clear this is a RailsConf talk, this is a RubyConf talk. You know where to put them. But now it's like well, with RailsConf no longer being hosted and RubyConf is the only thing that Ruby Central does, how does that change the content that you see at RubyConf? The organization for RubyConf hasn't really started up yet, but I think that's a great question. And I think I mean, obviously there's Rails world, and Rails world will have that Rails centric content. But there's something about having a place where we all come together. It caters to different needs and different topics, but we're all together, and so I think it'd be nice to have more classic RubyConf type content along the side of that web or Rails type content. Oh, absolutely, you can collaborate with everyone. I think that makes a lot of sense and I suspect that's the direction things will go.

David Hill: 12:17

Yeah, one of the keynotes from RubyConf just this past November, brandon Weaver's talk, keynotes from RubyConf just this past November, brandon Weaver's talk and it's like I absolutely would not want to lose that type of content from RubyConf. Like the language itself outside of Rails is still plenty interesting, with plenty of room to learn new things. But my job in particular tends to be a Rails heavy environment and so I also want to have a healthy diet of Rails content. But I'm glad at least that RubyConf the plan is that RubyConf will continue moving forward even though RailsConf is coming to an end, so hopefully that'll be a long-term thing where I can keep kind of getting the good Ruby and maybe Rails-related content through a nice reliable Ruby central source. Yeah, agreed, yeah, I think that covers the basic bullet point stuff that we had about RailsConf. There was something else that you mentioned as a possible conversation point and I was really excited about it, and now I've completely forgotten what it was.

Marty Haught: 13:18

Yeah, I mean I think it would be digging into some of the open source program elements. I touched on it briefly in the beginning of the call, but we could go deeper on some of that.

David Hill: 13:31

Yeah, let's do that. There's a lot of concerns there that I've heard the words and the terms used before but I've never had to devote that time and energy to actually understand and go into. How do I protect supply chain, vector attacks and all of that stuff that you're having to deal with?

Marty Haught: 13:49

Anything that you'd be comfortable and willing to share and talk about, like those types of concerns that you're dealing with, I think a good example for those that maybe want to Google this or look it up would be like the XC Utils supply attack that happened and was thwarted I think it was maybe a year and a half ago or so happened and was thwarted I think it was maybe a year and a half ago or so, and I think that's an interesting one for the listeners to kind of look into. So the idea is with supply chain attacks it's like can you trust the libraries? The gems as they're published will be what you install and there won't be any modification, meaning there won't be any malware or vulnerabilities put in that you weren't expecting. And so there's aspects to this which is how do we secure Ruby gems in general so you can't compromise Ruby gems as a system? So there's that level of security. There is how do we improve security of knowing that a maintainer, when they push a gem up to Ruby gems, is actually that maintainer and they have that permission and so they're able to publish that gem and that the gem that they uploaded, that gem contents, don't get modified and you can trust that when it gets installed in your system, systems and ways of testing that these are all safe cryptographically and otherwise that we're working through with RubyGems work and there's more to come and I think the easiest thing might be to go and read the RubyGems blog, because there's various posts on what we've been doing that are there.

Marty Haught: 15:26

So it's important work. Luckily, there is interest in funding it, so Alpha Omega has funded Samuel Giddens' time to work on this full-time, so Samuel gets to focus his time on that. He's able to go deep on some very tricky problems because, if we step back and think about it, the RubyGems team is very part-time for the most part and it's difficult to go deep on a hard problem if all you've got is 10 to 40 hours a month. You're not going to be able to go very deep, and so I think there are certain problems that require someone's undivided attention, or at least large swaths of undivided attention, get to a really solid implementation and improve some aspect of how we build software.

Marty Haught: 16:15

I mentioned earlier the EU Cyber Resilience Act. That is going to be a forcing function that many people don't know very much about. You can think of the CRA as it's legislation that the EU has passed, and you can think of it like GDPR for cybersecurity. So the notion is that there are a lot of web-enabled devices, iot devices, applications that are maybe not as secure as they should be and become a very large attack vector and a very big problem that nations are worried about, and companies as well, and so the EU has taken action by passing a law that says that if you're going to place any commercial software in the EU market, that you're going to have to meet certain requirements around security and reporting around security with your product.

Marty Haught: 17:10

The first version of that goes into effect in 2026, and that is around vulnerability reporting, and then in 2027, all the requirements are now enforced and you will now have to not only report vulnerabilities but also have to patch them in a certain amount of time, and those vulnerabilities also include open source, which is kind of a new wrinkle. So now everything that you include in your software is in scope, and so that is going to be a very big change for companies. So I think we're going to see a lot of people talking about that this year and especially next year, there's going to probably be a mad scramble to try and figure out what a company has to do to be compliant.

David Hill: 17:53

Right. I remember when GDPR threw everybody for a while, as everybody was trying to get in compliance in order to continue doing business with the affected areas of the world. I imagine we're going to see something very similar again when that goes fully into effect.

Marty Haught: 18:10

Yeah. So to talk a little bit more about that, I am certainly not an expert. I am part of two different working groups and I guess I should step back and say that I stepped in this role around nine months ago and I had no expertise in security. I had no knowledge of these things, and so essentially, I've been learning since I started here about all these.

Marty Haught: 18:30

And with the CRA, the law has been passed and there's this period of time where the industry can interact with legislators and the agencies to firm up what does it mean to be compliant? How is the law going to be interpreted and enforced? What do we need to do from a technical system standpoint to make it possible for people to meet the requirements of the law? There's a lot of work that needs to be done. There's a lot of questions that are still open out there, and so these two different working groups one is with the Linux Foundation, the other one is with the Eclipse Foundation these working groups are global, so there's folks from all around the world involved in this, and we're essentially wrestling with those questions and trying to prepare our communities to understand and be able to be effective with this new legislation. So there's still a lot to be resolved, but I can tell you one of the things that you will all learn if you don't know about them. It's called SBOMs Software Bill of Materials. If you aren't familiar with SBOMs, you'll probably be hearing about SBOMs a lot in the future and at some point you will, in your build process, will be producing SBOMs before you ship your application.

David Hill: 19:51

Huh, I have a lot of things I need to go read about now.

Marty Haught: 19:55

So part of what I see my role is to help the Ruby community understand what this means practically and what to expect as this rolls out, and to make it easier. For instance, how can RubyGems make it easier for you to be compliant with this? We have a pretty good role to play here. So we're still early days where we don't have a plan yet. We're still waiting for some things to resolve with these working groups, but I would expect that later this year we'll have a fair amount of work to do and we'll be doing that and we'll be spending time educating the Ruby community on what that looks like. How can they get involved? How should they prepare? This is sort of what I expect is going to happen.

David Hill: 20:38

Okay, so keep an eye on the Ruby Central blog, because there's going to be stuff coming out there that's going to be very educational and informative for all of us, I believe. So I'm going to have to make sure I check that more frequently than I have been. One of the things I was going to ask here as we close out. So much of what we've been talking about is a lot of it requires really in-depth, focused time and knowledge, but at the same time, there's also, I imagine, a pretty nonstop need in terms of there's always work that needs to be done. For someone who is less experienced with working in this kind of an open source environment, what would you recommend to them for how they should get started trying to dip their toe into the open source waters and to see how it feels?

Marty Haught: 21:27

So I would say one find the area of open source that you feel drawn to if you want to get involved. I think open source is a marathon in a way. What are you interested in and how would you want to contribute? And find that place wherever it might be. And so I think with RubyGems it's critical work. I don't think it's for everyone, I don't think everyone wants to do that, but we know it's necessary for our ecosystem to thrive and be successful. And so I think if there's anyone who is interested in working on that part of the stack, first of all we have a bundler Slack. If you go to Ruby Central, the open source program page, there's a how to get involved, how to contribute section, and so you can go there and that will get you started. At least you point in the right direction.

Marty Haught: 22:17

I think there's lots of different open source projects out there that could use your time and attention, and I think, with the CRA coming, there is some concern that open source maintainers are not going to want to be active in that world, because who knows what that's going to entail for the life of a maintainer? The CRA is pretty clear that if you aren't commercially invested in your open source project that the requirements of the CRA are not targeted at you. I think if you make money in some fashion, then the area gets a little gray. Obviously, if you have a commercial product that you're placing in the market in EU, then you're You're fully applicable to this.

David Hill: 23:02

Yeah, yeah, you're all in as it were.

Marty Haught: 23:04

So I think that there's some fear around open source maintainers that aren't commercially invested, they're not making money, that this is going to be a pain for them. I don't know if that's going to be true. We'll just have to see. I think there will be a lot of interest from companies that want to support open source that they depend on, so I think it could be a very healthy dynamic. We'll just have to see how it plays out. So I think, as listeners are thinking about it, is there an area that you would like to contribute or help or get more involved? Especially if there's a library, a gym that your company uses and you wouldn't mind getting involved? I think that would be a great place to start. So I guess those would be the things I would suggest at this point.

David Hill: 23:47

Okay, great. Well, thank you for joining me today, Marty. Is there any kind of parting words you'd like to offer before we bring this episode to a close?

Marty Haught: 23:56

Come to RailsConf. I hope to see you there and we'll have a good time. All right, thanks so much for coming back, marty. All right, thanks, david. Great chatting with you.