In short
Podcast Summary: Rails is Having a Moment (Again)
Episode Details
- Podcast Title: The Changelog: Software Development, Open Source
- Episode Title: Rails is having a moment (again) (Interview)
- Host: Jared and Adam
- Guest: David Heinemeier Hansson (DHH), creator of Ruby on Rails and co-owner of 37signals
- Release Date: [Insert Date Here]
Overview In this episode, DHH joins the hosts to discuss the renewed excitement surrounding Ruby on Rails, the challenges faced by JavaScript developers, the future of Rails with Rails 8, and ongoing discussions about open source governance. The conversation touches on the balance between developer joy and user experience, the implications of the BDFL (Benevolent Dictator For Life) model, and notable developments in the Rails community.
Key Topics Discussed
- Renewed Excitement for Rails
- DHH feels that Rails is experiencing a resurgence, partly attributed to Rails 7 and upcoming Rails 8.
- A shift in sentiment among developers who have become disenchanted with JavaScript frameworks, leading them to re-evaluate alternatives like Rails.
- Acknowledgement of the generational shift where new developers realize the value of Rails over the complexities of modern JavaScript.
- Balancing Developer Joy and User Experience
- DHH emphasizes the importance of developer joy and the need for developers to enjoy their work, which can be hindered by complex JavaScript frameworks.
- The episode reflects on the challenges of maintaining a balance between user experience and the ease of development for programmers.
- BDFL Model and Open Source Governance
- Discussion on the pros and cons of the BDFL model. DHH argues that it allows for a clear vision and direction but also comes with risks if the BDFL engages in irresponsible behavior.
- DHH cites the recent WordPress drama as a case study on governance challenges within open source communities.
- He expresses a desire for the Rails community to maintain the integrity of its contributions without the pressures of corporate interests.
- The Future of Rails 8
- Rails 8 is highlighted as a significant step forward with improved features and continued focus on solving the full web application stack.
- DHH discusses the integration of SQLite into Rails for better deployment simplicity, allowing developers to run applications without needing additional services like Redis or Memcached.
- The emphasis on enabling developers to deploy applications with minimal overhead and encouraging a return to simpler development practices.
- JavaScript Soup and No-Build Philosophy
- DHH critiques the complexity of modern JavaScript ecosystems, referring to it as "JavaScript soup," which often leaves developers feeling overwhelmed.
- The #NoBuild philosophy in Rails provides a way for developers to write and ship JavaScript directly without complex build processes, enhancing productivity and enjoyment.
- Commercialization of Open Source
- DHH discusses the implications of commercialization within open source, especially in light of Laravel’s recent venture capital funding.
- He stresses the importance of maintaining healthy relationships with open source contributions while recognizing the commercial landscape.
Key Takeaways
- DHH is optimistic about the future of Rails, highlighting the framework's strengths and its potential to regain popularity among developers.
- The episode underscores the importance of community and governance while navigating the challenges of open source contributions.
- Rails 8 aims to simplify the development process and reduce dependency on complex tools, aligning with the #NoBuild movement.
- Developers should prioritize their joy in the work and seek tools that enhance productivity rather than complicate it.
Conclusion DHH's insights into the current state of Rails and open source development paint a picture of a vibrant community that is continuously evolving. The discussion encourages developers to embrace simplicity in their workflows and remain engaged in the open source ecosystem while being mindful of the complexities introduced by commercialization.
---
This markdown captures the essence of the podcast episode, summarizing the key discussions and ideas presented by DHH and the hosts.
Written by AI. May contain mistakes. Listen to the episode to check what was said.
Transcript
Automatic transcript. May contain errors.0:05What's up? Welcome back. This is the changelog. 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.
0:45So 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 changelaw.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.
1:20What'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-minded cloud because you can build better features for users, basically, if you don't 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?
1:55In 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 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.
2:29You 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 than Lambda that you could use to build Lambda on top of.
3:03And what machines are is just these VMs that are designed to start really fast or designed to stop and then restart really fast and are 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 is 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.
3:39Very cool. Okay, 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.
4:29Well, we are back with David Hennemeyer-Hansen. For the fourth time, DHH, you're always welcome on the Changelog. 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.
5:06And 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. Right. And that's sometimes when you just have to wait. I think if I look back on the last, let's say, 10 years of web development, 10 years ago, 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.
5:55And 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. 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 I've 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 static versus dynamic typing or anything else like that.
6:41Where you can just see that pendulum and it swings and 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, 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. So if you had to say, let's take a note from a town hall recently.
7:19If 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.
7:59I 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 back end in it but do you know what if i had to for whatever reason ruby didn't exist i probably could do it and not 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.
8:35It's like, how much do we even want object-oriented programming structures in our language? Now, it's there. It's in there with ESX. 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 I was thinking. But combining those two things together, the JavaScript I now write for the web applications we build at 37 SQLs, it's a pleasure.
9:17It'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.
10:01And 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 Hay. 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.
10:37And 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 where 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.
11:19It 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. Is that still true? I'm not sure. But when it first came out, they were like, we're not doing configuration file.
11:59And 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, 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.
12:38There's no transpiling. There's no compilation. There's no chunking. There's no tree shaking. There's none of these techniques that were for a hot moment taken 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 that whole orifice of complexity and 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.
13:14I 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 auto-completion. 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 auto-complete 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.
13:52Like 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.
14:27I 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. 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.
14:59They 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. HTTP 2, of course, that predates that.
15:42And 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. Like, don't, 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 directories 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.
16:24You 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 37 Signals. 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.
17:01It 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.
17:44You got to use all these techniques that 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. Like 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.
18:29There 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. And 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. OK, I don't know what happens there. Probably there are some tradeoffs. Are the tradeoffs as clear as they've been presented?
19:01I 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. And 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.
19:37They 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 and 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.
20:08Well, 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. That style sheets had that same phenomenon. We used SAS for many, many years. And SAS has a complicated build pipeline as well. And now we just use the CSS that the browser can ingest because the browser's caught up on CSS too.
20:42Now you have nesting. Now you have all of these parent selectors. You have all the things that people normally reach for when it's build 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.
21:17It's just not true. I think that's fair. If we go 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.
22:07Rails, ships, omakaza, 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.
22:44We 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. Like 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.
23:28And 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.
24:10And here we use this front end web farming. 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 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.
24:48And 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, OK, 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 commented on this stuff. There's like Fastify. Yeah, there's a couple of them. There's both the reality of things churning incredibly quickly. And then there's, I think, also just a culture that churn is actually amazing, that we should all be using frameworks that were invented six months ago.
25:22Otherwise, 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 ActiveRecord 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.
Read the full transcript
26:01So 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.
26:37Rails 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.
27:22They 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. and they can say, well, I just have a developer. And at some point when I build a bunch of stuff, maybe I have two, but they can do all of it. And that allegiance to the programmer, the web programmers, 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.
27:59And 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.
28:38One 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 there are 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.
29:19So 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, right? 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.
30:00That to me, by the way, is the best definition of web scale, that you are 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 is 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.
30:38But 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.
31:25But 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.
32:03They 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.
32:41I 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, you know, get the likes, the contracts, right? I mean, what's new is what sells. And so we're very much highly motivated to do that. And I also think some of it is generational and that is the fun part of it being around for so long. You see things in fashion, for example, whatever, mid 2000, like all the socks, they had to be angled socks, right?
33:18Because we went from a phase where people use tennis socks and they went up high. Do you know what the most uncool thing to wear now is? Angle socks. Do 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. They want to 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 liked object oriented programming. We've got to pick the other one.
33:46Same 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, ankle socks versus tennis socks. Jeans that kind of go out or go in skinny jeans. They're also, they're not hip. 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 that 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.
34:19Right. 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 you wear, David? you know what it's so funny because now i've used that example a couple 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 then no soccer cool stinky feet in there come on but the other thing is you can just wait long enough right and this actually goes that's right wait it out just wait it out give it another the five years, we're back to angle sucks.
35:11And 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 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. Yeah, clout 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 liking typing. I'm like, yeah, do you know what? I'm just going to sit here and wait it out.
35:43And like in three years, option oriented programming with dynamic typing is going to 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 for instance what elixir was doing where you could just run background jobs without having to have a redis or something like that.
36:31And 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.
37:15If I had tried to use SQLite in the way we're using it now in 2009, when the underlying technology was a spinning disk, like the Rust compilations. that were the thing before we had SSDs and NVMe 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.
37:55Great, 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 Gehz 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 an even large application on one box.
38:56That 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.
39:43You take the network layer out and you're writing straight to disk. 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.
40:27And 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 entrance 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 a fundamentally paradigm shifting advantage. For SQLite, it is.
41:01There's no server. It's so much simpler to run. It is so much cheaper to run. You can run it so much wider. Unless you're working on that file, there's no overhead. There's no process even. And that just probably in order of magnitude in terms of simplification of how you think about data, how you think about databases, right? And it's then no longer backed by those constraints. So we keep moving up the ladder. And we'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 web sockets coordination.
41:41And 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. No, 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.
42:20Rails 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.
42:58They'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.
43:32This 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.
44:05Okay, 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.
44:43Like 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.
45:22Well, 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 requests and response objects, an 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.
46:07Again, speakeasy.com slash Python.
46:23on when you say no pass required is that synonymous with no cloud i mean it's kind of how i read that the way is it not synonymous no no i mean yes and no so where's the 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 Ipik box with 48 cores and here's the address to the data set 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.
47:05I want to shrink that gap such that the bare metal deployment scenario looks virtually identical to the cloud deployment scenario. That there's not like it's not a different category. It's using the same tools. It's 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. And, oh, Hefstner 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.
47:48I 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 builds 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 I said, 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.
48:21That's why I was asking that, because like 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 so far 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, is that cloud? Because I feel like that's more like a rented single machine.
48:53I think that's very fussy. And I think there's one side of the aisle that wants to label everything that touches the internet a cloud, because then all we argue about is 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?
49:29Like where exactly is the line? Is it VPS or it's a droplet? Is it droplet cloud? It's VPS renamed as a cool name from DigitalOcean. It is a little bit, right? So I think it is 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 VPS or VM or a dedicated box and move ever 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.
50:10It 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, 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 hawk was 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.
50:54That'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. Like 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.
51:27We 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 Heroku, whatever, or something else like that.
52:08And you could just move on. You don't get locked in. You don't get locked into a cost basis. That's prohibitive. Yeah, so if you graduate, let's give you a place to go. 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 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.
53:02And that is the key trap the cloud has for keeping you put. 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, 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.
53:38We'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 100 ,000 requests a second, and then you go down to like five.
54:17All 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. 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 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.
54:50I think those two things are not alike. I want to go back to SQLite because I'm just obsessed with this idea. How much have you put it through its paces? I'm thinking of it, and it makes sense, Redis replacement, cache store, 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.
55:36We 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.
56:15But 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. Like, 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.
56:48And 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.
57:24They just get primary keys assigned off the basis of an integer's intercommenting. So the data doesn't kind of go back in quite as neatly as necessary 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, like 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.
58:05I 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? You've 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.
58:40So 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.
59:13Shard sucks, man. I mean, rebalancing shards, setting them up, all the – 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. 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.
59:53But 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.
1:00:31There'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. Right. That's the problem with something like MySQL, for example. So MySQL for us, like we use the InnoDB table format, the InnoDB cache is a global cache. Like 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.
1:01:04Because if they do show up and I don't 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 it takes down the whole database because all the resources just go into servicing that query. And everyone else is on that same database.
1:01:41So, yeah, good luck. Everyone else is screwed because Paul had an unreasonably large instance in some case that we didn't expect, 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 LightFS? So when you get to SQLite at scale, I call it SQLite. I'm sorry. College, are you up, man? Well, we talked to Richard Hipp at one point. It's better than what the Prime calls it.
1:02:21He calls it squeal light. I'm like, I can't listen to that squeal. What do you mean? I just realized 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 Hipp 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 SQLite. I can't help myself. I committed to memory and I can't stop. So that's how it works. What is he, what's the official way? Like meteorite. He actually named it after meteorite. So it's like, say it Adam. SQLite. SQLite.
1:02:48Like it's just a lot of syllables. Like meteorite. Yeah. TIL, man. I know. He's a nice guy though. And he's like, say it however you want. Like he's not going to dictate or anything, but, but that's the, the original idea was meteorite. SQLite. SQLite. Everybody thinks it's about Lite, but it wasn't about Lite. It's about Lite. 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 Lite version. You should think it was Lite. Yeah, it seemed like Lite, non-pro, non-cool, single-file, throwaway, toy, all those sort of synonyms.
1:03:26So LiteFS, 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 gonna 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 just say sequel light it's okay i'm sorry what they've done like it's three guys that for literally for 20 years have just said like, hey, this is open source.
1:04:08You can look at the source, but like 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. Like I think SQLite is just probably like 100x or 1000x 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 LightFS is one example.
1:04:43I just spoke with the guys at Terso who are doing Lip Esquilite and they're essentially forking, trying to maintain upwards compatibility, but doing some forking because they want to do something similar like what the LightFS folks are doing. And it is a little, I don't know yet what I fully feel about that because I so respect what those three guys that made the original and 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 lib.sqlite, it's being pushed to a server.
1:05:23Right. It's one of 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 But 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 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 Basecamp-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.
1:06:07And 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 note here with what you said. You used the word just before the other word synchronization. It's just a little sync. Those two words don't put together. Just a little sync. Such thing as just synchronization. Just sprinkle some sync on in there, Dave. Exactly, sprinkle something 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, has been used on single tendency so well.
1:06:40If 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? 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 can get readers around the world that 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.
1:07:16And this is one of the, I find it a little annoying when I talk about this because people go, well, SQLite is already the most amazing database that's been used. Like, it's not new. No, it's not new. but sometimes something existing put in a new context it's been there all along new right and it is exciting i'm super excited it's like kaiser sose you know anyways that's a not a direct anomaly don't spoil another movie for us adam come on well sorry about that uh i do want to toot the horn of torso 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.
1:07:58And 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 YLibSQL 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, 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.
1:08:38That there's more there. It's been there for so long. It's written by, you know, the greats of Programmer World, like Richard Hipp and his team. They've been of the greats for so long. Dedicated. They've got these slow and steady mantras about the ways they work. It's trustworthy software. It's stable, reliable software of decades and decades at this point. So 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 progmas and do all the little tweaks because SQLite folks are really dedicated to backwards compatibility.
1:09:28So 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 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 progmas and all the correct protocols of how to use that database well.
1:10:10and I think that's what's going to really help adoption when you don't have to know all the little arcane bits and pieces and you can just rely on the fact, hey, this is a database in a file and it works. Awesome. Let's go. Very exciting. Well, we're talking about SQLite and this dynamic trio. 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 been 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, you know, what happens when your BDFL goes on a bender?
1:10:53Are you referring to anything in particular? It bogs my mind. What if DHH goes on a bender and just starts going scorched earth in something? You could really ruin Rails's 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 governance. How much is written in law and how much do we depend on a set of norms that we all just take for granted?
1:11:34And 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.
1:12:18There is no such thing as just a universally better governance model that does not have trade-offs. 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.
1:13:02A 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.
1:13:45And 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.
1:14:30Now, 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 equal to 9. Right. 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.
1:15:10Sure. But also, I mean, if you pull on historical parallels here, like why did we have the royal families in age of old, right? Well, we had them in parts because as soon as the leader would die in, I don't know, prehistoric 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 such that 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.
1:15:47Just 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 Rassam. I'm thinking of Python. And they seem like they've transitioned pretty well. I think there's probably been some bumps along the path into a steering council now that they have him retiring.
1:16:26I 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 of philosophy, I think, between the two things. But you know what? When I look at those, that scenario, I don't look at wistfully at the Python governance model.
1:17:04I 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. uh no i 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 don't last forever i think we're also gonna 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.
1:17:47And 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 averages, right? Like, Matt's 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.
1:18:27I 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 were as 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 but this is where you will put projects when like oh yeah cassandra like today we're gonna do exercise let's do a new release cassandra you can do it I like this.
1:19:07There'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. And 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.
1:19:38What'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.
1:20:15And 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. 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 WorkOS, 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 AuthKit stuff I mentioned, that identity service, we give that away for free up to a million users. One million users. And this competes with Auth0 and other platforms that have much, much lower free plans.
1:20:49I'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 focused, but could be someday.
1:21:25They'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. They're 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.
1:21:57And 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 office is 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.
1:22:25You 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.
1:23:09Who 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. confluence. And when you get those two systems together, it will blow your mind.
1:23:51Actually, 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.
1:24:23The next step to get unblocked for you and your team is to go to get unblocked.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.
1:25:06can i bring up a somewhat touchy side of this yes or no i'm not gonna stop we're already there calling that Apache Foundation of Retirement Hope, but like, let's go, let's go. Okay. Well, this lasers back to you and Jason. And I think at the time, I believe, 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 Real, sorry. 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.
1:25:44I'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, right? Right, 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 remember, I don't know your history of company closely, but I think so. That's right. But this is a big issue. There was a cancel scenario. So this is Rails adjacent, left of center, but it impacted Rails in the fact that there was a cancel culture attitude towards you, towards Jason, towards anyone who stayed basically at Basecamp.
1:26:32And somehow that storm was weathered to have Rails 7 and to have this conversation, to have Rails 8, and you're not gone. So the BDFL model almost 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.
1:27:11So 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 a lot of crazy stuff 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 with death to some extent on some of these projects and And I think to me, first of all, it's very satisfying to have outlived an attempt on your involvement in that regard, right?
1:28:07Like 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. 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.
1:28:41So Redis ran on a BDFL model with Antires for 15 years, something like that. Long time. And then 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 now, is it source available? Is that the bullshit they call it? Yeah. Or something like that? It's no longer open source. Yeah, rug pull. So 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 forward.
1:29:20I 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 Valky 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. Or things just falling apart. We've been around in our modern incarnation for what, 50 years?
1:29:5460 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 dilution 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'm with you. I think there's a lot of pros comparative to the committee level.
1:30:38You 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 okay with me. But I think we're on this show, and Jared and I both come from the roots of Ruby and Rails.
1:31:17And so to us, in our developer core, like our developer Greenheart, it's Ruby and Rails. Like that's to me, and I probably, I think you're the same, Jared. And so 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 these, this renaissance, this, what'd you call it, Jared? This, uh. I just said it's having a moment. That's all I said. Well, you, 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.
1:31:49But 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 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 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.
1:32:31Not 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 going to fold? Are you 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? 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 am i 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 right 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.
1:33:31I 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 come up with a conference. I'm going to help organize Rails World. I'm going to put my energy behind that. And let's just see 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 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 can 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 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.
1:34:52Do 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't. We'll consider in post. That's right. We'll have a committee decide.
1:35:21So 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. I'm not. 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.
1:36:01Should 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. And 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. 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. That's the beauty of open source.
1:36:38And that's what I love most. But let's talk about capturing less than you create. 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.
1:37:23And 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 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?
1:38:01I 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 gift 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.
1:38:39There'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'd go, 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, 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.
1:39:23That's a human attraction. But most of them, 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 plugin repository, right? That's not the order that most open source developers have followed. Banned. Yeah. 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.
1:39:55It's 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 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.
1:40:28You 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 like, well, here's one of my gifts, that it's a gift. You can't give it to me and then suddenly also 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.
1:41:05That'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 pretext. They're not giving back enough. OK, 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.
1:41:42They 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 envision that.
1:42:14I fully agree with that. Yeah. That's the, when we zoom out and I'm, so the thing I, 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 banned i'm like that seems like it's cool you 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 is 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.
1:43:32And 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 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 an open source package that's running, what, 40 % of the internet or something like that.
1:44:11That's incredible. If anything, I'm biased to cheer for whoever brought that to life. So I'm biased to cheer 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 impostoring, that just violates every norm that I'm interested in having in 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.
1:44:52So 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. I think it's kind of you actually to say there's a lot of context here that we don't know. And like, yeah, but also sometimes like 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.
1:45:27They don't give anything back. Now I'm going to get them. I can recognize that. That's not an alien instinct. It's not something that is so far removed. I've said words like that. I'm sure my brain or felt that way about things in my life. 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?
1:46:03I 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.
1:46:39That's certainly what's happening 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 you get your daily meal.
1:47:18It is in their pursuit of self-interest. This is sort of the root of capitalism. And I get 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 self-interest. Don't bane 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.
1:47:58I 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.
1:48:34Corporations 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. No, no, you're doing the chicken little thing.
1:49:08You 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.
1:49:47I 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. And like that whole thing kind of we've seen it unravel for folks over time. I agree with you. The machine itself is not that. Like it's not going to just stop operating.
1:50:17And 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 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 task.
1:50:53Like Alfred Adler 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 to solve it for us right like i think actually what a lot of these i mean this sounds glib and it's 50 clip and 50 real talk like what 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.
1:51:26I 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, like, that's your choice.
1:52:05Like, 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.
1:52:42That's a lot of money. He has gone on the record to say he doesn't really need money at this point. Like, you know, 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.
1:53:22I 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 the 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.
1:54:03Easy. 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 build something cool. I like Lamborghinis. You should try a yellow one and a green one.
1:54:40I 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.
1:55:17And when that happens with developer tooling, we talked about Antires 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 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 past 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?
1:55:58And 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 extort. Like, okay, like PHP is still there.
1:56:37Laravel 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 it all is good. Good take. All right, last question for me is when is Rails 8 going to drop, man? I'm looking at my calendar here. Like, very soon. So 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.
1:57:14Unless 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 Hay. 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, 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.
1:57:57So, I mean, we're just being extra safe here, extra careful. We just think it's 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.1 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, to push back a little bit and to rest.
1:58:48We got a little bit of both. So 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, too, so I appreciate that. As part of this one, at least. That was cool. That's cool. 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.
1:59:25Some 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 are steeped in the JavaScript suit 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 in his prime time. Love him or not, like him or not, David Hynmer 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.
2:00:05But you decide. Okay, so we have a bonus on this episode. And you're going to love it. What is a bonus? Well, bonuses are for ChangeLaw++ subscribers only. You can do that at changelaw.com slash plus plus. $10 a month,$100 a year. Directly support us. Drop those ads. Get closer to that cool changelaw medal. Get some stickers sent to you in the mail. And of course, bonus content like today. Again, changelaw.com slash plus plus. It's better. It is better. Before we go, I'm going 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 brake master cylinder those beats are banging banging banging banging I love them hope you love them too that's it this show's done we will see you on Friday
2:01:25I'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.
2:02:00Uh-oh. Go to changelog.com slash plus plus. It's better.
2:02:08Thank you.
From the publisher
(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.
