The Changelog: Software Development, Open Source - Rails is having a moment (again) (Interview)

Episode Date: October 31, 2024

(Includes expletives) David Heinemeier Hansson (DHH), creator of Ruby on Rails and co-owner of 37signals, joined the show to discuss this Rails moment and renewed excitement for Rails. We discuss hard opinions, developers being cooked too long in the JavaScript soup, finding developer joy, the pros and cons of the BDFL, the ongoing WordPress drama with WP Engine, and what's to come in Rails 8.

What's up? Welcome back. This is the Change Log. On this show, we feature the hackers, the leaders, and the innovators moving the Rails world forward. Yes, this week, Jared and I are joined by David Heinemeyer Hansen, also known as DHH, the creator of the Ruby on Rails web framework and co-owner of 37signals. We are coming hot off the heels of Rails world, and we're discussing this renewed excitement for Rails, devs being cooked too long in the JavaScript soup, finding developer joy, the pros and cons of the BDFL being canceled,

the ongoing WordPress drama with WP Engine, and what's to come in Rails 8. So a disclaimer on this episode, there are several explicits, and it just didn't make any sense to bleep them all, so be warned. A massive thank you to our friends and our partners over at fly.io. That is the home of changelog.com and the public cloud built for developers who are productive,

developers who ship. That's us. That's you..com and the public cloud built for developers who are productive, developers who ship. That's us. That's you. Learn more and deploy your app in five minutes at fly.io. Okay, let's talk Rails. What's up, nerds? I'm here with Kurt Mackey, co-founder and CEO of Fly. You know we love Fly. So, Kurt, I want to talk to you about the magic of the cloud.

You have thoughts on this, right? Right. I think it's valuable to understand the magic behind a cloud because you can build better features for users, basically, if you understand that. You can do a lot of stuff, particularly now that people are doing LLM stuff. But you can do a lot of stuff if you get that and can be creative with it. So when you say clouds aren't magic because you're building a public cloud for developers and you go on to explain exactly how it works what does that mean to you?

In some ways it means these all came from somewhere like there was a simpler time before clouds where we'd get a server at Rackshack and we'd SSH it or Telnet into it even and put files somewhere and run the web servers ourselves to serve them up to users. Clouds are not magic on top of that.

They're just more complicated ways of doing those same things in a way that meets the needs of a lot of people instead of just one. One of the things I think that people miss out on, and a lot of this is actually because AWS and GCP have created such big black box abstractions. Like Lambda is really black boxy.

You can't like pick apart Lambda and see how it works from the outside. You have to sort of just use what's there. But the reality is like Lambda is not all that complicated. It's just a modern way to launch little VMs and serve some requests from them and let them like kind of pause and resume and free up like physical compute time. The interesting thing about understanding how clouds work is it lets you build kind of features for your users you never would expect it. And our canonical version of this for us is that like when we looked at how we wanted to isolate user code, we decided to just expose this machines concept, which is a much lower level abstraction of Lambda that you could use to build Lambda on

top of. And what machines are is just these VMs that are designed to start really fast or designed to stop and restart really fast or designed to suspend sort of like your laptop does when it closes and resume really fast when you tell them to. And what we found is that giving people those primitives actually, there's like new apps being built that couldn't be built before, specifically because we went so low level and made such a minimal abstraction on top of generally like Linux kernel features. A lot of our platform is actually just exposing a nice UX around Linux kernel features, which I think is kind of interesting. But like you still need to understand what they're doing to get the most use out of

them. Very cool. OK, so experience the magic of Fly and get told the secrets of Fly because that's what they want you to do. They want to share all the secrets behind the magic of the Fly cloud, the cloud for productive developers, the cloud for developers who ship. Learn more and get started for free at fly.io. Again, fly.io. I-O. Well, we are back with David Hennemeyer Hansen. For the fourth time, DHH, you're always welcome on The Change Log. Thanks for having me back once more. Lots to talk about. Lots to talk about. Where to begin?

Questionable even where to start. There's so many things. Let's start with Rails. I feel like Rails is having a moment again. Do you get that feeling too? I totally get that feeling. I think Rails 7 was a real turning point. We set some new ambitions and really took a different turn from a lot of the direction that has been followed otherwise.

And now with Rails 8, we've doubled down, tripled down on doing things differently. And I think that's just resonating. Not that Rails is suddenly the thing that makes sense for everyone in every situation, but it is more clearly defined what we stand for and how we're pursuing it. And I think that part is resonating. And I also think there's now a generation of developers

who've been cooked in the JavaScript soup for long enough to realize that maybe it's time to look elsewhere for developer joy. And that's sometimes when you could have had some really nice stuff and it wouldn't have mattered because the React train would have pushed everything out of the way and nothing would have been able to sort of live next side or beside it. And now that a bunch of people have gone through it, they've realized, oh, do you know what?

There are some areas we don't like it as much. It doesn't really fit here or I just don't enjoy working with it. The conversation is suddenly open again. The window for folks to explore other technologies, including things that have been around for quite a while, like Rails that now has 20 years under its belt, has suddenly opened. And I think for me, having the patience to wait for the pendulum to return to some of your positions is one of the real joys of have been around for this long i've seen that pendulum swing a couple of times on some of these major evergreen topics that we love to discuss like uh static versus dynamic typing or

anything else like that where you can just see that pendulum and it swings it goes to the one side and then just give it two years. It's going to come back past you. And if you just stay consistent and you continue to elaborate on the things you believe and advocate for techniques that you think are good, do you know what? Eventually the pendulum is going to pass you. And then when it does, which I think is what is happening right now with Rails, the pendulum is right in our orbit.

Also have some humility, enjoy it for the limited time and realize that in two years, it's going to swing somewhere else. I guess so. If you had to say, let's take a note from a town hall recently. If you had to say five nice things about JavaScript, what would it be? I don't actually have a hard time doing that. And I often say this with a bit of a smirk, but JavaScript is my second favorite language. It's a distant second. Ruby is by far my favorite, but I enjoy JavaScript. Now, what I'll say with that is I enjoy the JavaScript that I get to write without all the built stuff, without all the pipelining.

I enjoy the JavaScript that I can run in a browser, a modern browser, the ES6 plus stuff with import maps and all these other things that I enjoy. That's the version of JavaScript I enjoy. I don't really like the version of JavaScript with all the types crammed into it. I'm not a big fan of TypeScript, to put it perfectly blunt. But JavaScript as it exists in browsers today is actually kind of awesome. Now, I don't want to write my backend in it. But do you know what, if I had to, for whatever reason, Ruby didn't exist, I probably could do it. And I wouldn't be that discontent about it. I think JavaScript is actually good. I think especially the fact that now we have the basic structures for object-oriented programming.

I think this is one of the wrestling matches that's been going on in the JavaScript world for some time. It's like, how much do we even want object-oriented programming structures in our language? Now, it's there. It's in there with the SX. So I get to write JavaScript that's quite similar to Ruby, just sort of, I don't know, a slightly lesser version, but existing in the same paradigm in the same universe. And I enjoy it. I mean, we have released Hotwire, which includes Stimulus, which is a framework for building interactive components.

And then we have Turbo, which is a way of sort of getting away from writing as much as those things, but combining those two things together, the JavaScript I now write for the web applications we build at 37 Seagulls, it's a pleasure. It's not like I'm not like, ah! If you had asked me, I don't know, 2011, 2009, I would have gone like, I can't deal with JavaScript. Give me some CoffeeScript.

Give me some other syntax that kind of makes this passable. That's not true anymore. JavaScript today is good. What is the JavaScript soup? Describe that. It might be obvious, but what is the JavaScript soup that people have been stewing in, as you said? Well, there's the framework side of it,

and then there's the build side of it. And let's start with the build side of it. The part of JavaScript I've really come to not enjoy is this idea that a lot of projects were set up with about a million dependencies. And if you left those dependencies alone and didn't stay on top of them for about five minutes, the whole thing just fell apart. This was actually the main motivating factor for me on the whole no-build train. I went back to a project that I

had written a bunch of JavaScript for. I think I was trying to move some JavaScript from maybe Basecamp to Hey. And that JavaScript depended on a bunch of things and i wanted to move it over into a new project and i just all the dependencies just clashed i was just stuck in this soup of like there's so many things there's so many packages my node modules folder was i don't know 2000 deep and i just went this is so frustratingly difficult to take a piece of software that I myself wrote not that long ago and to bring it forward to something new and to make it work. And, you know, I don't like that. Then the other part of it is all the sort of mechanical steps that you need. I think things have gotten a lot better.

But at the moment of peak frustration I had on that project, we were on Webpack. And I think Webpack was amazing for what it was able to do at a certain period of time. And this is one of the reasons why when I say soup, I say it halfway lovingly because I have also come to accept the reality that a lot of progress depends on like an awkward phase. It depends on a complex phase. We're trying to do something new and we don't yet know how to do it simply. And the only way we can do it right now is complicated. And I think JavaScript really went through an awkward phase in that regard. Webpack was part of that awkward phase.

It was highly complicated to set it all up and get everything working. And now today we have things like ESBuild and other tools that I think are following not just a better approach, but a better philosophy. ESBuild, for example, resisting a configuration file. I don't know if that is that still true. I'm not sure. But when it first came out, they were like, we're not doing configuration file. And I was like, oh my God, that is beautiful. What an amazing constraint to put upon yourself that the tool has to be so simple that all the options i need they can fit on the command line by the time we get into the webpack configuration files like we've actually already lost the plot i love that kind of stuff but even so i don't enjoy the build pipeline So key component to getting out of the soup is to leave all that

behind. We've been able to do that with that hashtag no build phenomenon where we write the JavaScript and the file as it looks in my editor, that's the one we ship straight to the browser. There's no transpiling. There's no compilation. There's no chunking, there's no on any of these other, there's no tree shaking. There's none of these techniques that were for a hot moment, take it for granted that you absolutely needed these things to build modern web applications, and you needed them to be fast and whatever. And I look at all that whole orifice of complexity, then I go like, you know what, I'm glad that there at least now exists an alternate path. Maybe there's some apps and you want to write it like that. You love TypeScript and you need a compile of that anyway. Okay, fine.

I mean, peace be with that as long as you enjoy it. I didn't. And as long as I have an alternative path here that doesn't include any of that nonsense and I can just write JavaScript in my text editor, not even my IDE. I mean, I think there's a whole discussion there too. I don't need autocompletion. In fact, I find it annoying a lot of times. I know that's not a majority position.

Most developers would be like, what do you mean I can't autocomplete my things in code, VS Code? But there's different ways of enjoying programming. And for a while, I felt the way I enjoy programming, which is mainly through a text editor where I ship things directly and don't have a ton of moving pieces, was not available in the JavaScript world. That path was just blocked. It had hit a dead end. And the only way to do it was this other way. And I was a bit miserable there. And now I'm no longer miserable.

I get to write for the web. I get to use JavaScript. And I get to do it in a way compatible with how I like to program, which is just a wonderful place to be. Let's hone in on that hashtag no build, because there was a big debate around that. And I think it's a microcosm of a bigger debate, which seems to be this dichotomy between developer experience and user experience and like which one you put first. I kind of sit on that fence and I can see both arguments.

I don't know. I don't have strong opinions. You obviously have strong opinions about darn near everything. So to somebody who says, well, great, you're not going to bundle. You're not going to chunk. You're not going to tree shake. You are putting yourself first. You're not putting your user first.

H2 is supposed to bring us this reality. It hasn't. Look at the performance benchmarks, et cetera, et cetera. H2 is supposed to bring us this reality. It hasn't. Look at the performance benchmarks, et cetera, et cetera. What's your response to that argumentation? There's two aspects of that. One is facts and the other is opinion. And I think when it comes to facts, a lot of people sit with a collection of facts that are simply out of date. They have not updated their premise as to whether things like HTTP2 works or doesn't work. Or they're relying on synthetic benchmarks that are not representatives of, for example, how I write modern applications. So I think getting your facts straight, and sometimes that's like, it's not that your facts were wrong.

Like they were accurate in 2015, 2017. They're not accurate in 2024, because a lot of things have changed. And I think that's the thing that have excited me about developing for the web and using JavaScript in the last three to four years. The game has really, really changed. HTTP2, of course, that predates that. And I remember the benchmark most people do refer to. I think it was Khan Academy or something that wrote something up from 2015. And they used a benchmark set where you're like, oh, if you're including 2,000 files, this is what happens. And I go like, yeah, don't do that. That sounds painful.

Why would you? And it comes into the same idea of if you're accepting the premise, the JavaScript has to have this insane dependency tree where your node modules directory is like two gigabytes full of hundreds of thousands of files. Yet that model of how to build for the web is ill compatible with what I'm talking about. You don't have to build like that. You don't have to have a node modules tree that has hundreds of thousands of files and gigabytes of space. You can build in a different way. And this is how we build things at 37signals. If you look at the main app where I really got to push the envelope on these topics, it's hey.com. So hey.com is an email client.

We compete with the likes of Gmail or Outlook 365, whatever. So we got to do all the email things, right? And email, I think for a long time, correctly was held up as an application that needed a very high level of fidelity for the user interface. It needed to be fast. It was sort of a desktop-y app on the internet. And people, I think, erroneously thought for a long time that the only way you could build something like that was with literally megabytes and megabytes of JavaScript. If you look at Gmail

and how much they download, I think uncompressed, it's 28 megabytes of JavaScript that it takes to load the whole Gmail interface. And I just go like, I didn't even, what? 28 megabytes of JavaScript? How many, is that decades of man years that's invested in producing 28 megabytes of JavaScript? That just sounds wild. And I also recognize if that's the domain you're playing in, you have 28 megabytes of JavaScript. You've got to use all these techniques. The 28 megabytes probably came from 100 or 500, and it was tree-shaken, and it was chunked, and it was all these other things.

When I look at, I think hey.com, when we launched at least, had like 80K kilobytes, 80 kilobytes of JavaScript. And that was including Turbo. It was stimulus. It was about 120 stimulus controllers, I want to say. It was Trix, our WYSIWYG editor. It was that bundle of stuff, and it was, I mean, just orders of magnitude less. And it did not depend on half of NPM. It depended on very, very few things.

And those things were sort of neatly packaged up. There was a handful of packages. So when you build things that way, you end up with an application that might have, let's say, for hey.com, we have about 100 JavaScript files. That's not a hard problem for HTTP2. It just isn't. Again, if you're the 28 megabytes, and if you segmented that into individual files, and you were trying to download, I don't know, thousands and thousands of individual files, which was the false premise, as I saw it, that that original Khan Academy benchmark was based on. Okay, I don't know what happens there. Probably, there are some trade offs. Are the trade offs as

clear as they've been presented? I also don't think so. The fact is, when you take a large bundle and you break it into smaller components, you get very different cache dynamics. Now, this is one of the reasons why when people use bundling, they also use chunking. It is a way to address the rate of change such that when you make one change, you don't invalidate the whole thing. Now the user has to download it all again. The way we build things, we have really optimized that part of the equation, that maybe you download, or not even maybe, you will download more files. Those files are tiny, but they are set for far future expiration. They will last on your desk for however long the browser allows them to last, because most of them don't change. Most of the rate of change is a new functionality that's being introduced or like one file here so forth so the whole premise

that we're choosing between developer experience or user experience is false when you look at the whole picture of it it's not false in the sense if i don't want to change anything about how i write my application and i want all these dependencies and whatever. Okay, there are some trade-offs. We don't have to do it like that. And we're presenting one alternative. Well, not even one. We're writing all our applications like this. We haven't started anything new that was using a built pipeline

for four years, I think, maybe now at this point. We've made a bunch of applications still. We have several in development. They're all going all in on no-build, not just on the JavaScript side of things, but also excitingly on the CSS side of things. Style sheets had that same phenomenon. We used SAS for many, many years. SAS has a complicated build pipeline as well. Now we just use the CSS that the browser can ingest because the browser's caught up on CSS2.

Now you have nesting. Now you have all of these parent selectors. You have all the things that people normally reach for when it's built pipeline. So it's just a false premise. And I think some of it is based on, as I say, facts that are out of date. And then some of it is based on, okay, if you want the TypeScript thing,

and if you want a lot of, if you want React, for example, if you're all set on that, yeah, there are some different trade-offs. Maybe you can't make applications how I make applications. But then we can't make it that categorical that, okay, how we're building it means the trade-off is in user experience. It's just not true. I think that's fair. Back to Rails 8's big moment and this pendulum swinging back. You said earlier that Rails has a set of opinions which are contrarian or going against the soup that we currently have existed in. And people are starting to look outside of that. Could you list off a few of the things that Rails believes, whether they're 20 years old now or if these are new ideas that are coming out with Rails 8 that

really sets it apart from everything else? Yes, let's start with the things that are evergreens, things that have been true since day one. The number one thing is probably the full stack ambition, that Rails doesn't try to be like one library you slot into a vast collection of other libraries that you have to go around selecting between a bunch of choices. Rails, ships, omakasa, as we say, chef's preparation, the entire menu has been set for you. You can do substitutions. You don't want this part, take it out. But when you show up on

day one, someone has thought through all of the components that you need to build a modern web application and has made sure that those components actually work together, that they've been configured to work together. You're not going to find like, oh, I wanted to use this thing, but it fits really poorly into the other thing. And now, well, that's up to you. You got to figure out how to solve that problem. We take a very ambitious approach to the web problem. We want to solve everything in one box, whether it is talking to a database, whether it's generating HTML, whether it's processing inbound requests, whether it's handling job queues and asynchronous tasks, whether it's dealing with web sockets, whether it's sending email, whether it's receiving email. There's a lot here, actually,

if you look at the total scope of what a substantial modern web application has to deal with. And I have depressingly found that when Rails was introduced, a lot of other people were also interested in the whole problem. You look at someone like Django or other contemporary frameworks, we had the same ambition to try to tackle the whole problem. You look at someone like Django or other contemporary frameworks, we had the same ambition to try to tackle the whole problem. And somewhere along the way, I think particularly

in the JavaScript community, I don't know if it was a lost nerve or because people just thought it was too big of a problem, but we ended up in a space where there's a bunch of libraries to do all of those things. But it is your job as a developer to figure out how all this stuff fits together, works together, is optimized together.

And then you end up in this unfortunate situation where every single JavaScript app seems to be like this bespoke collection. So jumping from one app to another, if you get a new job or you move between projects, it's actually quite difficult because, oh, we use a different ORM mapper here than I did in the last project. And here we use this front end web firm. So there's very little retained value from the skills you're developing in certain parts of the whole pyramid of libraries and frameworks you need to develop. And that is then exacerbated by the fact that the churn in the JavaScript world seems just to be just turned to 11. Things go out of date instantly. I just, I mean, sometimes they go out of date on like developer Twitter, and that actually has very little bearing on like what people are actually doing.

I thought a great example of this was someone had done a benchmark between something in Rails and Express.js. And the first thing, the comments showed up to say, no one uses Express.js anymore. They use whatever Nuxt or this other thing or the third thing. And then I was like, oh, wow. I thought Express.js was still the thing.

And I thought, okay, maybe it's out of date. Then I looked at this other chart. Everybody uses Express. Everyone uses Express. except for like the 10 people who comment on stuff like fastify yeah there's a couple of them there's there's both the reality of things churning incredibly quickly and then there's i think also just a culture the churn is actually amazing that we should all be using frameworks that were invented six months ago otherwise they'd be horribly out of date and it's not best practice. And we have to accept that that level of churn has an immense cost. And in the Rails community, we've said, you know, that's not what we're interested in.

We're interested in solving problems and we want to use the best techniques we can do to solve them. So it's not like we're bound to the past. But if you learned how to use Active Record in like 2009, 15 years later, those skills still have value. You've invested in something durable. And that is a dividend of trying to solve the whole web problem. We're not constantly replacing every part of it. So you can build on top of skills that you can have, and you can have the compound value of that. So for Rails 8, we introduce a bunch of new things. There's some new things to learn, but we're not wiping everything underneath that. It's not a clean sheet of paper of like, now learn everything over from scratch. I think there's too much of that

in the JavaScript world, or at least there's not an appreciation that certain problems once they're solved, not just well enough, but good, it'd be nice if we could leave some of the pieces of the pie just intact from one version to the other. So that's one thing of it. Rails is wedded to the idea of having ambition for solving the whole problem. So we have all the frameworks,

we solve front-end, back-end, all the stuff. The other thing, and this is one of the things I've been harping on lately, is the idea that we want to solve the whole problem and that solution has to be able to fit inside the mind of one developer. This is a one-person framework. I want Rails to be so powerful that you can basically build anything in it,

but I also want the toolkit to fit inside not only my head, but anyone's head, such that someone starting tomorrow, they want to build a competitive, modern web application. They can do it alone, by themselves. They don't need these thinly sliced pieces of expertise. They don't need a front-end pipeline engineer on day one.

They don't need even splitting front-end from back-end in terms of engineering. They can say, well, I just have a developer. And at some point when I've built a bunch of stuff, maybe I have two, but they can do all of it. And that allegiance to the programmer, the web programmer, this integrated unit, someone who's dealing with the whole problem, I also find is quite rare. Again, in the JavaScript world, they seem quite keen on separating front end from back end. And here you have your GraphQL experts.

And then over here you have your React experts. And maybe they talk because there's some coordination, but they're not the same person. Rails really wants that to be true as late as possible. So when you start on day one, you can hold it all in your head. By the time you arrive at Shopify level and you literally have thousands and thousands of programmers and you're processing somewhere between 10 and 20% of all commerce on the internet. Yeah, you can have some specialists. Of course you are. It's about delaying that moment.

And I think the Shopify example is actually great because when Toby started building Shopify, one Toby. One developer, yeah. One developer. It was one Toby that took Snow Devil, the original shop that he built, and turned that into Shopify. And then by the time that became like a $100 billion business, yeah, it was a large team. But it's the zero to one transition that kills the vast, vast, vast majorities of attempts at starting a new business. It's not that most businesses go out of business by the time they're 100 billion. In fact, they get quite resilient at that size.

It's that they go out of business because they don't produce something valuable that customers actually want to buy at a timeline before they run out of money or patience or savings. So when we have to choose in the Rails world who to optimize for, I optimize for Toby on day one, not Toby on year 12.

Now, what's fascinating with that choice is they're not actually so much in opposition as you would think. A lot of the optimization for keeping Rails small, slim, and integrated enough that it can fit inside one developer's head is also the stuff that makes it a joy to use even at scale. Now, there are new problems. You have different problems when you have thousands of developers. And sometimes you even deal with frontier problems. You deal with problems no one else has had before. That to me, by the way, is the best definition of web scale, that you're hitting thresholds that no one's seen before. You actually literally have to invent some stuff. You have to invent usage at a scale that no one has done before you.

So they have those problems to deal with, but they also have a base that's really solid that they can build on that is welcoming to new developers and can be a joy to use. I mean, it's hard to make a code base with 5 million lines of code. I think it's what Shopify has at this point as enjoyable for everyone to work on as one that's like 10,000 lines of code or 5,000 lines of code. But you can keep a holder connection to that for longer. So I think these are some of the evergreen controversial parts of the Rails equation that are still true. And what's so fascinating to this for me is I thought it was obvious when I started Rails

that full stack was the way to go, that you should optimize for the single developer, that convention over configuration was sort of a fundamentally better stance than the old way of you have to spend days setting things up. And I therefore thought that the entire developer world would come around to those principles. And Rails, to some extent, would just be kind of just a step on the way. And others would take the same ideas, and they would put those ideas into new incarnations.

And Rails would have contributed to that evolution of the industry. But like, all right, not that we were going to be here 20 years later. And I found the opposite to be true. I found there is less purchase to some degree of these fundamental ideas today than there was in 2004. Now, some of it is that our industry is like 100 times larger than it was in 2004. But also some of it is that these ideas are fundamentally at odds with how a lot of programmers think about the problems they're solving. They don't actually want someone to put the whole toolkit together for them. They want to do the bespoke thing.

They don't actually want their skills to compound over time. They want to learn something radically new every six months. They don't necessarily care that much about an application they wrote five years ago still working because they change jobs every 18 months. That, by the way, is the standard in our industry. So true, yeah. So they don't get to pay the penalty for some of these decisions. So therefore, we end up in a world where a lot of the things that makes Rails special is actually not what developers want. Fascinating. Fascinating. There are definitely, so I've been around the entire time as well, and there are people and projects that came after Rails that list specific things that Rails does in their inspirations.

I think convention over configuration, for instance, has not just stood the test of time inside of Rails, but has actually permeated other projects. And then, of course, there's always those that rail against, no pun not intended there, whatever is currently the status quo, because that's how they get the likes, the contracts, right? I mean, what's new is what sells. And so we're very much highly motivated unknown

yeah to do that absolutely and i also think some of it is generational and that is the fun part of it yeah around for so long you see things in fashion for example whatever mid-2000s like all the socks they had to be angled socks right because we went from a phase where people use tennis socks and they get went up high do you know what the most uncool thing to wear now is angled socks you know what the cool thing is tennis socks right some of it is just like the generation that comes afterwards they don't want to do the thing you did do the opposite thing that you did they want to do the opposite and i think that actually to me explains a large part of the affinity for functional programming like people went like oh the old farts they they liked object

oriented programming we've got to pick the other one same thing with dynamic typing versus static typing right we just that's that pendulum i was talking about that a lot of these things swing between two things fashion angle socks versus tennis socks jeans that kind of go out or go in skinny jeans they're also they're not hip you i mean that's the worst thing to wear right now right so they swing and you can look if you zoom out far enough you can see that pendulum move back and forth between two points not 25 points it's not like we go like bouncing all over the place we just go from like that generation had that thing they like then we swing back and we skip one right and this is how we help assert our identity as new people coming up. So, I mean, sometimes it kind of, it's funny.

And I think what's most funny about it is when there's no degree of self-reflection that that's what's going on. No, no, no, really. Angle socks just are cooler. They're just better. No. Right. What kind of socks do you wear, David?

You know what? It's so funny because now I've used that example a couple of times. And now I do look at my ankle socks and go like oh my god i've gotten old i need to change my entire drawer now with the cool tennis socks i'm wearing ankle socks so no shows basically oh no shows well now i mean that that's a good move because then people are thinking does he even have socks on i mean no yeah they're like a cool sock you got stinky feet in there come on but the other thing is you can just wait long enough, right?

And this actually goes into the discussion. That's right, wait it out. Just wait it out. Give it another five years, we're back to angled socks. There you go. And this is one of the reasons why when I look at some of these big things like functional programming versus object-oriented programming or static typing versus dynamic typing, I'm also like, all right,

you know what, right now, to now to some degree my preferences they're not the vogue thing like functional programming has more of kind of like the hot new thing which is funny cloud right now all of these things fucking have roots going back decades and decades and then the static typing now too really has a a moment and a lot of people like typing i'm like yeah do you know what i'm just gonna sit here and wait it out and like in in three years object-oriented programming with dynamic typing it's gonna be the hot new thing yeah and you'll be here you'll be here waiting that's right something else that's old which rails 8 is making new which i'm excited about is all these sqlite integrations into making doing a lot of the stuff where you used to have to rely on a Redis

or a Memcached or something. Or in my case, a lot of times when I was deployed to Heroku, somebody else's service. I felt like one of the things that for me was grading with Rails is I would get to production and then I felt like, because I was building apps for customers,

and then there'd be all these additional services that they would have to also add in in order to run that thing in production. I kind of felt bad about that. And so I liked i liked for instance what elixir was doing where you could just run background jobs without having to have a redis or something like that and rails 8 is like bringing that into rails via sqlite which for the longest time and maybe this is your fault david because unintended consequences right the convention of having sqlite as your test database but using mysql in production which you probably decided that back in 04 for a lot of us it made us think sqlite's a toy like you

don't run that thing in production but for use cases it makes sense you certainly can and so now rails is kind of embracing sqlite to do some stuff can you tell us the details yes so sqlite is exactly one of those beautiful moments to me where we take something old that in a past context with an old set of facts could not be used for the things we use it for today if i had tried to use sqlite in the way we're using it now in 2009 when the underlying technology was a spinning disc like the Rust compilations that were the thing before we had SSDs and NVMe's and so forth, it wouldn't have worked. SQLite would not have been a great storage for caching, for example. It would just have been too slow. You have that

freaking reader head on those disks that have to move. It just can't do it at the same pace that RAM can do it. So SQLite, I think, started out with a certain context, and that context was largely embedded situations. You can put it inside your app for a single user. Great, fine. And it was held back by this constraint that the underlying storage is quite slow, as it was before SSDs. And then also that compute was quite slow. So the amount of work a single machine could do in say, when we started, the first box we started Basecamp on was a one core Celeron 2.8 gigahertz machine. That machine today is two orders of magnitude slower than what you can buy for the same amount of money. That means what in 2004 required 100 machines and the coordination of how they access a shared data store and whatnot can now be done by one computer. And there is a vast, vast simplification possible when you can remove

the entire network layer of distributed computing. When you can run a even large application on one box, that is really, in many ways, kind of the golden ticket for simplicity is to run one box. And that's what SQLite is optimized for. It is optimized to run on a single computer on a local drive, and then it can actually be staggeringly fast, almost unbelievably fast, expectation premise busting fast. This was one of the things we found out when we started doing these benchmarks is like, holy smokes, how is it that SQLite, for example, for the cache use case can be in the same realm as a Redis

that's moving things around purely in memory? That's just incredible. And then it's even more incredible if you introduce that Redis or Memcached or whatever lived on another box because now you're limited by the network layer. You take the network layer out and you're writing straight to this this is just incredible so real aha moment for me when you started putting all these pieces together computers have gotten so much faster storage have gotten so much faster and so much bigger i mean you can now terabytes of storage is trivial in terms of cost.

Again, wind the clock back 10, 15 years. It was really expensive to get terabytes of storage. And then it was also slow. So the fundamentals have changed. And Rails 8 is trying to reap the maximum value out of those changes and rediscovering the best things from the past that we could only use in certain contexts and then go like, well, things have changed. Now the context is so much wider. SQLite is no longer just a development database. It is a completely credible production environment

for a lot of applications. Not all of them, but this is classic innovator's dilemma. So this is one of the things that happens. The innovator's dilemma is that new entrants comes in, it starts looking like a quote unquote toy. Oh, that's just for the low end. Oh, that's just for the cheap stuff. And then step by step, it moves up the ladder because it has. There's no server. It's so much simpler to run. It is so much cheaper to run. You can run it've moved up so far now that Rails 8 uses SQLite for literally everything out of the box. We use SQLite for the jobs, the queuing backend. We use SQLite for caching. We use SQLite for the WebSockets coordination. And obviously, we use SQLite for the main database that your domain models are being persisted into. That's all of it, which means that the deployment story gets so much better, gets so much simpler. You don't have to set up a MySQL server and nurture that server and feed it all the things that needs to be fed.

You just have a bunch of files. And the only consistent or persistent process that you have is your application server. That has opened up all these other doors for lowering the cost of deployment. This is one of the things that Rails 8 is really a lot about, about the fact that you don't need platform as a service. Rails 7, all about no build, Rails 8, all about no pass, no platform as a service required, no Heroku necessary, certainly not with all its extension. Now you can use any $5 VPS or your own server or your own hardware or whatever to deploy, and you can move between these things.

This is the other thing. I have tremendous respect for Heroku. It's actually mind boggling how far ahead they were of the entire rest of the industry. And for how long you would have thought that advantage would have been erased in a couple of years. And they had it for a decade. Everybody's still trying. They're still trying. They're still trying.

And I think actually, even though the tragedy is that Heroku was left to rot, right? It was bought by Salesforce and they've left it to rot. I'm not saying there's no one there. I'm not saying the people who are still there aren't nice, kind, caring, professional engineers. All that's true. But you look at what happened between Heroku getting launched in 2007 and until they were bought, it was basically the world. They turned everything upside down. And you look at what happened since salesforce bought them and now nothing's happened right so that's just a little sad but whatever this is what happens in the world of commerce

things get bought and they get stuffed inside some big bureaucracy and i think it is our job or i consider it to be my job as an open source software developer to go like, all right, all this great philosophy and even technology existed in this commercial project. Now that commercial project has been left to rot. Let's make sure we rescue some of those ideas. We're not going to go back to whatever the norm was before Heroku. Developers don't want to go back. They want to have like one command, deploy.

With Heroku, it was git push. With Kamal, it's Kamal deploy. Okay. That's where we want to be. So let's bring those things out. And I think Rails 8 has really done it in a way I'm just incredibly proud of because the speed with which I'm able to start a new application, develop something basic, use some of the other new Rails 8 features, like generating some authentication and then taking that to production, like full on, ready to go, ready to serve internet traffic, like I have everything exposed here as a real IP to the internet, that path has never been shorter.

And not only has it never been shorter, the fact that it no longer leans on some commercial subscription that you need, that just warms my heart. Like I love commercial interest in all of these things. I think it's great that we have commercial companies who want to improve developer experiences, da-da-da-da-da. But my heart really is with open source,

and I want the default to be able to be open source end-to-end. You should be able to start a new application, do all the development, deploy to production, run it in production, operate it at large scale on an entirely open source stack. And then the commercial part is optional. Amen. Well, our friends over at

Speakeasy have the complete platform for API developer experience. They can generate SDKs, Terraform providers, API testing, docs, and more. And they just released a new version of their Python SDK generation that's optimized for anyone building an AI API. Every Python SDK comes with Pydantic models for request and response objects and HTTPX client for async and synchronous method calls and support for server sent events as well.

Speakeasy is everything you need to give your Python users an amazing experience integrating with your API. Learn more at speakeasy.com slash Python. Again, speakeasy.com slash Python. When you say no pass required, is that synonymous with no cloud? I mean, it's kind of how I read that in a way. Is it not synonymous?

No, no. I mean, yes and no. So where's the difference there? I think in the past, right, you were thinking, what would it take for me if I wanted to have my own server, I call up Dell and say, hello, can you send me an epic box with 48 cores? And here's the address to the data center I want delivered. The jump from getting that piece of iron able to host your application was kind of tricky, right? It was quite different from the Heroku path. Like anyone could set up Heroku. Far fewer people would feel comfortable setting up a physical box. I want to shrink that gap such that the bare metal deployment scenario looks virtually identical to the cloud deployment scenario. using the same configuration. It's using the same method of thinking about it. But also, most people don't start by phoning up Dell to order a $5,000 piece of hardware. They go like, oh, I have an idea. I'd like that idea to get online. Oh, Hetzner has a VPS for

$12 a month with a couple of cores and enough RAM for me to run it. I'm going to deploy there first. So I think still the path for most developers will go through the cloud first. I want to make sure that when they do that, they don't end up getting locked in to a commercial platform, which I've seen time and again happen, including on Heroku, where some relatively large services suddenly have some very, very large bills that are making things quite difficult for them, and they kind of don't feel like they can get out.

They feel like they're in too deep, and that would be a huge project to move off Heroku. I want to make it a trivial project. I want it so that you can start on the cloud, because I think most people should. Now, what is cloud? I think that there's a discussion there, too. That's why I was asking that,

because you said VPS in your prior argument or discussion about this and then i asked the question and i get what a vps is it is in the cloud i get that it's it predates the term cloud though right but it's yeah exactly it's not it's not ec2 right it's not amazon web services cloud in insofar as that when you come in here you have an ecosystem of things to build upon. Whereas a VPS is a standalone server. You can then connect to other servers if you want to. And there may be other services, but is that cloud? Because I feel like that's more

like a rented single machine. I think that's very fussy. And I think there's one side of the aisle that want to label everything that touches the internet cloud, because then all we argue about is sort of some nontical thing. And like, oh, we're all doing cloud.

We do private cloud. Private cloud just blows my mind. Like that's sort of some nontical thing. And like, oh, we're all doing cloud. We're doing private cloud. Private cloud just blows my mind. Like that's such a nontentical term. Because we've watered down the idea of what is cloud. For me, cloud is exactly as you say, EC2 with RDS and open search. Like that's cloud. That's what I think of as cloud. When I, for example, rent a dedicated box from Hetzner, I don't think of that as cloud.

Now, obviously it's fluid, right? Like where exactly is the line? Is it VPS or is it Droplet? Is it Droplet Cloud? It's renamed. That's VPS renamed as a cool name from DigitalOcean. Yeah, a little bit, right? So I think it's all quite fluid. And also fundamentally, I'm fine with that fluidity. I don't care. I just want you to have a path, a roadmap, a tool to get from A to B to C to D to E without it feeling like there are hard lines and hard walls. I want you to be able to start on a BPS or a VM or a dedicated box and move every which way around them. In the Kamal config, for example, that we ship with new Rails 8 installations, Kamal is the deployment tool that we've made default. It should be as simple

as changing the IP deployment addresses. And that IP can point to the VM, it can point to the VPS, it can point to the dedicated box, it can point to your own hardware, and Kamal won't care. It'll be the same. Now, part of the pitch for Kubernetes, for example, was that that was going to be true sort of at a broad scale and it's totally awkward. It's not true at all. I've never, ever seen a Kubernetes installation of any sophistication being able to just, oh, we're on Amazon? Like flip the switch, George. Let's move over to GCP. What? No.

That's like, flip the switch, George. We'll start having the meetings about the meetings about how we can move out four years from now. That's what the Kubernetes migration path often is. And I was just, yeah, there's got to be a better way for that. At least for some style of application. Now, again, I actually think Kubernetes is an amazing piece of open source infrastructure. And if you have it in your heart that you want to start the next AWS or the next GCP or the next even DigitalOcean, you should probably look into Kubernetes. You're going to be operating at that scale and you're going to have hundreds of engineers. It's going to be very complicated. Great.

Kubernetes sounds wonderful for you. I've looked at Kubernetes enough. We ran Kubernetes on AWS for long enough that I realized that is not what I want to do with my time. And it is not proportionate to the kind of problems that we have. Something far simpler is possible. And if that simplicity is achieved, we also get portability. And I think portability is actually less of a thing at super high scale. It's not that common that huge applications and huge businesses move from one provider to another.

Where I want to make sure that the portability is present is in the early days. Is that you start your startup and you started on, maybe you started on maybe you started on heroku whatever or something else like that and you could just move on you don't get locked in you don't get locked into cost basis that's prohibitive yeah so if you gradually let's let's give you a place to go you know let's not stick you where you got to be at where you've been where you want to go let's go there and this And this is the thing. I mean, I think one definition of cloud,

that perhaps is a little antagonistic, is that cloud means lock-in. Cloud means proprietary encapsulations of simulacra of open source services. It means open search. It means, what do they call it? Is it open cache? I forget what the cache product is.

But there are all these managed services that the cloud providers have that usually have some sort of proprietariness to them, that you are not developing skills as an organization or an individual in the underlying technology, whether that technology is MySQL or Redis or whatever, using the managed service. And that is the key trap the cloud has for keeping you put, right? If you had developed a bunch of expertise in say MySQL or Redis or anything else, you could take that expertise and you could take it somewhere else. If you developed a lot of expertise in like RDS maintenance, I think that kind of stays with Amazon, which is of course exactly what they want. Now, sometimes these things do break free. I think S3 is a great example of something that broke free, where S3 was Amazon's encapsulation of an object storage. That then became an industry standard. And we were able to migrate between these things. That's actually the migration we're doing for 2025. We're getting out of S3. We have, what is it,

eight petabytes or something in there, and we got to get it out onto our own stuff. And what we're moving on to something called pure storage, they have an S3 compatible layer. But a lot of times that's not what's happening. And especially even worse, if you get sucked into the Lambda nonsense, all the serverless nonsense, not only is that usually highly proprietary, it's also usually the most ludicrously expensive part of the whole cloud equation that really only makes sense if you have these extreme dynamic ranges where your spikes are a hundred thousand requests a second and then you go down to like five all right fine i guess it's great that you could buy things piecemeal but if you have a steady state of load none of that stuff makes sense of course it doesn't make sense right it's like buying your toilet paper like one snippet at the time they're not

going to charge you what adds up to a whole roll right like you you buy that shit in bulk because you know you're going to need it like every day for a year and going forward yeah i think there's a very small set of constrained applications that make sense under that model. And I think that the sales pitch is that everybody should be using that model. I think those two things are not alike. I want to go back to SQLite

because I'm just obsessed with this idea. Have you guys, how much have you put it through its paces? I'm thinking of it, and it makes sense, Redis replacement, CacheStore, PubSub. But you said even for the primary application database

to a certain extent. Have you put it through its paces? Do we know, is there a line in the sand of writes per second or requests per second where you're like, yeah, let's throw in a Postgres instead? Yes. So we have two commercial products in the wild that use SQLite.

They are of the single tenancy nature. So the one product is Campfire, a chat system like Slack, where you get the code and you can install it and run it on your own server. We boiled it all down to like a one command setup so that you can run your own instance of this chat system. And it runs on a single machine and it runs SQLite. And we did a bunch of performance testing to figure out like where are the limits here? And I think the top machine we used was something like, I want to say, was it 30 cores or 24 cores, something like that. And that got us to 10,000 concurrent chatters that were all saying something once a second or something.

So we pushed it quite far, much further than almost anyone who was using a single tenancy application ever would in this circumstance. But now we're getting curious. Of course, I'm getting curious. I'm like, all right, it works for that case. It works for the case where someone buys Campfire and installs it on their machine and they can run up to 10,000 shadows. That's great. But we also make other SaaS products. Would it work for something like Basecamp? Would it work for Hay? All right. Maybe those are just beyond, but we're working on two new products right now where we're exploring exactly that question. How can SQLite work in a multi-tenancy setup? And there's some real appetizing benefits as to why you would even attempt that. And one of them is isolation. So when you run multi-tenancy on SQLite, where each individual customer has their own database, first of all, none of the data is touching.

You're never going to have like, oh, it bled into the other account. Even if that's not with modern development techniques, that's not the major thing. But what is a major thing is right now on any multi-tenancy app built on Postgres or MySQL, exporting that data into a format where you could then import it again is not trivial at all. And a big part of that reason is that the primary keys, they're all intermingled. So I have 10,000 customers, they just get primary keys assigned off the basis of an integer. It's intercom remitting. So the data doesn't kind of go back in quite as neatly as necessary.

It goes back out. But if SQLite has the entire data set for one customer, you could literally give them the file. You're like, hey, here's the SQLite file that you've been building up on our service. Now it's yours. And then also, by the way, if you do a model like we're exploring, where that data could then run on your own instance of the app that we're building, that's pretty freaking cool. Now you could run that data in a SaaS setup if you want that. And you could take the data straight out and run it on your own server if you prefer to have it in your own sort of setup. I really like the sound of that.

I really like the idea that some of the scaling challenges that multi-tenancy apps run into, they run into because the whole system just gets too large. You look at something like Basecamp, it's just terabytes and terabytes of data, right? It's actually not, it's still a hard problem. How do you make a database fast when you have tables that are terabytes in size? Right. You got to do things with indexes, but at some point that even breaks. And if you're doing joins in a certain way that doesn't work, some of those problems get a lot simpler when the data

size gets smaller. So if you think of each customer having their own database and you're mainly putting in text there, it's going to be uncommon, I assume, for let's even say let's imagine Basecamp brand like this, right? Any individual customer would have, what, 100 megabytes? That's a huge account. Imagine 100 megabytes just of text from one customer, right? Now, suddenly a lot of the scaling or tip over problems, they're just trivial. They don't even exist. Now, at the grand scale, when you're using Postgres or MySQL, you have to do actually quite complicated things. Worst case scenario is you have to shard.

Shard sucks, man. I mean, rebalancing shards, setting the mob, it is very complicated. We have thankfully been able to resist that complication because computers keep getting faster and we keep getting bailed out by the faster computers but by the time you reach again shopify scale or something else like that you need to shard that's really complicated then you need multiple readers and multiple replica writers and all the orifice of running distributed synchronous data storages like not for the faint of heart now again in most cases that's not a zero to one problem that's a problem when you have enough money to

throw at it but i'd still like to see that radically simplified could we get to a world where even at that scale you could just use sqlite because it was all infinitely sharded to one database per customer. I don't know. So that's the other answer. The real answer is I don't know. I don't know what the upper limit is. I know what some of the theoretical limits are.

And SQLite is amazingly, stupendously quick for the theoretical stuff. I like the idea of the take it with you, you know, data sovereignty kind of thing for the customer. But it's also kind of like the aspect of serverless that you like because it can spin down effectively to zero if the customer isn't active. There's no cost to you in the business.

I mean, there may still be the service SQLite sitting there doing its thing, but it's not doing anything for that particular customer. And so there's no activity, there's no cost. That's the problem with something like MySQL, for example. So MySQL for us, we use the table format. The InnoDB cache is a global cache. We're all sharing it. And that cache

needs to be enormous for the database to be fast. So I need to, since you have everyone's data freaking in memory, or the bulk of it in memory all the time, whether it's being accessed or not, because if they do show up, and I don't have have it in cache and I have to do a table scan, well, bye-bye system. You're going to lock up the database, which, by the way, is another really appetizing potential

benefit here is every single outage we have ever, not every single, the majority of outages we have ever had with our database was that somehow some query from one particular customer tickled a tip over point where suddenly we're doing a table scan. And now we're table scanning a terabyte. And like it takes down the whole database because all the resources just go into servicing that query and everyone else is on that same database. So, yeah, good luck. Everyone else is screwed because Paul had an unreasonably large instance in some case that we didn't expect, that we didn't design for.

We missed a pagination thing. With SQLite, when each individual database is its own database, it's kind of quarantined. Maybe you can cause some trouble for your own little thing, but it's not going to cause trouble for everything else have you looked into or entertained light fs so when

you get to sql light at scale i call it sql i'm sorry college are you up man well we talked to richard hip at one point it's better than what the prime calls it he calls it squeal light i'm like what do you mean? When I said it out loud, I said it differently than the both of you. And I was like, I need to apologize real quick. We had Richard hip on the show and he told us how to say it,

but I can never say it his way. Adam's done a better job of remembering it, but I just call it sequel light. I can't help myself. I committed to memory and I can't stop. So that's how it works. What's the official way? Like meteorite.

He actually named it after meteorite. So it's like, see, say it Adam. SQL. I SQLite. So it's like, say it, Adam. SQLite. SQLite. It's just a lot of syllables. Like meteorite. T-I-L, man.

I know. He's a nice guy, though. And he's like, say it however you want. He's not going to dictate or anything. But the original idea was meteorite. SQLite. SQLite. Everybody thinks it's about light, but it wasn't about light.

It's about light. Which fed into this unintended consequence you alluded to earlier in the fact that it was the default database for Rails, but when you went to production, you went to MySQL. Right, because it was a light version. You should think it was light. Yeah, it seemed like light, non-pro, non-cool, single file, throwaway, toy, all those sort of synonyms.

So LightFS, that's the cloud thing, right? I believe this is... Ben Johnson, right? Ben Johnson, the work of fly.io as well. It's LightFS, it's distributed SQLite. SQLite. Way to say it your way. Now we're all going to be thinking about it the whole time.

We have not actually dug into any of that stuff yet. I am kind of, I'm of two minds here. On the one hand, I tremendously sort of celebrate what the team behind, see, now I'm getting super self-conscious about this. Just say SQLite, it's okay. I'm sorry. SQLite, what they've done, like it's three guys

that for literally for 20 years have just said, hey, this is open source, you can look at the source, but we write it. We don't actually take patches. This is our thing, and it's amazing. I mean, that's incredible. Fucking three guys who created the most popular database system in the world, and it's not even close.

I think SQLite is just probably like a hundred x or a thousand x more used if you count up all the individual databases than any other system out there but it also means that if someone wants to use it in a different context like they do face some challenges because they can't just submit a patch right that's not going to get accepted so light fs is one example. I just spoke with the guys at Terso who are doing LIP, SQLite, and they're essentially forking, trying to maintain upwards compatibility, but doing feel about that because I so respect what those three guys that made the original were able to do and that they're still doing it. I mean, stamina out the gazoo here. But it's also cool to see this concept of a serverless database

being pushed further. Now, funnily enough, with libsqlite, it's being pushed to a server. Right. It's one of the things that's being formed. But I love all of it's being pushed to a server right it's one of the the things that's being forked but i love all of it i want to see this explored and i also want to see a bunch of experiments i think we are just now waking up to the fact that this little database engine can do far far more than what we had in our head five years ago we thought oh embedded services great but for web application stuff it's's development, it's testing, it's a tool.

And now suddenly, it's not. Lots of cool ideas. One that I'm thinking of while you talk, if you had a multi-tenant SQLite-based base camp-like thing, and you had your phone apps, you could actually do offline first with their own version of the database, local, and then just synchronize back to the main one that everybody's sharing and that could be a really cool way of easily

at a lower level than your application code getting offline first up and running which would be pretty rad yes now i'll take one one note here with what you said you used the word just before the other word synchronization it It's just a little sync. Just a little sync. Such thing as just synchronization. Just sprinkle some sync on in there, Dave. Exactly, sprinkle some sync on it. That is one of the hardest problems that we have. And this is, I think, also one of the reasons

why SQLite, for example, have been used on single tendency so well. If you only have one user, the syncing issues are less. But yes, I like that too. And I also know that that's what the Terso folks are exploring. That they're trying to do? That they're trying to explore, what if you ran these SQLite databases on the individual boxes, but you were syncing constantly up to some cloud servers that were distributing. Now you could get readers around

the world. That's some of the stuff that the Fly.io folks were interested in. I understand they maybe wound down some of the investments they've made in that area but the general concept is really strong and i don't think i mean we're only just starting to scratch the surface of what sqlite can do in web applications and this is one of the i find it a little annoying when i talk about this because people well sqlog is already the most amazing database that's been used. It's not new. No, it's not new, but sometimes something existing put in a new context is new.

Right. And it is exciting. I'm super excited. It's like Kaiser Sosa, you know? Anyways, that's not a direct anomaly. Don't spoil another movie for us, Adam. Come on. Well, sorry about that. I do want to toot the horn of Terzo really quickly. I've talked to Clobber. We were supposed to work with them. I think they're

launching this month something. And I haven't gone into their story enough. So we, David, as you know, we're sponsors. So we have a lot of cool tech companies that work with us. And we were excited about this one. It didn't pan out. I think it's going to happen in 2025. Wow, to say that number is kind of crazy. But part of their why LibSQL portion says, and it kind of references back to what you said, it says to get to where it needs to evolve in regards to SQLite, gosh, to get to where it needs to evolve,

however, SQLite is open source, and as you said before, not open to contribution. That's why we created LibSQL. And so they have something cool happening. I think what we're all sort of revolving around is this idea that there's something beneath the surface further that's worth exploring for SQLite. That there's more there. It's been there for so long. It's written by the greats of programmer world, like Richard Hipp and his team. They've been of the greats for so long is written by you know the greats of programmer world like richard hip and his team like they've been of the greats for so long dedicated they've got these slow and steady

mantras of the about the ways they work it's trustworthy software it's stable reliable software of decades and decades at this point so let's let's mine those hills and see what's there. And this is one of the things I'm just excited about with Rails 8. So if you wanted to use SQLite for a web application today, you have to know a fair amount of a little bit arcane knowledge about how to set things up

in the right wall modes and set the right pragmas and do all the little tweaks because SQLite folks are really dedicated to backwards compatibility. So if you start a SQLite database from like 2005, it's going to load, it's going to do all the things. They really cherish that, which means that to run SQLite in the way we would want to run it today on a multi-tendency

or a multi-user app, you have to set a bunch of tweaks in it. And that was a little bit, I think, of a barrier for some folks. They would start using SQLite and then hit all these exceptions. Oh, I can't write right now. It just throws an exception. Well, yeah, you've got to build up a thing where you do a retry and da-da-da-da. Rails 8 has all of that built in. It is fully configured to use SQLite to the best of its current ability

with all the correct pragmas and all the correct protocols of how to use that database well. And I think that's what's going to really help the adoption. When you don't have to know all the little arcane bits and pieces, and you just rely on the fact, hey, this is a database in a file, and it works. Awesome. Let's go. Yeah. Very exciting.

Well, we're talking about SQLite and this dynamic trio. I don't know. I know Richard Hipp and his team. Open source, but not open to contribution. It's making me think about open source. Of course, there's a lot going on in open source with relicensing

and with just thinking about the models. Of course, you're a big fan of the BDFL, Benevolent Dictator for Life model. And so I am historically as well, but I do wonder what happens when your BDFL goes on a bender. Are you referring to anything in particular? It boggles my mind. What if DHH goes on a bender

and just starts going scorched earth in something? You could really ruin Rails' reputation very quickly. Have you thought about this, David? I have. Curiously enough, there's been occasion to ponder the model of open source recently. The whole WordPress drama, of course, was something I think brought a lot of folks to think about what does the license actually mean? What about the norms?

This is one of the things we talk about in other realms with sort of governance. How much sort of is written in law and how much do we depend on a set of norms that we all just take for granted? And I think we had a bunch of norms that I took for granted about open source collaboration works

that were, let's just put it politely, challenged in the WordPress drama. Things like retaliatory actions when it comes to code repositories and so forth. When I suddenly think like, oh man, Rails really depends on RubyGems being an open neutral platform that is not engaged in kind of trying to push its own advantage in these ways. And the BDFL model, I think, too, does hinge on a single individual. That is both its greatest strength and its greatest weakness. And we have to accept that those things come together as a package.

There is no such thing as just a universally better governance model that does not have tradeoffs. The committee model has also been tried. You know what? I'll hold the accomplishments of the BDFL model against the committee model any day of the week when it comes to open source progress. If you think of most of the major projects that we all use and love, they have run under the BDFL model. And I've seen what happens to projects that get mirrored down in unclear vision, unclear direction, a thousand cooks all pulling in their own direction. It's not great. We don't get the kind of software we want

to use and we enjoy to use. A lot of that is downstream from a coherent, uniform vision. And that just happens to be the model you get with the BDFL setup. Again, you should look at that and go, does that mean it's always going to be flawless or that we're never going to have WordPress scenarios? No, of course it doesn't. In fact, if anything, what's remarkable about the WordPress drama is how novel it seems. Why hasn't this been happening every six months all over the place in projects left, right, and center? Why is this one of the first instances of a project of that size getting embroiled in these kinds of debates? That to me, more than anything, is kind of one of those exceptions that prove the rule.

And the rule is the BDFL model is amazing. And it works, if not flawlessly, then exceptionally well the vast majority of the time. And we don't have to speculate about this. We have literally three, four decades worth of prior art telling us exactly how well it works. And I think that's actually the most mind-boggling thing to me about all of this. It's like, why? Why does it work? Why have we not had more spectacular failures? And it makes me appreciate that that was the way open source went, that this model that allowed open source to be competitive with closed source software to a large degree was downstream from exceptionally driven individuals.

Now, I think a lot of great open source is great now because it's more than an individual. Rails has near 7,000 contributors to the main code base over the two decades. I mean, that's a remarkable achievement. Although we also did just pull out an example that literally only has three contributors over 20 years to collide. Right, right. So maybe that's not the be all end all of it, but the initial inception of almost every great piece of software

sprung from one person's mind. And I think that's just something I'm very willing to accept. I'm willing to accept that there's no governance model that's 100% effective. Sure. But also, I mean, if you pullhistoric times, there would be a vacuum. And then there would be an absolutely terrifying bloodshed of people gunning for this. So we come up sort of as civilization with this idea.

Do you know what? What if we just make it so there's a lineage and we can name the next 16 successors? So even if like the first five on the list are assassinated, number six, name is on the list, just go to that person. And do you know what? Sometimes we're going to get a mad king. Yep, them's the rules. Either we can have anarchy all the fucking time or we can occasionally have a mad king.

Let's go with the model that just only gives us a mad king like every four times. How do you feel about the unified individual vision to start and then when you reach maturity scale success transition away from that i'm thinking of guido van rossum i think of python and they seem like they've transitioned pretty well i think there's probably been some bumps along the along the path into a steering council now that they have him retiring. I mean, you're not going to live forever, David.

So there has to be some sort of a next benevolent dictator or something else entirely once you're done. You need some lineage. We need some lineage. Let's bring back firstborn rights here. It's a good question. And the reason I say that is when I look at Python and its vision, I mean, tons of respect for Python. And I know I have friends who like Python's their favorite language. And I think it's really cool. And there's a lot of overlap in terms governance model. I wish we had that in Ruby.

If only Matt wasn't sitting there giving thumbs up or thumbs down to every use of facing API change, I'd be so much happier. No, I don't. Well, maybe not better, but a necessity for continued sustainability, because like, I mean, unless you, unless you do find a taker over who's another individual that shares the vision i mean but even tim cook doesn't share steve jobs vision exactly as we've seen even though he was groomed for that right so things didn't last forever i think we're also going to

accept that and i think part of it is that you're not gonna there is no continuity with a committee that somehow fulfills what that original person brought to the table. And this is why I'm in no hurry to see that come to fruition. And in fact, we should rue the day when that's required. But part of this is that software development is such a new field. We're literally in the first generation of it. Like so much of all the programming languages we use, like they're all alive and not only alive, they have like another 40 years left on their clock

by just the averages, right? Like maths is not like 92 years old and we're like looking at sort of doing the handover in hospice. Now, again, the bus factor comes for all of us, either at the long end or the short end. But I don't know if we have the solutions. I don't look at any of the alternate models.

I think the Apache Foundation is a great example of an alternate model. They have a very distributed and regimented setup of how they adopt projects and so on. I also look a little bit, and I don't know, maybe this is offensive, but like Apaches is a graveyard to some extent, to a monument. I'm not saying that the projects don't know, maybe this is offensive, but like Apache is where it's a graveyard to some extent, to a monument. Like, I'm not saying that the projects don't evolve further. I'm saying like, maybe graveyard, that's the wrong term. Maybe retirement home is a better term. This is where you put projects when like, oh yeah, Cassandra, like today we're going to do exercise.

Let's do a new release, Cassandra. You can do it. I like this. There's a little bit of that, I think, that projects... I'm not saying it's impossible that you could hand things over. I'm saying it's difficult. The examples I've seen feel more like the retirement home version

than they feel like whatever idealized picture of democracy you might have in your head. What's up, friends? I'm here with a friend of mine, a good friend of mine, Michael Greenwich, CEO and founder of WorkOS. WorkOS is the all-in-one enterprise SSO and a whole lot more solution for everyone from a brand new startup to a enterprise and all the AI apps in between. So, Michael, when is too early or too late to begin to think about being enterprise ready? It's not just a single point in time where people make this transition. It occurs at many steps of the business. Enterprise single sign on, like SAML, auth, you usually don't need that until you have users. You're not going to need that when you're

getting started. And we call it an enterprise feature. But I think what you'll find is there's companies when you sell to like a 50 person company, they might want this. They actually, especially if they care about security, they might want that capability in it. So it's more of like SMB features even if they're tech forward. At WorkerWest, we provide a ton of other stuff that we give away for free for people earlier in their life cycle. We just don't charge you for it. So that auth kit stuff I mentioned, that identity service, we give that away for free up to a million users, 1 million users. And this competes with Auth0 and other platforms that have much, much lower free plans. I'm talking like 10,000, 50,000,

like we give you a million free because we really want to give developers the best tools and capabilities to build their products faster, you know, and to go to market much, much faster. And where we charge people money for the service is on these enterprise things. If you end up being successful and grow and scale up market, that's where we monetize. And that's also when you're making money as a business. So we really like to align our incentives across that. So we have people using AuthKit that are brand new apps just getting started. Companies in Y Combinator, side projects, hackathon things,

things that are not necessarily commercial focus, but could be someday. They're kind of future-proofing their tech stack by using WorkOS. On the other side, we have companies much, much later that are really big, who typically don't like us talking about them, their logos, you know, because they're big, big customers. But they say, hey, we tried to build this stuff, or we have some existing technology, but sort of unhappy with it. The developer that built it maybe has left. I was talking last week with a company that does over a billion in revenue each year and their skim connection, the user provisioning was written last summer by an intern who's no longer obviously at the company and the thing doesn't really work. And so they're looking

for a solution for that. So there's a really wide spectrum. We'll serve companies that are in a, you know, their offices in a coffee shop or their living room all the way through. They have a, you know, their own building in downtown San Francisco or New York or something. And it's the same platform, same technology, same tools on both sides. The volume is obviously different. And sometimes the way we support them from a kind of customer support perspective is a little bit different. Their needs are different, but same technology, same platform, just like AWS, right? You can use AWS and pay them $10 a month. You can also pay them $10 million a month, same product. Or more, for sure. Or more. Well, no matter where you're at on your enterprise ready journey, WorkOS has a solution for you.

They're trusted by Perplexity, Copy.ai, Loom, Vercel, Indeed, and so many more. You can learn more and check them out at WorkOS.com. That's W-O-R-K-O-S.com. Again, WorkOS.com. And I'm also here with Dennis Pilarinos, founder and CEO of Unblocked. Check them out at GetUnblocked.com. It's for all the hows, whys, and WTFs. Unblocked helps developers to find the answers they need to get their jobs done. So Dennis, you know we speak to developers.

Who is Unblocked best for? Who needs to use it? I think if you are a team that works with a lot of coworkers, if you have like 40, 50, 60, 100, 200, 500 coworkers, engineers, and you're working on a code base that's old and large, I think Unblocked is going to be a tool that you're going to love. Typically, the way that works is you can try it with one of your side projects, but the best outcomes are when you get comfortable

with the security requirements that we have. You connect your source code, you connect a form of documentation, be that Slack or Notion or Confluence. And when you get those two systems together, it will blow your mind. Actually, every single person that I've seen on board with the product does the same thing. They always ask a question that they're an expert in. They want to get a sense for how good is this thing? So I'm going to ask a question that I know the answer to, and people are generally blown away by the caliber of the response. And that starts to build a relationship of trust where they're like, no, this thing actually can give me the answer that I'm

looking for. And instead of interrupting a coworker or spending 30 minutes in a meeting, I can just ask a question, get the response in a few seconds and reclaim that time. The next step to get unblocked for you and your team is to go to getunblocked.com. Yourself, your team can now find the answer they need to get their jobs done and not have to bother anyone else on the team, take a meeting or waste any time whatsoever. Again, getunblocked.com. That's G-E-T-U-N-B-L-O-C-K-E-D.com.

And get unblocked. can i bring up a somewhat touchy side of this yes or no i'm not gonna stop we're already there calling apache foundation of retirement home but like let's go let's go okay well this laser's back to you and jason i think at the time i, and I'm still trying to get back to this because I knew your company as 37 Signals from back in the day. I bought and read the book Getting Started or Getting Real. Sorry. Yes. Because that's how I got started. But then I think you went away from the idea of 37 Signals and you became just Basecamp and now you're back to 37 Signals again.

But either way, that's past history. I'm still confused by that back in 2021 when it comes to the bdfl concerns rails came kind of close to some degree of an issue and it wasn't direct it was indirect y'all had an issue internally there was a lot of crazy things that happened y'all being 37 signals not rails. This was, so that's why I brought that up. This was at the company Basecamp because I don't think you brought back 37 Signals until after this. Correct. If I can, Robert, I don't know your history of company closely, but I think so.

That's right. But this, this was a big issue. Like there was a cancel scenario. So this is Rails adjacent. Yes. You know, left of center, but it was, it impacted rails in the fact that there was a canceled culture attitude towards you towards jason towards anyone who stayed basically at base camp and somehow that storm was weathered to have rail seven and to have this conversation

have rails eight and like you're not gone so the bdfl model almost almost uh tainted the rails world do you know what whether it had been that model or another model i think it would have been tainted nonetheless if you look at some of the drama that's been happening in the rust world that is less focused on the bdfl model more focused on committee style whatever there's just as much infighting the cancel culture came for that shit too there was no place that was safe to run. There was no place you could hide from that mob mentality. So I think that is sort of an adjacent issue to do we run things on a committee basis or a BDFL basis.

But I do think it was an instructive time because you do realize, you know what, it is possible to destroy things and to destroy them in the service of what? Of a bunch of fucking nonsense that a few years later we look back in horror upon like what the F was going on in 2020, 2021. That was just a batty nonsense time. And a bunch of things did get destroyed. Maybe not as many open source things as one might have expected. But yeah, we definitely brushed things with death to some extent on some of these projects. And I think to me, first of all, it's very satisfying to have outlived an attempt on your involvement in that regard.

This is something that gives me renewed energy on a continuous basis. Oh, remember that one time they showed up at the house with pitchforks and torches and you somehow made it through and now we're doing better than ever? Oh, man, I like that. Yeah. So wherever you can draw a source of energy from. But nonetheless, I think you're still correct in the fact that, yeah, it's possible to tear things down. than ever oh man i i like that yeah so wherever you can draw a source of energy from but nonetheless i think you're still correct in the fact that yeah it's possible to tear things down it is possible to destroy things and i think you point to that example 2021 is one example of it i actually

think a better modern example that's not the wordpress example since we haven't actually seen fully how that plays out is redis so redis ran on a a PDFL model with Antares for 15 years, something like that. Long time. And he ended up selling it essentially to a committee run, I mean, it's a company, but they run the development

as a committee basis. How's that going? Fucking like shit. That's how it's going. Like Redis is turning, Redis yanked. Redis is no longer, Redis is now,

is it source available? Is that the bullshit they call it? Yeah. Or something like that. is is no longer red is is now is its source available is that the bullshit they call it yeah or something like that it's no longer open source yeah rug pull like here's an example of you went from bdfl to committee style but on a very different premise and i have no interest in redis at this point forth i think it's an amazing piece of software i loved it for many years if i'm starting a new project tomorrow, I'm starting it with Valke or any one of the other forks. I'm not going down that dark path. So things don't last forever. And I think we can delude ourselves into thinking that because we have such a young industry, right?

Do you think architects think like, oh, this building is going to last forever? No, because they've seen like literally the history of civilization. Build things, destroy things. Build things, destroy things. Build things, destroy things. Or things just falling apart. We've been around in our modern incarnation for what, 50 years? 60 at the most? Like everything is still here.

Cobalt is still here. Fortran is still here. You can actually still compile and run those programs. We've not yet seen proper destruction. We've seen some degree of abandonment, maybe, but we don't have the timeline to really appreciate these things on. And therefore, we are liable to the delusion

that things are going to last forever. They're not. I didn't bring that up necessarily to call back to the moment, but more like Rails, because we haven't talked about, Rails had had an opportunity for some major change at the BDFL

level. And I don't, I'm with you. I think there's a lot of pros comparative to the committee level. You don't even have to run an open source project to think that committees are bad. Try to make a decision with committees and you know that it could be at church, it could be in your family, it could be wherever

you bring in a committee. Now you need a leader. You need somebody who can define the vision and collect people who believe in that vision and share that vision and have shared beliefs. And the beliefs is not simply bestowed upon by the BDFL, but they are originated by someone who has command, someone who has vision and others come on that journey. And that's okayDFL, but they are originated by someone who has command, someone who has vision and others come on that journey. And that's okay with me, but I would, I think we're on this show and we're like, Jared and I both come from the roots of Ruby and Rails. And so to us in our developer core, like our developer Greenheart, you know, it's Ruby and Rails. That's, to me, and I probably think you're the same, Jared.

When we talk about this, it's nice to know it's still there. It's nice to know that you've got Rails World. It's nice to see your latest keynote. It's nice to see this renaissance, this, what did you call it, Jared? I just said it's having a moment. That's all I said. I said Rails

renaissance, and you said something else in pre-show. Oh, I don't know. I don't know. It was cool. It was cool. I say lots of cool stuff. But that Rails is still here, still sturdy, and these old, new, reformed ideas that have been lines in the sand, convention over

configuration, like these things you've talked about on the show, are true. And they weren't tainted or destroyed by this adjacent possibility yes and i think this is this is when i look back upon things like that i look back upon them with first of all tinted nostalgia of how you sort of compress the past but i also look back on with joy and say like you know what whatever we survive i mean it's a fucking cliche but does make us stronger rails is stronger because that happened not just in spite of it but because of it we end up with a better structure i ended up with more dedication after sort of just getting my bearings again on like do you know what am i still interested in this

so you're tested right you're tested first of all what are you made of are you gonna fold just getting my bearings again on like, do you know what? Am I still interested in this? So you're tested, right? You're tested. First of all, what are you made of? Are you going to fold? You're going to just run away from the thing? Or are you going to rise up and face it head on? That's one thing. And then are you going to keep going? Like, do you want this? And that is a good question. I mean, I've been doing Rails now for literally over 20 years. It is not unreasonable to raise the question, like, do I even really want this anymore? Is it worth the fucking hassle? Like, I could just have said, like, all right, fine. Here, form a fucking committee. I'll give you the commit rights. Go see if you can do a better job. Go see what happens a few years

in, if that's how you're going to run it. I mean, I'm not going to say it wasn't tempting for a hot minute, but then I also went like, no, no, no, no, no. I like Ruby. I like Rails. Do you know what? I'm going to fight for these things. And I'm going to continue to invest my energy and enthusiasm into a direction of this.

And when we had the nonsense with the RailsConf stuff, like, all right, whatever, that's what you want to do. Great. I'll take my energy over here. We're going to put, come up with a, with a conference. I'm going to help organize Rails world. I'm going to put my energy behind that. And let's just like, see how it goes. I think it went pretty well. I think the- Here's the problem with that idea though. David, you are capturing less than you created. I'm sorry, man. You've done it wrong. That is the problem. You're capturing less than you created i'm sorry man you've done it wrong that is the problem you're capturing less than going back to the mad king now yeah what a call out right that was a post that went away but like that was a good a bad good call out i think you know i think

matt's not in the best place mentally i think he was backed into a corner there and lashing out at the wrong person and i could also see why yeah i mean not just that argument though it comes back to the open source idea which i think you outline well in your post capturing less than you create which is why i said that to bring it back to yes to this direction is that we don't have to capture it all like we don't even with this network in this podcast media company that jared and i created like we don't. Even with this network and this podcast media company that Jared and I created, like, we don't capture every possible dollar that can come in the door. We say no to a lot of people because why we're not, it's a not good term. Do you mind if I say one not good term, Jared? Is that okay? We're not ad whores. Like that's a terrible term. And I hate seeing it. I only say

it to people now on podcasts one time and transcripts forever that are get committed and it's in black and white forever but we don't just say yes to everybody it's going to come up in your cancellation hearing in about three years when the pendulum comes back around that just so you know adam it is now in the official record it is well we can still edit this out that's true we can consider in post that's right we'll have a committee decide we should edit that out so we don't say yes to everything that comes our way just like in the scenario of our creations, we don't have to capture it all

to bear all the fruits of our things we've made. I think that's just a sad way to think about it. And I agree, Jared, I think that Matt is not in the best state. He seems like he's literally hell bound to be his state of mind, keeps coming out. Now there's this new thing i think this injunction that wp engine is putting against me he's going to be more quiet he says in his latest post but this idea that it's really about open source and we've got this blended line

of what open source really means should osi be the arbiter of these licenses? Where is the line? What really is open source? We've got different licenses that have come out that try to be open source, source available. There's been all these different terms. I think the thing that's under scrutiny here is this blurred line of open source that you have to come back to just make the thing

and let whoever can capture the value, capture the value. That's the point of open source that you have to come back to just make the thing and let whoever can capture the value, capture the value. That's the point of open source, the freedoms to use it, the freedoms to show up, the freedoms to not show up, the freedoms to say F it and give it to the committee. You know, that's the beauty of open source. And that's, that's what I love most. But let's talk about capturing less than you create. What do you, share, share what you feel there. Yeah, so I think I have been hashtag blessed that other ventures in my life panned out well enough that I did not need to look envious upon folks using my creation to create value. I hope that even if things hadn't panned out well for me in my own endeavors, I would still be able to hold to that ideal. But I can also see the human, very human attraction to the idea that, do you know what? I'm owed something. Someone built something on top of my creation. I should get a taste. I should get a cut of that. And I do think it takes some degree of dedication to not

fall into that trap because I do think it is fundamentally incompatible with what open source is. I have decided that my involvement in open source is not going to be governed on market terms because in a market situation, in a commercial situation, I would totally act like that. If we're having a contract here back and situation, I would totally act like that. If we're having a contract here back and forth, I want that contract to be fair. I want my inputs to be reciprocated by your inputs. That's a different model. It's a different economic universe.

And then I look at this universe over here called open source and I go like, do you know what? I do the commerce thing. I do enough of that at my day job. In the open source world, I don't want that. I want this to be a gift exchange. I want to make gifts for myself first and foremost. And then I want to show up to the gifts exchange and go like, does anyone want this? Here, you can have it. And by the time I've given you that gift, it is yours. I don't get to tell you how to use it. I can offer my opinion, but it is just that.

An opinion is not a contractual bound. The only contract here we have for all my open source is the MIT license. And that basically just says, don't sue me, bro. Like you can do whatever you want. There's no warranty here. But other than that, you can go build a hundred billion dollar business. And I would stand on the sidelines and I'll go, yeah, that's awesome. Good for you. I'm not going to show up at the back door. Hey, by the way, you owe me 8%. Like that's just not

the model that I'm interested in pursuing open source with. And I also don't think that that's true for most people. I think, well, most open source developers, I should say. I think most open source developers, first of all, they are human. And some of them are what I termed starving open source artists. And they are tempted to think like, oh, my life would be so much easier if just this company that uses my software, if I could just get 0.01% of their revenues, I could pay for X, Y, and Z. That is a human attraction. But most of them

it's it stays there right they don't persecute that they don't suddenly go like actually i should go ask them for them actually they owe me that actually unless they do i will kick them off the plug-in repository right like that's not the order that most open source developers are followed banned yeah i think the freedom in open source too is like the freedom to not force someone to do something else that's exactly right it's not just the gift exchange you mentioned and the freedom to create for you first and then to give away at the gift exchange is to say you don't have to come to the gift exchange and give me money to get this thing or somehow force somebody else an entity an individual or otherwise that is the beauty and

freedom of open source is that you are not forced and you shouldn't and can't force others. And if you believed in the truth of open source, you wouldn't try and do that. That's right. I think that that is, this is a voluntary exchange of gifts in both directions. I've mostly been persecuting this from the other side, right? I'm going to give you a bunch of gifts. You don't get to tell me what color the wrapping paper should be. You don't get to tell me how the shape of those gifts should be. I determined that because I made the fucking gift. I'm showing up here and I'm giving it to anyone who wants it. I'm not saying I won't listen to your feedback.

I'm just saying you don't get to tell me what to do. That freedom, paramount. Just as important is the other freedom that if you're going get to tell me what to do. That freedom, paramount. Just as important is the other freedom that if you're going like, well, here's one of my gifts, that it's a gift, right? You can't give it to me. And then suddenly I'll say, well, now I've given you the gift. You owe me A, B, C, D, E, F, G. If that was the case, then I mean, we made a transaction. Gift is not a transaction or I mean, that's not the kind of gift giving I'm involved with. That's some nefarious shit right there. So if it's not a transaction, you don't get to declare

your sort of secret side of the ledger here. And I think that's what irks me and brought me to get involved with this whole WordPress drama in the first place is I thought that a shadow set of obligations were pulled out of the drawer when someone happened to be successful and then suddenly applied under all these spurious pretexts. They're not giving back enough. Okay. Do you know what? I mean, billions and billions of dollars have been created on the back of Rails' creation, and a ton of those companies have given back exactly zero. They have zero commits.

They have zero donations. They have zero sponsorships. They have zero everything. Sometimes I look at that and go like, hey, it'd be nice. It'd be nice if they would contribute a little more. But like, so what? Okay. There's a bunch of others who do. I'll just focus my energy and time on them. I'll focus my energy and time on the Shopify's and the GitHub's and the rest of the Rails Foundation and the people who do want to be involved. There's enough of them. I don't have to find every unsqueezed lemon and then just go like, here's a baseball bat. Splat!

I just want to vision that. I fully agree with that. That's the, when we zoom out. I concern myself with or leave some hesitation for is that there there's a hundred percent a lot of context that's behind the scenes that we're not aware of like there may have been conversations etc but then I'm like that doesn't excuse what's the name of the show Jared it's the wrong place to slap a person I we we conversated about this because we're podcasters on a different podcast and i use the analogy of will smith and chris rock like you don't go on stage and slap somebody and at that point it was a slap like it was uh this was like day one right it was week one uh it was word camp it was the announcement of wp engine being I'm like, that seems like it's cool.

You're right to do whatever you want with her keynote, but that's a weird place to slap somebody. Like that's the wrong place to slap somebody. But then I'm like, this is just generally wrong. Like the way it's been handled, the way it's been the initial release of the concern, all these things, it's just weirdly wrong. And then the people that pay the price is the potential fracturing,

I suppose, if not complete trust fracturing of WordPress as it is. And it's just the wrong way to handle all this, regardless of the context that may be missing. It just seems wrong. I mean, I don't disagree with that, but then I also constantly try to check myself that when we had our little

kerfuffle in 2021, there were a bunch of people who just thought they're just wrong right yeah so i try to keep just an an ounce of humility in that but even so i've also looked through all of it i've looked through the complaint i don't have a dog in this fight i don't use wordpress for anything we did once upon a time we don't anymore i like the idea that it's it's an open source package that's running what 40 of the internet or something like that that's incredible if anything i'm biased to cheer for whoever brought that to life so i'm biased here for that and i still look and go like you know what no there's just some norms here i don't even have to render a verdict on the total sum of everything to go like okay that part taking over someone's plugin in the way it was taken over and

impostering like that just violates every norm yeah i'm interested in having an open source regardless of whether you're right or you're wrong on some other trademark questions or other things that are in there. Now, again, said all that, I also do know that there are other people who would have the same conversation about the actions that Jason and I took in 2021. So I kind of like, I try to do it with that distance, still having opinions about things. And I also do think some of it is not necessarily that deep, right? I think it's kind of you actually to say, there's a lot of context here that we don't know. Yeah, but also sometimes

the answer is simpler. Here's a competitor to WordPress.com that's doing really well, reportedly hundreds of millions of dollars a year in revenue hosting this open source thing. I can see the human response going like, that's fucking bullshit. They make all

this fucking money and i don't get anything back to my projects they don't give anything back now i'm gonna get him like i can recognize that that's not an alien instinct it's not something that is so far removed from i would i've said words like that i'm sure my brain or felt that way about things in my life so i totally get it exactly so that's why I'm like, I can actually understand where these instincts come from. I don't think they're good. I think we should, we have our instincts and we have our emotions and then we should try to check them with some intellect and some virtue and some respect for norms and so forth. But I can understand where it comes from. So part of this

to me as I've been trying to walk the fine line of saying, do you know what? I don't think this is good. And the reason I'm even getting involved is that it's not just not good for WordPress. It is not good for the entire open source world. If we're suddenly opening up this idea that at any one time, someone can just show up and want 8% of your business if you happen to build on some open source software,

that's going to really put a damper on corporate acceptance of open source. And corporate acceptance of open source is good. We want corporations to use open source. This is not some sort of net zero pie here. When you have corporations adopting open source, they're way more likely to dedicate their employee time to improving that open source. That's certainly what's happened in the Rails world.

The vast majority at this stage of contributions to the framework, certainly at the higher levels of contribution, they come from individuals who are allowed to work on that open source during work hours, paid for by a corporation, because that corporation sees a self-interest in improving the shared commons. That's good. We want more of that. That's how we get better open source. That's how we get better gifts, that we get a bunch of corporation thinking in their self-interest. This is where I like Adam Smith's immortal words here about it is not by the virtue of the baker or the butcher that capitalism has all sorts of asterisks to it, perhaps. I don't actually subscribe to so many of those. But the reason it works is that we're all working for our own self-interest. Don't feign it. Don't believe that the world is just full of all these completely altruistic super beings and super organizations that never think about themselves and their own benefits.

We all do. The game is to set up rules in such a way that that self-interest promotes a common good. And I think that's what we've done almost to perfection in the open source world. I mean, certainly to an incredible rate of success. If you had asked anyone in technology, in software in like 1989, hey, do you think in like 20 years, 30 years, like all the important software that runs the internet, if they could imagine the internet, was going to be open source? What do you mean open source? Like people just giving software? What? No. No way. License fees. We'd have Per CPU, this, that, and the other thing, right? The fact that it works is a testament to incentives, and the incentives of open source are good. The incentives, when the rules are known, there's stability about what the licensees mean.

Corporations are not fearing that they're going to get sued if they contribute a little or a lot or not at all. That's all good. It is all part of that finely tuned machinery that's producing more software every year than the world has ever seen. So this is where I also just get into this. There's this critique of open source. It's unsustainable. Like any minute now, any minute, it's going to collapse. I was like, do you know there's more software produced like this year than there ever have been in the history of mankind?

And a lot of it is open source. Now, no, you're just, you're doing the chicken little thing. You have your own personal interests and agenda you want to push forward that might be like, oh, corporations should pay open source developers more. Okay, fine. I guess that could be a, you could take that position, but to take that position from like a chicken little perspective of the whole world is falling it's just a historical nonsense open source is in its best shape it's ever been in terms of number of contributions strength of software reliability of that software all the things are freaking great it's like everything's amazing and everyone is unhappy i think I'm sympathetic to that argument on the margins with individuals.

I think that there are definitely open source maintainers who are feeling the stress and strain of the pressure and the guilt when somebody is using their software and they can't keep up with the issues and the feature requests and all these things. And they're working nights and weekends for free for no reason other than like,

it's just pressed upon them. They feel they're givers. So they're given a gift and they want to make that gift as best as they can. And that whole thing, we've seen it unravel for folks over time. I agree with you. The machine itself is not that. It's not going to just stop operating, and it is producing so much awesome stuff. But there are the individuals who are suffering because of, in many cases, a... Because of their own choices.

This is why when we use words like suffering, which I don't disagree with necessarily. Yes. That could describe that individual's feeling. You're here because you chose to be here, dude. Right. And it's true. It's also easy to say when you have a healthy relationship with the situation like there's unhealthy relationships that that that develop around these things where it becomes very difficult for them to see that straight you know

but it's also like that's your life life task like uh alfred sure and the courage to be disliked there's just you know what i i can't solve that for you you'd probably be any which way are people asking you to solve it for us right like i Like, I think actually what a lot of these, I mean, it sounds glip and it's 50% glip and 50% real talk. Like, what do you need is a therapist. Like, you need to figure out your shit, man. You need to figure out, like,

what you're investing in, whether it's giving things back to you and you need to stop doing the things that aren't returning to you. Sitting around moaning and whining about it, you know what, not going to lead to the outcome you want. I mean, as evidenced by the fact that people have been piss sitting around moaning and whining about it, you know what, not going to lead to the outcome you want. I mean, as evidenced by the fact that people have been pissing and moaning

about being unrecognized and unrewarded from open source work for literally decades. It has not changed the incentives because it is not an incentive. So again, I can have human sympathy. That's the whole starving open source artist thing. I can look at some humans and go like, you know what? You're a really good developer. You make stuff that's valuable.

That's really cool, dude. But also, it doesn't mean that that suddenly produces these extra license obligations of others. If you choose to be sort of at the mercy of donations, that's your choice. There are many other different ways of doing open source. You've chosen this one. Them's the rules, dude. Right. So here's one where we're not talking about

the marginal open source developer who's the starving artist. We're talking about somebody who's more like yourself, very successful. Coming in your wake, in fact, I'm surprised you didn't capture any of the Laravel value being, you know, you are an inspiration. Rails is an inspiration for Taylor Otwell's Laravel. And Fortune recently had this headline, exclusive Laravel, an open source startup in Arkansas founded by Taylor Otwell, raises $57 million from Excel. That's a

lot of money. He has gone on the record to say he doesn't really need money at this point. He's posting pictures of his Lambo on the internets and stuff. So just curious your take on Laravel raising a whole bunch of money. I don't know if you know Taylor or not. Is this a good idea? Is this a bad idea? Your thoughts. First of all, I think Laravel is awesome. And I think it's amazing to see a bunch of Rails ideas expressed in the context of PHP. I did PHP for a number of years. PHP was what led up to me doing Ruby. So I do think there's some beautiful symbiosis there of sending ideas back and forth. I really like to see that. I also like to see different ways of doing things. I like to see people try crazy shit I would never attempt

and I will just lean back and go like, that's going to be a good show. I am going to tune in to see how that one turns out. And I wouldn't want it any other way. I think that life would be so boring if we all did everything the same way according to all the same values and trade-offs and whatnot. So that's a long preamble for saying, yeah, I wouldn't have chosen that. I know

the pressures that come with venture capital. I know what the math looks like. And the math looks like he's got a 10, 20, X that. Easy. That's a lot of money. Like he's got to turn this into a billion dollar business. That's a lot of stress. I hope he's ready for all that. He may very well be. There are others who have done it and succeeded, but there are more who have broken their neck and failed.

And I think this is something we at least just need to be realistic about. We can look at that and go like, do you know what? Good for you, Taylor. I hope he took a bunch of that money straight off the table and into his own pocket and he buys another two Lamborghinis. You built something cool. I like Lamborghinis. You should try a yellow one and a green one. I can highly recommend. It's great. And then also be realistic about the fact, you know what? Odds tell us this is not going to work because odds are that the majority, not just the majority, but the vast majority of all venture capital investments do not work. They turn businesses into dust because that is just what happens. Like one out of 10 is going to be the slam dunk.

It's going to be the unicorn. Then a couple of the others are going to be sort of these base hits that are usually merged or sold off or something else. And then the majority of them are just going to fail. And before they fail, they're going to be pushed to the brink of trying to make them work. And when that happens with developer tooling, we talked about antires and and redis that's one outcome of things that can happen when some of these things get involved in that way it's not the only negative outcome i can think of in that realm i really hope that laravel beats the odds i not only do i hope i'm fucking cheering i want taylor to succeed with this i want laravel to do well. And if he can make it work with some PaaS system that he sells to a bunch of PHP developers to do it, wonderful.

I'll cheer. I'll go on the Lambert tour with you, Taylor. It's going to be great. But let's just be realistic about the odds, right? And I think this is where I've chosen, and Jason and I, for our business, have chosen different paths that had different odds. It's always hard to make a business work, no matter how well you do it. But there are ways to make it harder than other ways. And I think you're playing on like hardcore when you raise $57 million.

Most of it does not pan out. So just sort of accept that. And then, okay, also fine. So it doesn't work out, right? Let's just imagine it blows up in the most explosive, exploitive ways. Now there's a shitty cloud that doesn't function or trying to explore. Like, okay, PHP is still there. Laravel is still there.

It's still open source. Someone else can fork it, take it somewhere else. Let's hope none of those things happen. And that the best possible outcome is achieved and Taylor beats the odds and all is good. Good take. Last question for me is when is Rails 8 going to

drop, man? I'm looking at my calendar here. Very soon. The first release candidate is out. We pushed that out on Friday, I believe. I think if it's not going to be this week, then hopefully it's going to be next week.

Unless we find something terminal. Well, we're never going to find it in the terminal. Unless we find something serious that requires a long time to fix, and I can't see it because all the major, well, not all, many of the major Rails apps, they've been running Rails 8 in production for a long time shopify runs rails 8 in production github runs rails 8 in production we run it for basecamp and hey this is the dividend of modern rails development is that the new versions they're

generally exceptionally solid because they're being run early at such an incredible scale that if there is a problem shop Shopify is going to find it. GitHub is going to find it. We're going to find it. Either in ergonomics because there's a lot of developers who have eyes on it or in terms of performance regressions or outright bugs or something else like that. So, I mean, we're just being extra safe here, extra careful,

which I think is good. Like the quality has risen immensely. Like those early versions, like version one, extra careful, which I think is good. Like the quality has risen immensely. Like those early versions, like version one, version two. I mean, maybe you wanted to wait for the dot one version for that to be a little safe. That's not the case with modern Rails and it hasn't been for a long time. Coming soon to a terminal near you.

Adam, anything left? No, it's been fun. I'm glad we got to dig into some, I'm glad to hear your thoughts on the way software works, some of the ideas that you're putting out there as the benevolent dictator for life of Rails.

So we listened a lot and I would say the first half of the show when we spoke more in the second half of the show, we got to conversate a bit more, which I always appreciate because you have a lot of good things to say and people want to just sit back and listen, but it's also nice to have a conversation, you know, to push back a little bit and to rest.

I like that. I'm happy we did that. Kudos to you guys. Sometimes it hits play and it doesn't stop until like 27 minutes later. A occupational hazard of thinking about these things for decades and talking about them and refining the arguments

for at least as long and we want to hear those things we also want to have some conversation just i appreciate that that's part of this one at least you know it's cool it's cool yeah well i appreciate you coming on yeah thanks for having me on again really enjoy it as always thank you well rails is having a moment once again. Some would say it is a Rails world, but who are those people? Is it me? Is it you? I don't know. Are you part of the developer community who has a renewed excitement for Rails? Those who were steeped in the JavaScript soup for just a little too long

and you're looking for some developer joy? Well, Rails might be something that's just up your alley. Ruby is an amazing language. Rails is a fantastic framework. Some would say 20 years in the making and it's prime time. Love him or not, like him or not, David Hanamer Hansen, DHH has some pretty awesome ideas about where the web is going, where the web has been, and what makes sense to use, and what's pragmatic and what's not. But you decide. Okay, so we have a bonus on this episode. And you're going to love it. What is the bonus?

Well, bonuses are for ChangeLaw++ subscribers only. You can do that at changelaw.com slash plus plus. Ten bucks a month, hundred bucks a year. Directly support us. Drop those ads. Get closer to that cool ChangeLog medal. Get some stickers sent to you in the mail. And, of course, bonus content like today.

Again, ChangeLog.com slash plus plus. It's better. It is better. Before we go, I want to give a massive thank you to our friends over at Fly.io, our friends at Speakeasy.com, workos.com, and our friends at unblocked, getunblocked.com. They support us, and you should check them out. And of course, the Beat Freak in Residence Break Master Cylinder. Those beats are banging, banging, banging, banging.

I love them. Hope you love them too. That's it. The show's done. We will see you on Friday. I'm just so excited about this idea that somebody was bold enough to leave the cloud. That's really it. And you probably can't condense that into four minutes. You can't do this in four minutes.

Come on. But, you know, I just want to share my excitement in this conversation because like, that's cool. You've kind of made home labbing at scale. Cool. Which to me is so funny because it's exactly the same discussion as we had with SQLite. We took something quote unquote old, which was to run your own server,

which by the way, was what everyone did five minutes ago until AWS sort of steamrolled the marketing hype to the max and convinced everyone. Uh-oh. Go to changelog.com slash plus plus. It's better.