Code with Jason
Code with Jason
306 - Steve Pike, Co-Founder of Infield
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode I talk with Steve Pike, founder of Infield, about dependency management and automated Rails upgrades. We discuss the tradeoffs of taking on dependencies, authorization libraries like CanCanCan versus Pundit, open source maintainer obligations, and how AI is changing the upgrade automation landscape.
A Paper Newsletter For Programmers
SPEAKER_01Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsense monthly.com. That's nonsensemonthly.com. I'll say it one more time. Nonsense Monthly dot com. And now without further ado, here is today's episode. Hey, today I'm here with Steve Pike. Steve, welcome. Hey Jason, good thanks for having me on. Thanks for being here. You found me on Reddit. You found my post that said I'm seeking founders and such to come on my podcast, specifically uh founders of Rails-powered startups and stuff like that. Um and you and I have only known each other for about 60 seconds. Um so tell me about yourself and and about your startup.
SPEAKER_00Yes, I'm the founder of a company called Info.
SPEAKER_01Yeah, and you did Y Combinator?
SPEAKER_00We did Y Combinator, um, and also yeah, I've been working in Rails for about 15 years at this point.
SPEAKER_01Okay. Um, yeah, and we were talking pre-recording about uh when you moved out to Mountain View briefly, um, and and I'm and I lived in uh Austin, Texas for a time. Um and now you're in Connecticut and I'm in Michigan. I wanted to make a comment. Um there there is a downside to living in a place with such nice weather. Um it makes you, well, it makes me at least feel like guilty for being inside on the computer so much. But here in Michigan, like recently the weather has been shit, and it's like I don't feel bad at all. I don't want to go out there.
SPEAKER_00Yeah, in the in the spring, in the summer, it's beautiful here in in Connecticut, but in the winter it's definitely like heads down, just get stuff done.
SPEAKER_01Yeah. Yeah, and what's uh what's kind of interesting though, I don't know if you've noticed this, uh seems to me like uh programming work is kind of seasonal, even though it's indoors.
SPEAKER_00It's busier in the summer, it seems like Yeah, I don't know if that's true for our work specifically. So I think uh definitely engineering teams have uh ebb and flow throughout the year, but sometimes the holiday season can be when more of the technical debt gets paid down. You know, there's fewer, like fewer risky changes shipping to customers, but there's more time maybe for uh reviewing and getting to some of the dependency upgrades that you've been putting on Backburner. So uh yeah, we don't really see it slow down in the winter, actually. Yeah, yeah, I can see that.
Seasonality And Team Bandwidth
SPEAKER_01Anyway, tell me more about Infield.
Dependency Pain And Infield’s Approach
SPEAKER_00Yeah, so uh yeah, I've like I said, I've been working in Rails for a long time. Um I was CTO at a company built on Rails where felt the pain of dependency management, uh specifically like keeping all of your open source frameworks and libraries up to date. So you know, something like Rails or you know on the front end side, React, you know, all these uh there's new versions of all of these dependencies always coming out. Um and so we built Infield to manage the whole dependency management lifecycle. So monitoring all of your dependencies for risk, you know, there's security vulnerabilities, but there's also you might be on an abandoned package or um you might need a new feature, you know, there's sort of reasons why you care about keeping things up to date, then um prioritizing all that work. So uh you know, what are the dependencies that I'm I'm running where I can get to the latest version with no breaking changes? So I should just batch those together. What are the ones where, say like Kuma, you know, your web server, you know, there might not be any code changes I need to make, but I need to be careful about this deployment. And then there's the really big stuff like Rails, where it's like, all right, this is an epic project. It's going to only take us a couple of months to get this framework up to date. Like, how do we break that down into small pieces? So you know, software for all of that management. And then actually doing the work. Um, so we'll you know upgrade the dependencies for you, including fixing breaking changes. So we kind of bundle all of that together into a product.
SPEAKER_01Okay. And what kind of customers are attracted to this offering? I imagine it varies a lot.
Who Buys Dependency Management
SPEAKER_00It varies a lot. We've really, I'd say, three archetypes. So you've got small companies. Uh sometimes this is even uh a founder who's semi-technical. Maybe the technical co-founder has left, but it's a profitable uh company that uh doesn't have a strong engineering team anymore, and they want to keep the product kind of in maintenance mode. So it's keep me up to date enough that I'm not at risk, keep me compliant. Um, so kind of taking all of that maintenance uh and automating it. Then you've got uh say like Series B, Series C stage startups with very strong engineering teams, um, care a lot about code quality, uh, want to be on the latest version of everything, but they're scaling rapidly and really don't want to take their like most senior engineers' time off of like feature work to upgrade uh dependencies. So could do this work themselves, but the people who can do it are like there are a lot more demands on their time. And so they uh they want to make that as fish as efficient as possible. So their teams will use our software and then we'll you know automate it for them. And then you've got uh enterprise customers. So we have some like public company size uh customers using Infield, and uh for them it's both uh I'd say outside expertise, uh doing this work safer and faster, um as well as uh yeah again lifting the the bandwidth off their team so that they can focus on other work.
SPEAKER_01Okay. And I'm curious what opinions you might have about dependencies in general. I was talking in my very most recent episode about dependencies, um, and my views on dependencies have changed over time. Um maybe 10 or 15 years ago I didn't think about dependencies that much. It's just you have a need, you grab a gem, and you got your need taken care of. Um but I've since become anti-dependency, uh um, or rather uh thinking about the price of each dependency and doing a cost-benefit analysis on each dependency. Because usually when when you bring in a dependency, you are permanently wedded to that dependency. It's easy to bring in and almost impossible to extract out. And I've been around long enough now to see the the the fashions change. And at one time Twitter bootstrap was the thing, and now Tailwind is the thing. And if you started with Bootstrap, you probably didn't migrate from Bootstrap to Tailwind. You probably began a bootstrap to tailwind migration, and now you have both, and you may well have both forever. And so I'm not interested in having that kind of situation. And gems are pretty easy to upgrade, but all these uh JavaScript and node dependencies can be a lot harder to upgrade. Anyway, just curious on your opinions on all that.
The Philosophy Of Using Dependencies
SPEAKER_00Yeah, there's a lot there. I'd say at the thousand-foot level, like open source dependencies are amazing. I think that the impact on developer productivity of the combination of like good package management tools with lock files like Bundler and GitHub, frankly, um that like you know that made developers at least 10 times more productive. You know, you can build something much if we if we go back 20 years to downloading files off SourceForge or something, or writing everything yourself with a textbook, like the you can build much more sophisticated systems more correctly today than you could um back then. And Rails has a big impact on that, but also libraries that you can use for authentication, for crypto, for uh you know, really any feature that you're trying to plug into your app. Um so I think writing, replicating that work yourself or certainly libraries uh is significantly slower. Um so you have to always have to put that up against the trade-offs of using dependencies, like you're saying. You know, there are uh risks to being committed to something where the maintainer could leave, or uh there could be decisions that are made that aren't aren't helpful to the way you want to use that library. But um but overall, I think that modern software development teams use open source and they should. I do think there's a distinction between frameworks and libraries. You know, you're not going to remove Rails from your project once you start using Rails. You can remove you you're really not going to remove even Bootstrap, like you're saying. Um but you know, if you if you want to swap out something like devise for a different authentication uh plugin, or if you want to swap out something even like Can for uh pundit, you know, your uh your authorization logic, like that is more doable. Um and that is, I think, where you have an obligation as a developer to be careful about the way that the way that you are integrating a library into your application. You know, so if you're if you're strict boundaries, if you uh test that surface, if you know how you're using your dependencies, it makes upgrading them easier, it makes migrating them easier. Um there's a clear distinction there.
SPEAKER_01Yeah, and I think it's a good idea when you're considering taking on any particular dependency. Am I good with using this forever? Like with Rails, it's like, of course, my intention is to use this forever. I I don't expect to ever switch to something else. Uh something like an authorization library, I'm not so sure. I'm not so sure that I would want to wed myself so irrevocably to something like that.
SPEAKER_00And some of it is about just I think you can confuse accepting complexity in your application with it was the library's fault. So if you decide your application is going to render PDFs in a complicated way, and you grab some library that makes it straightforward to render a PDF, and then like the layout of your tables in your PDF is funky because there's a bug in the library, like or because of an upgrade that you did to that library, uh, you wouldn't necessarily have avoided that complexity by writing it yourself. You know, there's a lot that you didn't have to think about because you grabbed it off the shelf. So that's an interesting point, that decision when you added that feature to your product.
CanCanCan vs Pundit: Tradeoffs
SPEAKER_01Yeah, yeah, and I've noticed you know, like one of the many differences between better developers and worse developers is like uh is more or less a guarantee. I've found crappy developers will make bad library choices. Um and like I don't know, I I fucking hate can can can. I I just think it's the worst. Um I I I don't rem so just like the uh the the the paradigm of it. Like it is rotten to the core. No offense to anybody who has has chosen. Oh, interesting.
SPEAKER_00Okay, we'll get to spend uh an hour getting into the the guts of it, but uh I've spent a bunch of time in the internals of it. And uh I don't know, I've seen applications use it where you get a nice centralized view of all of the authorization across your application compared to something like Pundit, where you have nice the actual uh building blocks of your authorization are easier to work with. They're more composable, it's more object-oriented, but it's spread across more files and it's a little harder to get a an answer to like what are all of the objects that this user role can see or can edit, um, which I feel like is documented a little more uh uh self-documented in in the way that Can Can Can expresses authorization. So I don't know, kind of maybe it's a thing where if you know how to use the tool or if you built it yourself, then you feel comfortable but going into a new code base might be more difficult in one versus the other, but um I haven't had that experience.
SPEAKER_01Interesting. Um okay, so my specific rationale for disliking can can can, um, I don't have it loaded in RAM, it's on disk, so let me let me try to read it from disk here. Um there's kind of two paradigms um that I've seen in authorization approaches. Um and I I might get this wrong as I as I try to recall it. Um but you have, you know, what are your entities in in authorization? Um you have your users and your roles and your resources that you can access. You know, these users have these roles, and these roles uh can interact with these specific resources in these specific ways and stuff like that. Um and I I don't think I'm gonna be able to recall right now in real time the way that Can Can Can does it versus the way that like Pundit does it. But they they take a different approach. Um it's like can this user do this thing? Maybe this is it. I might get this wrong, but uh it might be here's a user, what can this user do versus here's a resource, what can be done with this resource? I don't remember if that's it or not though.
SPEAKER_00Yeah, that's that's a good description. I think Can Can Can has more of a DSL for describing all of the uh resources that an actor can operate on. Um which I maybe it's also the kind of case where depending on what you're building, a different one or the other would um be more useful or or be a simpler description of what you're trying to express. I think Can Can Can probably works great for building a competitor and you've got a whole bunch of resources and you want to make sure users can operate on like theirs and their team's variant of those resources. You can see all of that described in one place. If you have more complicated, like context-dependent logic, you know, in this controller action, this this object should be acted on in this way. Maybe it gets a little more complicated to express.
SPEAKER_01Yeah, yeah, and this is um this is all not all, but some of it is specifically based on this um experience that I had about a year ago. I was working on trying to help upgrade Can Can Can. Um because I have to laugh because it was I have to cloak this pretty pretty heavily because I really don't want to publicly say who it was, but it it was it was a company that had a version of Can Can Can that was like 10 years out of date. Um and it was even worse, it was like a fork of Can Can Can. So the the upgrade path from their 10-year-old version to the latest version was just really there were a lot of barriers in the way to achieving that, and so there was a lot of disentanglement that had to happen in order for that upgrade to be possible. So I was trying to figure out okay, what what the heck is going on here? Um and it was very role-based. It was like, okay, we have this role. What's everything that the person in this role can do? And it sounds like that's something that's attractive to you about can. If you want to know what all the stuff that role can do is, it it's it's all spelled out there, you can see it. Um whereas the way that I prefer is uh here's here's a thing that uh here's an action that can be taken on a certain resource. What has to be true in order for the entity trying to do this to be able to do it. And it's so interesting, it's so interesting that you're in the one camp and I'm in the other camp.
Maintenance, Abandonware, And Risk Signals
SPEAKER_00I mean, I've used pundit, I think pundit's good too. I'm not saying I dislike the way pundit does it. I just I don't have a problem with the uh the style that that Kinkin can developed. I just think it's a different approach to the problem. Um I do think maybe Kinkin can has more uh interaction with the underlying like active record internals to make it function, um, because it's got to translate this DSL to uh restrictions for different types of queries, right? So there's both there's like can you access an individual resource that's been loaded, but there's also in like an index view, give me all of the records that this user can see. And uh there's restrictions on like what associated records they should be able to see, and um the way that it actually implements that makes it difficult to upgrade both the like library and you know Rails itself. You know, there's more tight coupling there in order to make the DSL function, uh, with the benefit that you can go to a page and see all the DSL descriptions and learn a little bit about what the developer was trying to express.
SPEAKER_01Interesting.
SPEAKER_00Uh more hidden foot guns and can can can for uh performance uh issues, probably. Um it's it's not easy, but it's it's possible to make mistakes. In there in your description that might cause things to get like N plus one query problems or load a bunch of records in order to iterate over them to check their uh authorization level like rather than doing it as a database query. So anyway, this is all a little beside the point. But uh yeah, it's beside the point. I think I think uh your experience upgrading though is interesting and more related maybe to what we're trying to solve. I think because we're trying to tackle two parts of that problem. So there's there's the library level, like is Can CanCan a good library to be using? So is it maintained by the uh by someone? Is it is it actively maintained and is it difficult to upgrade? And then there's okay, I'm on the 10-year-old version of CanCan. Can I upgrade it? Like, what do I what do I need to do in order to upgrade it? Is it our is and uh do I need to upgrade other libraries as well? Because they're you know, I'm using this other thing that's incompatible with the you know new version of Can Can Can that I'm going to. Um yeah, there's a lot, I think, in both of those spaces.
Caches, Mirrors, And Supply Chain Safety
SPEAKER_01Yeah, this is actually really interesting. Um so I've been working on a book that I've mentioned a thousand times on the show, um that is it was tentatively titled uh The Philosophy of Programming, and now I I changed it to something more like uh software design from first principles, I think is is the new title that I like better. Um and I'm trying to to pin down like what can we say objectively about software development, um, and what's the difference between like a subjective opinion and an objective fact. And I think there's blur there, um, like there's not a binary distinction between subjectivity and objectivity, um, but how much can we say objectively? And I haven't yet thought about dependencies uh in that. Um but there's certain things that are objectively true about dependencies, and if we want to talk about like the philosophy of dependencies, I think there's a lot that can be said there. Um something you just mentioned, I think is a great point. Um what does the uh maintenance of that dependency look like? Can we make a good bet that this is still gonna be actively maintained five, ten years from now? With Rails, for example, I think that's a very safe bet. With something that's just something some guy created a month ago, who knows? Um so I I think this is a really interesting topic.
SPEAKER_00Yeah, and I think well, there's so much there. I think there's cultural things to it. I you know, you have ecosystems that are more conservative, you you have ecosystems where it's more common to drop libraries entirely and tell the community you need to migrate to this other way of doing something. So JavaScript, for instance, is much more balkanized and like less centralized around a framework like Rails, and also it's much more common for build systems and libraries to get just discontinued. You know, like we just decided this is not the way to do uh you know your front-end build anymore. You should use you know V instead of Webpack or something.
SPEAKER_01Okay, wait, I have to ask, what does balkanized mean?
How Infield Works And Sells
SPEAKER_00Uh I don't know if that's still a phrase. I mean uh not centralized. It's uh this distributed. You know, there's a bunch of different uh competing um libraries for the same functionality.
SPEAKER_01Okay, so there must be some like historical metaphor about the Balkan region or something like that.
SPEAKER_00Yeah, I thought that must be where I heard it. I I'm not sure I can give the history lesson right now.
SPEAKER_01Yeah, all right. I'll I'll go look that up later. That just I'm like, hmm, I'd I've never heard that before. Um yeah, that's interesting. Uh JavaScript certainly does have a different culture around dependencies and stuff like that. It's like, hey, let's uh import a library to add two numbers together and stuff like that. Um it's it's a very different approach.
SPEAKER_00And then I'd also say uh on the more philosophy side, that there just is no obligation here. So I think it's an amazing thing that engineers create open source software and give it away to the world, and it doesn't create a commitment that they have to you know then be on call for every bug that is ever discovered in that library, right? Sometimes it's it's still great if you just solve your own problem and you just put the code out there for other people to use. I think that's like an amazing part of our community. And you can do that, and then that can cause massive pain for a whole bunch of other people in their day-to-day job because they happen to use your library or they didn't even know they were using their light, your library, they used something else that pulled it in as a you know, transitive dependency, and uh, and all of a sudden, yeah, for nothing you did wrong, you know, a new version of Ruby came out and it dropped support for some you know syntax that you were using, uh, which is rare, but you know, the the this happens. And you know, all of a sudden your library isn't compatible with say Ruby 3 because uh the keyword arc change or something. And you I don't think you are obligated to go and fix it, but you're also by not you know, by just abandoning your dependency, you have left a whole bunch of companies, engineers scrambling to fork it or figure out a patch around it or something. And so I I just think that's like an interesting part of our uh our world nowadays, yeah. Even at the same at the same time that I can feel that absolutely a modern software engineering team should use a whole bunch of open source software, like you have to use it to be broad.
SPEAKER_01Yeah, but yeah, I don't think an OSS maintainer has any obligation whatsoever. The obligation is a hundred percent on the people using it. It's like if you uh create for yourself a hard dependency on cer some uh third party something or other and it goes away one day without warning, uh well, that's your fault for depending so heavily on that thing with no backup plan and stuff like that. You can be justifiably unhappy with that person because like maybe that's not uh the most considerate move to just yank your library off the internet or something like that.
SPEAKER_00But I think ultimately you have an obligation to be a good actor, you know, you shouldn't push a malicious version of your uh software, you shouldn't you shouldn't inject like ads, you shouldn't inject things into your front-end library that start like popping up things uh browser, you know, there's no obligation there, but that's different from I'm not going to put more work into this, or I don't owe you more work uh just because this isn't you know doing what you wanted to do inside your company.
Rails Community, Tools, And Outreach
SPEAKER_01Yeah, yeah, exactly. And there's a whole fascinating debate around that, like the pay the maintainers, blah blah blah, all that stuff. I think all that is hogwash. Like I have the utmost appreciation for the people who spend their time doing that stuff, but there's there's a difference between that and and saying you're obligated to uh pay me and stuff like that. It's like that's just not how uh the economy works. Uh that's that's not um those there's no obligation on either side. Like I don't think there's any obligation on the maintainer's part to do anything in particular for anybody. It's just a gift. Um and then there's no obligation on the the person who's using its part to uh do anything for the maintainer or anything like that.
SPEAKER_00Right. But then at the same time, you've got you know public company-sized enterprises that are running billion-dollar businesses on top of this software, and they need to keep their software secure, right? And so when they go to upgrade their programming language, if they're using dependencies that are now incompatible, something has to happen. Either all of the companies using it need to migrate away, they need to fork it, they need to convince the maintainer to allow them to take over maintenance of the library or accept a patch at least, you know, um, something has to happen there. But well, we're what we're trying to do at least is give a visibility into that. So across all the dependencies you use, you know, which ones are at risk, which ones you know are have not had a release recently, you know, based on the you know average historical release cadence of this package, you know, it looks like it's uh maybe at risk of being abandoned. Or there's a there people have been asking a maintainer if they're still maintaining it, and there's been no response. You know, there's different factors that go into kind of predicting that something might be at risk from a consumer's perspective. And then if that's true, what do you do about it? Is there a fork that you can just switch to? Do you need to do a migration away to something that works a little differently, or should you actually think about forking it yourself, depending on you know your size?
SPEAKER_01I'm curious your way of thinking about a certain thing. Um so there was that incident some years ago. Um it's forever timestamped in my mind because there was that container ship that got stuck sideways in the Suez Canal, and right around that very same time there was an issue with a particular gem or something like that, and everybody was kind of dead in the water. Do you remember that incident?
SPEAKER_00Yeah, was that about a license issue? Did was there a version yanked because of a a licensing thing? I don't remember what it was. Was it R magic or one of the magic gems?
SPEAKER_01Something magic, yeah. And it really doesn't matter what it was, but the significant thing about that is that something happened in the world that was totally outside of anybody's control, except you know, the one person who had the keys or whatever. Um and it just caused this big problem for everybody.
AI’s Real Impact On Upgrades
SPEAKER_00And so if I'm remembering if I'm remembering it properly, I do care about I'm interested in the details of that one because I I think that that one was something I was not directly involved in, but indirectly involved in. So the the library was using a data set, and this may relate to some of the AI stuff nowadays too, though it's you know it's uh laundered a little more through the the model training. But the you have a library that's trying to do I'm just gonna say this, and this might be exactly what happened, or it might be like a metaphor for what happened, but you have a library that's trying to detect file types. And you know, if you think about how are you detecting a file as an Excel spreadsheet, you know, you have some file on disk, it's got an S XLSX expression, is that an Excel spreadsheet or not? You don't just look at the extension, you want to look at the like bits of the file to figure out what kind of file it is. And there's been a whole since the 90s effort to have open source projects with these like magic bits. So if you look at the first, you know, I forget what it is, but say first 256 bits of the file, what are these like magic bits that you can identify that every Excel file has, or every CSV file has, or every uh JPEG has? So there's these like magic uh bits, and then you take this like array of these magic bits and you overlay it on the file that you're you're detecting and if they match, then you know that that's the file type. And to do that, you need this like giant file of all this magic. That's where the magic comes from, the like name magic comes from. And I had tried to contribute magic bits back to the upstream. I think it was a I can't pronounce whether it's GNOME or Genome, but I think it was a like Linux desktop environment. Free desktop, maybe? I'm really going off the rails here, but uh literally. But anyway, there was this free desktop project that I forget if it was related to OpenOffice or just like detecting file formats inside a Linux desktop, but they needed a this like magic file. I tried to contribute some for some new Microsoft format. I had to look too far into the file, so they they rejected it because they they only wanted to look at the first you know X number of bits. But uh but I had kind of gotten in the weeds of like how do you detect these these file formats? I think that a Ruby gem grabbed just that file from the project and was using it to do file type identification. But that project was the underlying project was licensed under GPL or you know, one of the um poison pill uh open source libraries, where if you use this open source uh library, then your code needs to be open source. And then it's not your code needs to be open source. If you use this library, your code needs to be GPL'd. So it's kind of this uh I'm gonna get into licensing for a minute, but basically the library in question was licensed under the MIT license or BSD license, one of these very free use uh licenses where commercial products can use this open source software and not need to open source themselves. There's a separate license GPL that if you use it in your software, you need to open source your commercial software. Um gets complicated with web software, but don't worry about that right now. This library was using a file that meant maybe technically it should have been GPL, not MIT. And so they needed to yank the version that was using this underlying poison file and release a different way of doing the detection. Um that touches on a whole bunch of things because I think that can get like more philosophical, because I think like when I was a teenager uh you know installing Linux for the first time and like messing around with open source software and thinking that like free software was going to eat the world, like the you know, all the Stallman days and uh the GPL was really important. Um people thought we needed to legally ensure that when we give software to the world, if other people use it, they release their software too. Kind of a if you're going to use it, you should give it away. And the web just completely changed that. Um, you know, SaaS products were able to use open source software and then not give away their source code. And that led to a culture of licensing everything as MIT or BSD and allowing people to use it, and more software was created and generally good, but um it really changed from where I think a lot of the activists in the in the early days would have thought open source would have led us.
SPEAKER_01Yeah, and and by the way, I'd I started to say earlier um when you said something was beside the point. Um, beside the point is the entire point of this podcast. Um that might have been a good name for the podcast. Um so never feel bad about a digression that's the show is one giant digression. Um yeah, that's interesting about the GPL thing. I I didn't know that that's how that worked. Um, because it's like anything that's GPL would cause a cascade of the the thing that uses it has to be GPL, and then the thing that uses that has to be GPL and stuff like that. The the the larger question I was wanting to raise with that incident that happened is like what do you do in a world that anything could happen to any one of your dependencies at any time? It it kind of seems crazy that everybody operates the way that they do. It kind of seems like you should have a uh like a cached uh copy of all your dependencies or something like that. What do you think about that?
Agentic Futures And Dev Environments
SPEAKER_00Yeah, people have d definitely larger enterprises have started to do that. Um not so much because of this case, a licensing case. Uh much more common or much more top of mind is the security vulnerability case. So we've had more in the NPM uh the JavaScript package manager environment recently, but we've had malicious packages pushed uh where there have been a few attacks where someone has basically got a hold of maintainers' GitHub Actions keys or keys on their computer and been able to push versions of libraries in their place. And then you've got a whole bunch of uh consumers of those that are just automatically pulling the latest version off of uh NPM to use in their application. And uh so because of that, there uh there's been a lot of concern recently around what are the if if I'm using 100 JavaScript dependencies and a new version comes out, do I actually trust taking it or does that need to get vetted through some um security barrier first? And so there are companies that are doing automated review of these new pushes to see if they look like malicious code or not. That's very hard to do reliably, you get a lot of false positives, and you don't catch and if you don't catch 100% of the true positives, then you're you can't totally rely on that. Um so we've had simpler solutions like have your own cache of the NPM registry and then do a uh uh cooldown period. So we just unless a developer has explicitly opted into a new version of the dependency, we just don't install things that are you know newer than a week old or something or two sold. So there's a little cooldown for the community to find it. Um you get all these kind of collection act collective action problems then of you know how do things get detected if everybody is waiting, but um it kind of gets figured out. Yeah. But I have seen a lot of adoption of that recently. Okay, interesting. Running it running your own mirror and then maybe um doing a little bit of a cooldown.
SPEAKER_01Um and I'm curious about your like business model and how the product works and stuff like that. Like do you sign up for a subscription and then there's some kind of uh thing that you run periodically or constantly? How does all that work?
SPEAKER_00Yep, yep. So we're a web app that you you install our GitHub app, assuming you use GitHub, so we can get live access to all of your dependencies and also the source code to contribute pull requests back. And then we scan all of the dependencies, we give you a view of what's at risk, help you prioritize upgrades you want to do. We have tooling in the in the software for breaking that problem down. So I'm on you know Rails 5 and I want to go to Rails 8. To do that safely, I should make 150 pull requests to incrementally get there, right? Because I I want to go step by step and break that into small, easily reviewable chunks. So our software breaks that down, and then we will actually make the pull requests for you. And some of those we can do totally automatically, and then for some, we have a uh we also have a services arm where we'll do uh manual work for you as well.
SPEAKER_01Okay, interesting. Um how did you get your earliest customers?
Betting On Practical Automation
SPEAKER_00Yeah, so I did this work purely as a consultant for a few years. Um let me go back to maybe the beginning of Infield. So we were I was working on a different uh startup in the data space, decided to pivot away from that, and was thinking about problems that I wanted to go after and tackle with my co-founder um Allison. And I kind of thought back to my experience running startups on Rails and pains that I had that I had felt. And I always, and you know, I I love the open source community, I always wanted to do something that made the open source community stronger. And so I thought about the pain of upgrading Rails specifically and then generally keeping keeping on top of all of your dependencies. And at the same time, uh GPT-2 had just come out, and uh we got some early access through YC, and it became clear that there were new things that were going to be possible um with these language models. So when we started InField, I went out as a consultant and just upgraded gnarly Rails us by hand, just like doing it uh to try to figure out what the real problems were, what we could automate, and at the same time started to experiment with language models. And the first insight was, and at this time, really all you could do was we can use these models to start to make sense of all the unstructured content that's out there about code. So if you think about where a maintainer lists breaking changes or things you need to be aware of in upgraded independency, these are upgrade guides, these are changelogs, uh, maybe commit messages. There's all of this text that's written about code, sec overflow, you know, GitHub threads, all these things. How can we make use of that? It became possible to start to structure it. So we could we could run it through a model and pick out breaking changes from a changelog, or one really useful thing is to go through a changelog history and find undocumented incompatibilities. So incompatibilities between packages that are not expressed in a gem spec, but only in you know a GitHub issue somewhere where somebody says, hey, I tried to upgrade to version two and I'm also using this thing and it broke together. So you know, issues between gems. Started to build software to do that. And um yeah, kind of went from there. So then uh you know, raised a seed round and started to build out the software from that angle. The first thing I've got to do.
SPEAKER_01There's kind of a chicken egg problem. It's like you you you want to get money in order to grow, but in order to get the money, you need to make a compelling case that you can grow. Um and so maybe you need to get some customers and get some growth to show that you're going to continue to grow. Otherwise, it's like, why would I bet on this horse? Um d did you deal with that kind of chicken egg problem and how did you navigate that?
Closing And Where To Learn More
SPEAKER_00Yeah, I we got paying customers to pay us to do it for them. Um, at the same time that we were building out prototypes of the automation. It became clear after even three customers that everybody is reinventing the wheel. You know, I was finding issues, encountering breaking changes in dependency upgrades that I could repurpose from one customer to another, um, even with just a couple. Uh yeah, and even um anyway, so started to put that into the software as well. Um and yeah, kind of proved out of prototype that hey, we can make this dependency management problem maybe not 100% automated at that point. You know, the the real like coding agents hadn't come out yet, but we can certainly make this 80% uh more efficient, um, faster, safer, uh cheaper. And uh so the story kind of came together that way.
SPEAKER_01Okay. And it seems like if you were doing this for consulting, you already had some sales and marketing going for your consulting. Maybe you had a a network of people and and you got consulting clients via word of mouth and referrals and stuff like that.
SPEAKER_00Yeah, exactly. And I think uh deciding to focus on we started in just Ruby and Rails. Now we do JavaScript, Python, a little Elixir also, but Rails is still a big part of the of the business. And starting in a single community that's close knit, uh there's a lot a lot more leverage to the marketing efforts and sales efforts, and uh and also you can build a lot more kind of special purpose tools. So we have an upgrade path tool for Rails upgrades that is really good. So it'll tell you between your version of Rails and the latest version, here are all the other gems that need to be upgraded along the way. And we run a solver to find the best version of all of those to upgrade to in between. So can we find a version of each of those that's dual compatible with your current version of Rails and the next one? If we can, you can upgrade that as a standalone PR. So we can break that down. Um so tools like that have been really useful for Legion.
SPEAKER_01Okay, interesting. Um, do you do conferences and that kind of stuff? You know, when you when you reached out on Reddit, um that was the first time I'd heard of Infield. And I'm aware of other upgrade services and stuff like that, like um, and and you probably are too. Like uh my friend Ernesto Tagworker, I've had him on the show a number of times with um Fast Ruby, and then there's reinteractive, they do upgrades also. But that was the first time I I had heard of you guys.
SPEAKER_00Yeah, we gotta do uh more marketing, or I guess I maybe I could um get some opinion from you on what you see other uh what you see as the best places in the Rails community to get the word out.
SPEAKER_01Yeah, I don't claim to have the right answers. I can only uh tell you where I've how I've become aware of these other things. Um these people do uh do ads in Ruby Weekly. That's definitely one thing. Um and then conferences, that's a huge thing. Like whenever I ask people where they get their customers or consulting clients and stuff like that, a lot of them are very active with conferences and they meet people that way.
SPEAKER_00Yeah, we found the the legion of having free tools that you can use to get into the product and then um either upgrading to the services arm or to the full platform has worked. But uh yeah, I want to do a lot more on the on the sales and marketing side and reach out in the community. I uh there's kind of like two different approaches that companies are taking in this space. So you've got the consultants that I think are adding on some degree of automation in AI, and they're trying to do their work more efficiently with um copilot or cloud code or something. And then you've got pure software companies that are trying to build uh things like dependabot or um automated dependency upgrade systems more like what we're building, um, but a lot of those are really tackling like the easy 80% and leaving kind of the hard stuff. So you have things that comment on dependency upgrades with whether they look safe or not, or um things that are are like dependabot, but uh maybe batch um your upgrades together or try to make them a little easier to digest. We've really focused on how can we automate the gnarliest framework upgrades first. So if we can solve Rails upgrades, then we can solve the rest of it. Um but solving Rails upgrades is really hard. And uh that's kind of the approach that we've taken.
SPEAKER_01Okay. Um yeah, and another thing, of course, uh, and obviously this is probably why you're here, is like going on podcasts is a good uh marketing tactic. And I can tell you uh that you know not everybody has the desire or appetite to do this, but starting your own podcast, like wow, I've made so many connections and this podcast has benefited me so much. Um and then for me personally, um writing has worked out really well.
SPEAKER_00Uh yeah, we had a lot of success with a newsletter we run called Once a Maintainer, where we interview an uh open source maintainer. Um done a whole bunch. Uh we've interviewed people from the Rails core team, interview people from uh who work on like PIP, the Python package manager, or some like scientific Python uh frameworks, uh where we do an interview and then we write up a uh it's a written interview based on the discussion that we have. Um yeah, that's been great. And also just kind of really interesting to get out and talk to maintainers of open source packages. Um yeah, that's once a maintainer. Um yeah, there's always a lot more we can do.
SPEAKER_01Yeah, I have heard of once a maintainer.
SPEAKER_00Um yeah, maybe we tried a little too hard to not put our name all over some of this stuff. You know, we we didn't leave you know uh we trying to be like a genuine part of the community and not like always advertising our thing, but uh it will find the right balance.
SPEAKER_01Yeah, yeah. Um yeah, I was gonna say something else, but I forgot. Um it's it's my uh duty and obligation as uh co-chair of RubyConf 2026 to to bring up that conference. Um were you aware of of that happening? That's gonna be in July uh in uh Las Vegas.
SPEAKER_00Yeah, I am aware I was aware of it coming up. I don't we're not uh we're not gonna have a table. Uh maybe we'll uh it we'll find our way there though.
SPEAKER_01Yeah. Yeah. Um we're we're trying to make it a fun one. And I had my own conference for three years uh called SinCity Ruby. Um and I think people found that a lot of fun. There's there's a lot of regional conferences today, which is really nice to see. Yep. Yeah, yeah, that's great. Um okay, what else? Um we've we've covered a lot of ground, but I'm sure there are a lot of things that uh that I could ask you about that I haven't yet. Is there anything that comes to mind?
SPEAKER_00Um Yeah, I think it's maybe worth talking for a minute about the impact of AI on some of these upgrades and the upgrade work, because I think uh we st like I said, we started early in the in the GPT days with like let's make some text, which was kind of as someone who's built a lot of expert systems before for doing um like data in ingestion and data matching. So I've done like a lot of Nity resolution, you know, are these two things the same thing? Um cleaning up data sets, ingesting them, ETL, all that kind of like data work. The stuff that the language models can do out of the box uh was amazing and really like changed the what I thought was possible. Um and so what part of starting in field was this problem of making dependency upgrades safe is really a data problem. Uh right. So a lot of people have tried to tackle dependency breaking change analysis and fixing more the way we tackle linting, uh, more like a compiler's problem. So, like, can we write an AST transformation that makes this upgrade safe? And I think that that's just the wrong like lens to approach the problem from. I think the right one is this is actually a data problem. If we can find dozens of instances of other people doing this upgrade before, we can learn from that what is necessary to make this upgrade safe or how to automate this upgrade. But to do that, we just need to get a lot of reps. And so that's what we're uh one of the great things about having a free lead gen kind of version of our software where you integrate our GitHub app, we give you useful tools, um, but we can also see the upgrades that you attempt to do and see whether you roll them back or see uh whether they're safe or not. And so we've really taken the tactic of we want to grab all the data that's out there around upgrades and um synthesize it into a into a useful system. Over the last year, it's now become possible to take that data set. Here's an example of code changes, or here are breaking changes from a change log, or here are say that new tests that uh an open source container added in a new version of a library. Here's all the data about what changed. Let's actually go out and fix the breaking change automatically. So let's set you know claud codes loose in a sandbox and have it try to do an upgrade for us, you know, including updating application code. And that's like really starting to work, and I think that's really exciting. Um I think it's sort of nuanced though. Uh we're nowhere near, in my opinion, being able to just like check out a repo and have a coding agent statically upgrade Rails. Like there's just too much that even a human expert can't do just from reading the code. You need to run it. Um you need like runtime context to figure out whether you need to make a certain change in a certain place. Um so I think the the future is a combination of uh special purpose tooling and like we have a gem that you can install that sends us real-time deprecation warnings from your applications so we know where breaking changes can be found so we can fix them. You know, stuff like tooling like that combined with um the agent models can start to actually um fix these things.
SPEAKER_01Okay. Yeah, your approach is really interesting because like if I were to try to do dependency upgrades using AI, um, you know, my first thought would be like plug it into Claude Code or whatever and say, hey, uh upgrade my Rails version, run the tests, uh look at any failures, and if there's problems, you know, just try to do whatever you can to make those tests pass and just like do that loop until you get as far as you can, and uh here you go, have at it. That's that's the first thing that comes to mind. Um but your approach is much deeper and more thoughtful. Like it didn't occur to me to like you know, I don't know if this is exactly what you're doing, but it sounds like basically the idea is to like go out onto the internet and and do research and like get smarter about how these upgrades tend to go for people, uh what kind of upgrades are problematic, what kinds aren't problematic. If you run into a specific issue, what do you do about it, blah blah blah, and bring all that stuff in. Um and and don't just let the uh vanilla um Claude or Chat GPT or or whatever just do what it happens to be capable of at this moment. Bring in your own gain capabilities and bring those to bear when you're doing your upgrades.
SPEAKER_00Yeah, and right now that's required. And I certainly for our for our customers and certainly for code bases of any kind of substantial age and size, you can't just tell Cloud Code to go and upgrade your Rails app and expect it to work. Um and I and I think the gap between where we are right now and it being able to do that is not just scaling the model further. I think it's being able to solve that problem without any special purpose tooling or expertise that's overlaid on the model of directing it, I think is pretty close to AGI. Like you like I said, even in even an expert software engineer would struggle to do that without feedback loops and without reading documentation and understanding all this stuff. And um but when we can break the problem down and say, hey, step one of a hundred is upgrade this specific gem, you know, you need to upgrade paper trail from 10 to 11 to unblock the Rails upgrade. Here are the breaking changes in paper trail. Um, you know, maybe you can do that piece, uh, and then we can we can bundle that together into a full plan.
SPEAKER_01Yeah, that's that's an inspiring thought. Um, and it makes me wonder, and and we should probably start heading toward a conclusion soon, so maybe one or two more more questions, but that makes me wonder um if there is a broader applicability of this general idea. So the general idea I'm thinking of is like not just pointing the agent at your code and saying, hey, whatever you're capable of with with this kind of problem, uh do that. Versus um uh I I don't know how you characterize it, but what you're doing. Like go out and bring in specific things and and blah blah blah. How else can we apply that idea to other things besides just dependency upgrades?
SPEAKER_00Yeah, there's a lot and something I have a lot of thoughts, and I don't want to start something that we don't have the time to finish, but I think there's a ton of effort out in the commun in the startup community right now to build infrastructure for all of these coding agents. And there are you know very fundamental pieces, like uh developer environments. So there's been a push for a decade now to have remote developer environments where you containerize your developer environment, you make it trivial to spin up new ones, you're using something like VS Code server to connect to it, um, and you can just like destroy and create new full developer environments instantly. With a developer with a dev database, with a you know being able to actually go and run your code and test it. And you need that infrastructure to make the agent work. Like that infrastructure is mutt makes it much more productive to set something loose than infrastructure than just checking out a Git repo and having them look at it statically. That's a piece that has not been solved and people are working at. And so I think there'll be things like that that just unlock uh more tasks being achievable. And then I think, like you're saying, there's special purpose tooling. So dependence management is is one space, maybe security analysis is another space that people are looking at. Um, but spaces where combine special purpose tooling, you know, like we have uh solvers that we're running and planning software that we're running that spit out individual tasks to do. Um I think that there's you know that copy and pasted across different verticals is interesting, but then you're actually executing the tasks, you need some underlying infrastructure to run them on, and it's it's not just checking out some repo in a in a folder.
SPEAKER_01Yeah. Um wow, there's a lot that I wish we had time to dig into there. Um you know, when when AI was newer and we had to just tab back and forth between the chat and the browser um from the beginning, I'm like, this is not the the ultimate form of this. This is gonna change to something more um uh what's the word? Ergonomic. Um and you know, it did. Now we have agentic AI, clawed code, and stuff like that. Um and I've also had the thought that like uh surely it's gonna be the case that we're gonna have like containerized development environments that are like isolated, because you don't necessarily want to have some uh agent running on your machine and potentially polluting it and stuff like that.
SPEAKER_00Uh you want to have this And there's no way you can there's no way you can run a thousand them in that case, you know.
SPEAKER_01Yeah, exactly. Um and so and it sounds like you have your finger on the pulse uh regarding what's being worked on a lot more than I do. And my one of my biggest fears is missing out and and not finding out about the newest techniques and technologies and stuff as soon as I as I could. So if you're up for it, I'd love to have you.
SPEAKER_00Yeah, sorry. We'd talk about more of that another time. I think it's just as a as a concluding thought on that, I think it's it's fun to be in the space. I think it's we're as someone running a startup in this space, we're all taking bets on where we think the puck is going with incomplete information and no one has complete information. And so if in a year you can tell Cloud Code, upgrade my Rails app and it upgrades some million line of code Rails app by making 50 pull requests in series by planning that itself, I will be wrong, and that will be a transformational impact on the industry. I don't think that we're going to be there in a year. Um I'm making a bet that it's somewhere it is still useful, but it is somewhere short of that. And so if I serve up the right expert environment for it to do the work in, um, we can do upgrades safer and faster uh that we could do them before. Um so that's the bet that we're taking of what we're building. And um and we're also just you know really trying to come at it from the other angle as well. So, what is it that our customers want? What our customers really want is to never think about dependency upgrades again. Like they they want to be on the latest version of all their dependencies and they don't want to break production. And how can we make that true? You know, it's a combination of all the automation we're building and then um you know actually getting in there and doing some of the work for them when we need to for it for the ones that want that piece. But um as a on the business side, really, um got to build what they actually want.
SPEAKER_01Indeed. Um, very last question for you. Uh where should people go online if they want to learn more about you and Infield? Yeah, infield.ai. Okay. Uh well, Steve, thanks so much for coming on the show. All right, thanks, Jason.