The Changelog: Software Development, Open Source - 10+ Years of Rails (Interview)

Episode Date: March 6, 2015

David Heinemeier Hansson, aka DHH joined the show to talk through the past, present, and future of Ruby on Rails — the most beloved web application framework in the Ruby community.

Welcome back everyone. This is the Change Log and I'm your host Adam Stachowiak. This is episode 145 and today Jared and I are talking to David Hanemeyer Hansen, DHH as he's better known. He's one of the most influential software developers there. And crazy as it might be, we've never had David on this show before. 145 episodes into the changelog. Several years into the changelog. And this is the first time we're having David on the show. But we had him on the show for a big show. One hour and 45 minutes of nothing but me, Jared, and David talking about 10 plus years of Rails. A fantastic show today. You're going to love it.

We had some awesome sponsors, CodeShip, TopTile, and CodeSchool. We'll tell you about TopTile and CodeSchool later in the show, but our friends at CodeShip released a new feature called Parallel CI. And if you want faster tests, you have to run your builds in parallel.

With Parallel CI, you can now split up your test commands into up to 10 test pipelines. And this lets you run your test suite in parallel and drastically reduce the time it takes to run your builds. They integrate with GitHub and Bitbucket. You can upload to cloud services like Roku and AWS and many more. You can get started today with their free plan.

It includes 100 builds a month and five private projects. Or you can use our offer code, TheChangeLogPodcast. Again, that offer code is TheChangeLogPodcast. And you'll get 20% off any plan you choose for three months. Head to Codeship.com slash TheChangeLog to get started. And now on to the show. So we got Jared on the line. Jared, say hello. What's up? Excited to the show. So we got Jared on the line. Jared, say hello.

What's up? Excited to be here. This is a, Jared, this has been a show in the making for us. You know, we've, David, you don't know this, but we've had the idea of doing this show since roughly around the 10th anniversary. Well, I guess probably the tail end of last year. So around October, November, I was like, Jared, we should do a show called 10 Plus Years of Rails with DHH. And so that's what we're doing here today.

So this has sort of been, you know, it's February. So tail end of February 2015. So we're finally there. I expect you to be impeccably prepared then. We are impeccably prepared. But we haven't been preparing that long. We've just been talking about it. Well, speak for yourself.

Maybe our notes don't reflect a start date prior to today, but our thoughts have definitely been there. Excellent. You know, I can say that I take back my history to the beginnings of Ruby and the beginnings of Rails. I can remember first working on it in 2006. I think it was 2005, 2006. And so that's like forever ago to me.

Let me look up the birthday of rails. That was July 24th, 25 or 2005. Oh, four. Oh, four, 2004.

So July 24th, 2000, Oh, then I had it wrong then when I was looking at my notes. Which is really, I mean, it's the release of Rails. Right. The first public release of Rails. Which was.05.

.05. There was a.04321 before I was counting that went before that, which started in 2003, the summer of 2003, really. That was when the first bits of Rails started coming together. Now, I know you tend to walk into a situation like this, like a podcast, to have this conversation. You're typically known, but just in case there's a listener out there saying, who the heck is this guy? Who are you? Sure.

I am David Adamemeyer Hansen. I'm the creator of Ruby on Rails, and I continue to be involved with the development of Ruby on Rails. I'm also a partner and the CTO of Basecamp, which is a project management tool, the original Rails app, the app that Rails was extracted from. And I'm a Dane. I'm from Denmark originally, moved to the U.S was extracted from. And I'm a Dane. I'm from Denmark originally, moved to the U.S. in 2005.

I could go on forever. Author, racer? Yeah. I'm super interested to see that you actually drive a race car. I mean, that's so cool. I try to drive a race car on the streets. It's called a Mustang, but whatever, you know. Yeah, Undertrack is a different animal altogether.

And really, it's a fantastic hobby. A great second way of getting to that magical state of flow, which is what I really love about programming, right? Yeah. When it really works, when it really clicks, you get into the state of flow, which is the straightest path I've found to continued happiness, is to expose yourself to flow. And how difficult it is to get there sometimes is always the challenge.

Absolutely. So you say you extracted Rails out of Basecamp back in the day. To this day, that seems to be one of its virtues, is that it's had a large, very popular production app to track through time. Where did that initial insight come from? So when I started working on Basecamp, it was basically there that I decided

that Ruby was going to be something I was interested in pursuing. Because prior to Basecamp, I've been working on client projects. And clients back in 2003 and earlier, they wanted PHP, at least for the contracting work that I was doing together with 37signals. And if it wasn't PHP, then it was Java like those were the two big ecosystems that I was exposed to back in back in the day and I was not happy with either of them I was not not finding the craft of programming itself all that interesting I was finding it interesting to get programs out of it but working in PHP and working in Java was not exactly igniting my imagination.

But I then discovered Ruby through a number of articles by various... It's kind of funny to say this word because it's been mocked so much that people think you say it ironically now whenever you mention it. But thought leaders, I still think of it as that, even if that word is contained. Martin Fowler, Dave Thomas. I remember those two names from IEEE magazine and a couple of other software development magazines at the time, just mentioning and explaining their thought patterns using Ruby. And I thought, hey, here are all these very smart people who I look up to and learned a lot from. And if they pick Ruby when they're free to pick, then why wouldn't I give Ruby a chance now that I'm free to pick,

which is what was the case with Basecamp. I was free to pick. It was just Jason and I saying, hey, let's build an app to make it easier for us to manage client projects. And obviously, I didn't even ask Jason about, like, hey, what do you mind if I did it in Ruby? We just sort of, or I sort of just decided, I'm going to try Ruby for this.

And that was the beginning. And to try Ruby for Basecamp, I obviously needed just to build some stuff because there just weren't a whole lot of people using Ruby back at that time. And the people that were using Ruby, not a lot of them were using it for web stuff. And I came in from having had most of my programming exposure to PHP and Java with a whole lot of things that I just assumed should be there. And I found that a lot of them just weren't there in Ruby, so I had to build them myself.

You seem to hit upon a lot of ideas that were avant-garde at the time. Nowadays, people are new to web development. These are kind of, they're not cliches, but they're tried and true things that other frameworks have borrowed over time. I think a few shows back we had Taylor Otwell on of Laravel, the PHP framework, which was getting a lot of traction. And he mentioned you a few times as an inspiration and Rails itself. Some of those things, you know, convention over configuration, the opinionated software aspect of Rails and a few other things. Where did those ideas come from?

So I had been exposed to P2P and I had been exposed to Java, as I said, and that had obviously taught me a lot. And a lot of what it had taught me was things I did not want. I did not want to waste my time doing, we called it in the early days, XML sit-ups. That was the staple of configuring any web application in Java, that there was just a ton, a mountain of XML. I remember looking at applications and talking to people working on apps where the XML configuration files were larger than a working functional copy of Basecamp. And that was, of course, just crazy, right? But that was accepted at the time.

People thought, hey, what? 2,000 line XML file? What are you saying? That's crazy. Like, that's decoupled. Now we have it in XML. That means it's magically good. And I just looked at that and thought, no, it is not magically good. I need a framework that I can use myself as one programmer working spare time on Basecamp

and be productive enough that we're making substantial progress. And I have to feel like that's a good use of my time. I could do all sorts of other things. If programming is going to be the thing that I spent my time on, it damn well better be awesome. I need to have a good time. So I'm not going to sit there and just be subjected to frameworks and ideas that just make me feel like crap. And that's a bit of an overstatement. Of course, I wasn't feeling like crap all the time when I was programming in PHP or Java, but I was feeling like crap enough of the time that it just lit a fire. Especially, I shouldn't say it lit a fire. It was sort of volatile elements

that once I added Ruby to the mix, just combust it. Because Ruby was really the key trigger, I think. That here was a programming language that took such a radically different approach to what is a programming language. It redefined the question for me. Programming language was no longer just about how do you make the bits and the bobs go in the right order.

It was about how does the programmer feel about it? And that to me was just such a huge breath of fresh air that obviously no programmer would feel, oh yeah, spending time on a 2000 line XML file is a good use of time. But it wasn't questioned because that wasn't the question, right? The question wasn't, how do we make the programmer feel good? The question was, how do we do all these other things that are sort of sympathetic to the machine, sympathetic to the compile process, whatever else have you. They were not about how you make the programmer feel. And they were certainly not about how do we pick

the human over the computer when the two are at odds which very often happens like we do ludicrously inefficient things in ruby and in rails to this day because we pick the human like if we're picking the computer we do things in a totally different way, but we're not. And that was really, that was that just aha moment that Ruby sort of gave me permission to think those lines of thought. That I already had this discontent, but I didn't know where to take the discontent. I'm feeling like, this is not great. It's frustrating. Why can't I get stuff done? Then all of a sudden, Ruby comes in and says,

let's turn on the light. And then all of a sudden, I go, oh, that's possible. Well, I'm going to get on this horse, and I'm going to ride it fast. Go ahead. So that's where Rails's where uh rails came from with uh with base camp then basically was your your love and passion for a rethinking of how you can program and the idea that you had this open abyss because jason didn't care and it was in your court to choose so if you were choosing you were choosing developer happiness so you're building something

might as well do that but at what point though when you were building something, might as well do that. But at what point, though, when you were building Basecamp, did you really 1st, 04. So there was a process of about six months, maybe. Six months of part-time, I should say, because I was going to school at the time, and we also had other clients at 37signals that we were tending to. We didn't just abandon the entire consulting business to focus on Basecamp, like any quote-unquote proper startup would do, right? That's the startup law, abandon and risk everything. Anyway, so there was this process of about six calendar months where I was working on it. And perhaps halfway through, I realized that I had just made a bunch of tools. I needed something to talk to the database. I needed something to create the templates. I needed some controllers. I needed a bunch of things. And I had started working on active support in a sense, too. I was extending Ruby so that it felt even better

for creating web applications. And I just thought, hey, this is a good grab bag of stuff. And this is the grab bag of stuff that's making it possible and enjoyable for me to create Ruby or create Basecamp in Ruby. Maybe other people would enjoy it too. And I just, I remember feeling this sense of actually obligation, which is otherwise a word I push back against pretty hard in a lot of contexts. But even at that time, I had already spent years working with open source software. Open source just struck me as just such an obviously better idea, just such an obviously better paradigm for so much of the programming world that I felt obligated to contribute my part. And here I was sitting with a bunch of stuff made in Ruby that I can share.

And I was also thinking at the time, man, I am having so much more fun programming in Ruby than I ever was in Java or PHP or anything else I had touched before. That'd be awesome if other people could have that same experience. And I just, I remember thinking, yeah, they're not probably not going to have that if they just come to Ruby as it looks today without any of this additional stuff. Because there's just too much they had to cook from scratch. And while I was enjoying that path, I could totally see somebody like, hey, I'm on a deadline here. I've got to make a project for a client. I'm not going to freaking reinvent every framework in the book just so I can deliver

on this one thing. So I thought, hey, I can give them a jumpstart. I can give them enough cover and an excuse to pick Ruby, to learn Ruby, to fall in love with Ruby, perhaps, if I release this Rails bundle. You felt this sort of obligation to the open source community and you had, you know, you had your Basecamp product coming out and you decided to go ahead and make a framework of it. You also did something which again was I think unique back in 2004 and nowadays is just kind of compulsory

for everybody who wants to get a framework or a project out there that has some good coverages, which you did a demo video. A 15 minute Rails demo. What did you do? Build a blog in 15 minutes? Yep, build a blog. That really seemed to work well. What made you decide to do that? Given the fact that I'd already been an open source user for quite some time, I'd also observed open source and programmer behavior for quite some time. And one of the things that always struck me as so very odd was this notion that programmers hated marketing, that marketing was sturdy, that you shouldn't have to sell your ideas.

You shouldn't have to sell your open source packages. They should just be known as obviously good. If you build it, they would come. And I always thought, that's a load of crap. Like that does not work. If people do not know what you've created, it doesn't matter how great it is. They're not going to get any value out of it. Why wouldn't you quote unquote sell your ideas? If you think your ideas are worthy of releasing, you should also think your ideas are worthy of promotion. Right.

So I just decided Ruby was not going to fall into that category. I was not going to put, sorry, Rails was not going to fall into that category. And perhaps to some extent Ruby too. That I was just going to put it out there and then whoever wants to use it can use it. But that's kind of on their own volition. Hell no. This was going to be an advocacy job. And I wanted it to be an advocacy job because I worked with plenty of programmers who had the exact same feelings that I did about working in their respective ecosystems or domains.

And that was dread that they did not like the working environments of PHP or Java. And even for the people, I thought, who perhaps are not feeling that dread, I can still open their eyes. I can still show them that it does not have to be terrible. Like a lot of people just accustom themselves to acclimate to the environment that they're in, even if that environment is terrible. I thought, hey, nope, you're not going to be,

I'm not going to basically allow you to sit there and not know that there's a better way forward, which I recognize that that sounds arrogant. That's the word. I remember from the early days of Rails advocacy that that was the insult that was most often swung at me, right? You're arrogant. You think you have a better way? Well, it gives you the right to say so. And I thought, that is such a curious and peculiar argument. Of course, I think I have a better way. Why the hell else would I spend my time on it? Why would I invest so much of my free time and my interest and my passions in this thing if I did not think it was a better way? That doesn't mean there can't also be other good ways, but I certainly came into programming Rails as a reaction to feeling things were not good enough. It was not just, oh, let me try something

alternative and different and see if it's fun. It was like, damn, this is just too frustrating. There's got to be a better way, And nobody else is going to build it. I am. So, of course, I walk away from that experience thinking, yep, I have a better answer. And I'm going to tell you about it. Which that really rubs a certain kind of programmer the wrong way. And I think that's just deeply entrenched in the whole scientific association with programming that scientists are not supposed to be promoters. We're supposed to just put out objective truth and then everything will work out in the end. Nope. That's not how it goes. It's not how it goes for the scientific community. It's not how

it goes for programming. Yeah. It's a pure, it's an idealist idea that the cream always rises to the top. I don't know. My dad used to always say that to me and he's a, he's a bit of a romantic as well. And I, I, I wish I could believe that, but I'm with you that, uh,

you have to actually, you know, you have to put stuff out there and you do have to advocate, especially cause there's so much noise. You know, if you're going to be heard through all the noise, you got to speak up and i can see how people will take that confidence as arrogance but it worked i see i have a slightly

different angle on this though because um you know while i remember your charismatic ways and your ability to get a an audience enthusiastic about what you're showing off i also remember the whoops and i almost wonder if that was part of your marketing plea because you were just so and maybe it's you said you're a dane so you've got an accent and maybe that's something people say differently over there i don't know but i always remember that part being like the the virality i guess of what you were doing because you were like something that should be so easy was so easy in what you built and then the whoops just sort of added to it that's pretty funny because at the same time that's one of the things that rubbed other people the wrong way right

especially back in I think the video recording is from 2004 I was gonna ask you where were you at what were you doing to do this it's funny because one of the things I absolutely hate is repeating myself, which should come as no surprise to anyone working in Ruby that we all try to avoid that, right? Well, I try to avoid it too in any type of public speaking. That's why I don't do a lot of conference talks. Even before conference talks were recorded on video, since you basically couldn't give the same talk multiple times, I couldn't give the same talk multiple times because I would just get so terribly bored.

So the audio for that original 15-minute video actually came from a presentation I had made in Brazil. So I had the audio from that because they had recorded it at the time. And what I then did was I basically, I think I just played that audio in the background and then I recorded a video to fit that. So that I didn't actually have to narrate the video one more time because, yeah, I don't know.

I just, like, that would be a hassle. So the whoops, the whole thing was not a well-practiced or edited sort of flow. It was basically just a recording from me standing on stage in Brazil talking about Rails. And I think that's why it has that intensity of it. And it's also why it's not a polished piece of marketing, which is funny because as I was just saying, well, I actually believe in sort of putting together a coherent marketing message. And here I am, I released this video that was incredibly unpolished in all sorts of ways. But unpolished things sometimes have their own charm. And I think perhaps that's what would appeal to you and didn't appeal to others. But

yeah, that's at least the story. I don't know if there was a lot of intent necessarily, except I don't really want to narrate this again. Can I just use the video from this other one? How do you like the fact, though, that Rails is, I guess to the early, early adopters, the early visibility people that were sort of watching the space back then, it may not be so apparent if someone came into the Rails world in the last four or five years,

maybe to stumble upon that. But to those who have kind of been here along with you along the way, how do you like being that Rails is known for this video? I think it's great. I think it's great that, I think it's even greater

that people don't even realize it today. That to me is true progress. When you can lift up the level of expectation to the point where the past seems obvious and that it's just not something we have to think about anymore. These days, of course,

a new open source framework or library should have a slick marketing page. Of course, it should have advocacy. These things were not true at that point, but now they are. And the world is a better place, in my opinion, for it. I don't care whether people remember that as how much did that video have to do with it. I just care about today's better.

And that's really my primary motivation for a lot of things that I do. I just want to make today and tomorrow better. And once they are, who cares what the byline really said? Well, open source has grown up quite a bit since then. And yeah, nowadays, who's not going to ship a fancy marketing page and a video with their project? Of course, there's also a lot of money floating around open source. We know you have opinions on that.

We'll probably get to that a little bit later. This video actually on YouTube. So anybody who wants to trip down memory lane will link that up in the show notes you can watch it on youtube but i got to thinking you shipped this in 2004 youtube came around in 2005 man i don't even know how you get videos on the internet in 2004 you remember yep i ftp'd it to a server that I had, and it was in a MOV container. I don't even know what the recording itself was in, but it was just an MOV file.

And I think you couldn't even play it on Windows or something. I think the first version of whatever I uploaded to FTP could just be played on a Mac. I seem to remember that people were bitching that, hey, I can't play this on my Windows machine. And then somebody re-encoded it or whatever. But yeah, there were a lot of things that we take for granted today that just didn't exist 10 years ago. That is so funny.

I remember talking about the internet as tubes and whether or not YouTube was clogging them. That was crazy. Which is funny because that's still the same conversation today. Instead of YouTube, it's Netflix, right? Yes. Netflix is literally clogging tubes. And now a word from our sponsor.

TopTile is the best place to work as a freelance software developer. If you're freelancing right now as a software developer and you're looking for a way to work with top clients on projects that are interesting, challenging, and using the technologies you want to use, TopTal might just be the place for you. Working as a freelance software developer with TopTal, your days of searching for high-quality, long-term work and getting paid with your worth will be over. Let's face it, you're an awesome developer and you deserve to be compensated like one.

Joining TopTal means that you'll have the opportunity to travel the world as an elite freelancer. On top of. Joining TopTal means that you have the opportunity to travel the world as an elite freelancer. On top of that, TopTal can help provide the software, hardware, and support you need to work effectively no matter where you are. Head to TopTal.com slash developers. That's T-O-P-T-A-L.com slash developers to learn more and tell them the change log sent you.

We were talking here a bit about, you know, beginnings and whatnot. We talked a little bit about why you chose Ruby. And I think another question that comes from maybe opening up this idea of 10 plus years of rails is, did you intend to build a framework and did you intend to influence the open source community to sort of begin building more frameworks and more boilerplates? Jared and I talked in the pre-talk before about Java and other open source projects having frameworks. But it seems like if you go back in history, the spark of Rails sort of sparked this idea of, wow, I can framework something and ship it as open source and do what David did.

I don't know if there was a big intent at that point, except there was some intent. I don't know if that was the intent. The intent for me was, I have a lot of good stuff. I want to share it. Ruby is some fantastic programming language that I'm having endless amounts of fun programming in. I want to share that with other people. So let's make that happen. Because let's also be fair, at the time, I was certainly heavily influenced by the Java frameworks. Java was really the only environment that I was exposed to that had this notion of frameworks.

But it was pretty well developed at the time. It was Struts was one of the major ones back in the day when I got to start working. There was a couple of other things, but there was enough there for me to learn from. So certainly by no means was Rails like an original idea as sort of a framework. Perhaps the thing that I tried to push

and was sort of original at the time was the notion of the full stack. That Rails would ship with the whole thing, the whole enchilada. It would not be this compilation of just loosely coupled ideas that you had to piece together and configure yourself. Because that was one of the things I truly hated about the Java approach, right? That every single project, when they started out,

they had to spend a week just configuring the bits and selecting the bits even, which required researching the bits and contrasting the bits. And I just thought... It didn't allow innovation, right? I mean, you couldn't innovate in a situation like that because you couldn't think on the fly and riff and iterate as Agile was becoming more and more practiced too. I'm not sure I see that that's a dividing line.

What I did see was that it was slowing everyone down with needless decisions that they did not need to make, especially for this large category of applications where it just doesn't matter which of the thousand template languages you pick. Let's just pick one that works for most people most of the time, and it's good. And then when somebody needs to start a new project,

that's not a concern anymore, as we were just talking about, right? Right, and it's good. And then when somebody needs to start a new project, that's not a concern anymore, as we were just talking about, right? Right, don't compete yourself. Once Rails had, exactly, once Rails had gotten to this point where it had showed, to some extent, or at least made more people aware that marketing was not a dirty word,

you could use marketing for open source and marketing and advocating for your ideas was a good thing, now that's an assumption that everyone just takes for granted, right? I wanted the same thing to happen for all sorts of other technical decisions. I didn't want starting a revenue project to begin with, oh, which template language should we pick? Like, who the hell cares? Like, that's just not an important decision for the vast majority of projects out there.

But those are our favorite decisions to make, right? We love to just sit around and twiddle our thumbs and talk about that stuff, right? Yes, which is why it cuts the grains to the grain. Which is why, even to this day, Rails is one of the very, very few full-stack frameworks. I mean, besides the fact that it's a very substantial amount of work to go full stack, I think it's also deeply counter to the core of many programmers. They want to believe that every single application is a unique snowflake, that they're so brilliantly unique too, and that their value comes from their careful selection of which template language, which

data mapper, which whatever the hell it is in your stack, that they tailor that in this bespoke fashion to that specific application, right? They derive a lot of joy from that, which is why the notion of the integrated system, the full stack system, dare I say it, the monolithic system is so counter to what many programmers really feel is right. Most programmers are enamored with this idea of loosely coupled bits, the Unix philosophy, a variety of tiny focused tools that are endlessly configured together. And yes, that works great for Unix, and it works for a lot of other domains. And in my contention, the web is one of those things. And building web applications is certainly one of those things.

And Rails is a large argument trying to refute that idea that every programmer should sit and make these minutiae decisions on technical assemblies every single time on their own. No, Rails says we're going to start with a curated set of defaults that will work great for the vast majority of people for the vast majority of time. And this is the important part too, of course, is that when it does not work, you're free to pick something else and all the other decisions you can still benefit from. If you have a very particular affinity for, say, I love riffing on this, so I'll do it again,

RSpec as your testing environment, you can slot that into Rails and it'll be great. If you don't have a specific thing, like Rails ship with something great in the box with sort of a test unit style, and it'll work wonders for you, right? And do that they can make sort of there's tiny little substitutions but they don't have to prepare the whole thing from scratch what we're giving you is not um just a bunch of ingredients and saying hey here's how you mix it we give you a finished 21

course meal and then you can say all right i don, I don't like shellfish. So skip dish number seven. But the other 20 dishes, they're still designed on the menu because people sat down and thought, hey, what would make a good menu here? And again, this is actually a contentious point, which is why I love it, because it gives Rails still a unique argument in the world. This is one of the many things that Rails have not won the majority mainstream argument on. I'd say this is why Rails is still an outlier as it comes to full stack assemblies, because most people just in their hearts, even if they sort of practically can recognize, oh, I guess the Rails kind of makes it easy to get going fast, but oh, isn't that actually annoying?

But there's just something there that prevents more programmers from going down that path. And I think that's both curious and a little funny that people on the one hand can realize, okay, I get a lot of good out of this, but somehow it's just so deeply at odds with the philosophy that allows them to produce that good that they just, they can't kind of hold those ideas in their head at the same time.

It's gotten a lot easier to swap in, you know, swap out the shellfish or whatever, to pick and choose pieces as Rails matured, you know, over time. We'll talk about kind of the history of the framework, but I do want to go back to the point you said about it works great for Unix, but it doesn't work for the web. And I'm wondering why you think that is. I think part of it is that the web and the web application follows more of a template form than the use of an operating system.

An operating system has to account for more different kinds of usage. The web application is a pretty well-defined space, at least for that majority template that we're trying to present, which is controllers talking to a database, creating views. It's a very templated approach to software development, right? It's not sort of blue sky. It's well-trodden domain. And I think the more blue sky you're working in, the more novel the application you're working in, the lower level tools you need. The more your application is just like everyone else's application, the higher level tools you can benefit from. I think people have said that the closer your app is to Basecamp,

as far as the way it's going to work, the better Rails is for a fit for your app. Do you think that's fair? It's funny because most people say that as a point of derision, right? Yeah. And I embrace it. I agree with that point. Yes. The closer your app is to Basecamp,

the closer you will be to having the same opinions on me on most things. Now, the point of derision that I don't agree with, of course, is that Basecamp is so very unique, that Basecamp is this special application that is unlike most other applications. I believe that the first statement is true, that Rails is a better fit for you the more your application is like Basecamp, because I also believe that Basecamp is like most applications most of the time when it comes to the web.

In fact, I'll go even further than that. I'll say that this is perhaps the point where we cross into arrogance, is that more applications would be better off if they were more like Basecamp more of the time. And I'm talking about that on a technical level, not necessarily on a UI level, although there is some bleeding going back and forth there. I think that there's lots of applications out there

that are trying to be needlessly novel in order to satisfy the egos of programmers who do not want to feel like they're working in cookie cutter domains, that they somehow attach their sell worth to how novel their application is. And then they create artificial novelness by picking technical stacks and so forth

that are off the trodden path so that they can feel special. That's a lot of third-party remote psychoanalysis. Yeah, I think there's probably some generalizations in there. That's the only thing we can trade in when we talk about programmers as a mass. Right. And now, a word from our sponsor. It is time to put the programming books away.

Put them away. Put them down. And learn by doing with CodeSchool. CodeSchool offers a variety of courses to help you expand your skills and learn new technologies such as JavaScript, Ruby, iOS, Git, HTML, CSS, and many more. Code School knows that learning to code can be a daunting task. They combine experienced instructors with proven learning techniques to make learning to code educational as well as memorable, giving you the confidence you need to continue past the hurdles. They're always launching new courses on new technologies and offering deep dives on tried and true languages.

So if you don't see them you need, suggest a course and they'll build it if there's enough demand. CodeSchool also knows that languages are a moving target. They're always updating content to give you the latest and greatest learning resources. You can even try before you buy. Roughly one out of every five courses on CodeSchool is free. This includes introductory classes for Git, Ruby, and jQuery, which allow free members to play full courses with coding challenges included. You can also pay as you go. One monthly fee gives you full access to every CodeSchool course. And if you ever need a breather, take a break, you can

suspend your account at any time. Don't worry, your account history, points, and badges will all be there when you're ready to pick things up again. Get started on sharpening your skills today at Codeschool.com. Once again, that's Codeschool.com. Let's get back to a little bit of history, I think. 1.0, so December 13, 2005. What was Rails at 1.0? Was it just an ORM with an MVC?

What all was in there? It had ActiveRecord. It had ActionPack, ActionController, and ActionView. And it had, I'm pretty sure we had it extracted ActiveSupport at the time too. And we had Rails ties to bind it all together. So we had talking to the bit database, having a controller layer and having the view. That was, as far as I remember, those were the bits. So we did not have, say, Action Mailer. We did not have, what else have we added? We did not have Action Web Services, which was a framework that was for a time in

Rails. But the major components were there. It's funny because I looked recently at an old Rails app, and it was surprising just how much I could recognize. There's still a lot of, I'd say the vast majority of those ideas from back then. They're still there. They're still present. We've refracted them. We've made things better.

We make it easier, and we've built on of it and extend it in all sorts of ways. But that initial approach, the initial architecture has helped surprisingly stable over the years, I'll say. Yeah, it's funny. You know, you have Basecamp, which is the de facto legacy Rails app, right? It's the longest one that's been around. But it's also made the migration step-by-step. Just to get a little bit of my background, I've been doing Ruby and Rails since about 2006, amongst other things. But I still support a Rails app for a customer that's sitting on 1.1.6. And by the time I inherited it, it had been too far gone to get it up.

And it's really a maintenance project, just change this, change that, make sure things don't go down. But that, what you just said, kind of resonates because, yeah, it's antiquated. There's things that I'm missing that I go back to, and I'm like, oh, this is death. But the guts are still the same. It's still a Rails app. Not too far gone than what we're working with. What is it, nine years later?

Or 10 years later for 1.0? I think that's the DNA. You can recognize the DNA. Because the fundamental opinions about being a full stack framework and an integrated system and the idea of MVC as the basic skeleton and so forth, those decisions remain as valid today as they were back then for Rails. So that's why you still recognize the DNA,

that we've had all sorts of change, but it's been mostly evolutionary change and it's been changed to deal with new problems that's been thrown at us, less sort of revisiting the core assumptions of the original framework. And that's not by design. Like, I don't feel any necessarily better about that. There's a lot of people who are like,

oh yeah, I said that like five years ago and it's still true. Am I not awesome because of that? And I was like, I don't give a hoot. Like whether Rails looked the same at 1.0 as it does at 5.0, that's not the important thing to me. The important thing to me is that we continue to work with a framework that we love working with, and we're making it better, and we're making it the best it can be at all times. That's really the core for me. I would hate it if Rails was somehow tied to decisions 10 years back if it meant stopping us from realizing the best Rails that Rails can be.

There might be lots of people who are like, oh, Rails is outdated and they want to pick a different paradigm or whatever. That's awesome. But at least for me, I want to feel like Rails is the best it can be today because of what it is, right? So that's sometimes hard. Migration paths can be long and slow. But I also think that after working on Rails for me, it's close to 12 years now. I have enough faith in it rolling out over time. Okay, so here's a part of the framework I don't like. We're going to deprecate it and it's going to take a couple of versions, but like in a year or two, maybe, it's going to be better. And I can maintain that that's okay because we can have this long timeline because we know that the timeline up until this point, it turned out pretty well, right? There's just some confidence you get from working on something for 12 years that eventually things will pan out if you keep moving forward, which that's really the key, right? Like it's so easy to get stuck in the legacy. It's so easy to get stuck with, oh, these are the past

decisions we made. We have to keep them going forward because it'd be too much work to change things and go back and so forth. And I've always retained that is not going to be how we roll, which sometimes creates work for people. Well, I shouldn't say sometimes. It creates work for people all the time. Because when we do learn something new, when we have new and better insights, we change things, which require you to update your application, which means that sometimes upgrading from one version to another takes work. That's the trade. And that's the trade I'm exceedingly happy to make. So early on, obviously, it was just you making commits.

And I'm curious if by 1.0 if you had contributors yet. But to date, we see over 2,600 contributors. It takes more than one guy to start a revolution, so to speak. So obviously, you weren't the only one involved, at least not after the video went viral. Who are some of those early adopters that really jumped on board, started committing, and helping out early on? Sure. Well, first of all, the 2,600, that's just on GitHub. We actually track all the way back from when we were on SVN2. And I think we even have some history from CBS. And the full contributor count is, I think, 3,800, which was that was the tweet I was tweeting earlier today, which is just some of those early people. We had a really quite early, quite quickly, I realized when I started talking about Rails on the mailing list

that there were indeed other people who worked on web stuff in Ruby at the time, even though it didn't seem so because it wasn't very visible. Ruby as a thing was not very visible back in 2003. But I started talking about it on the Ruby talk mailing list. And I got in touch with a number of people who were like, oh, yeah, I'm also working on this. Hey, could you send me the early version? So even before 0.5 was released, a number of people already had the Rails source code. And some of those people were, I think Jeremy Kemper was one of the early ones.

Jeremy Kemper is next to me, the longest running Rails core team member. He is all the way back from 2004, I think. And Toby, for example, from Shopify, he was one of the very early members as well. Thomas Fuchs, famous for Scriptaculous, and he works on Freckle now and so on. Let's see, what else do we have on the list here? Rick Olson, I think he

is still at GitHub. Did a lot of cool work in the beginning. Sam Stevenson. What? Techno Weenie. Techno Weenie, exactly. Yeah, we still have those IRC handles on the core alumni list, which is kind of fun. Well, some may know him a little less as Rick Olson and more as Techno Weenie. Right, exactly.

The same thing with Thomas Fuchs was Matt Robbie. Sam Stevenson, who I work with alongside Jeremy Kemper at Basecamp to this day was one of the very first core contributors as well. He worked on Prototype like very back in the day and of course continues to do all sorts of awesome Open Source stuff. And perhaps some of those people are pretty well known. There's a couple of other guys that were around in the early days that perhaps the Open Source community,

perhaps at least the Ruby open source community, haven't heard from as much. Scott Barron was one of the guys. Florian Weber, who did a lot of the early work on Twitter, was on the list. Nicholas Sakaar, he did a bunch of the work for the router. I remember the router is one of those things. I think, as we say, some things sort of have stayed the work for the router. I remember the router is one of those things, I think, as we say,

some things sort of have stayed the same for 12 years and the router is not one of them. The router is probably one of the most rewritten bits of Rails. We've gone through tons of iterations and Nicholas, I think, had Generation 2 or Generation 3 was sort of his masterwork. Nice. So one thing I want to just double back, a question three was sort of his masterwork. Nice. So one thing I want to just double back, a question I was thinking of asking when we're talking about the initial release and just kind of got lost in the stuff there was you obviously prepared and you had an advocacy or a marketer's look at getting it out there.

Still, though, were you surprised by how successful it ended up being? Of course. I think, of course, that would be the, that would be the height of arrogance, I think, beyond even my capabilities. I just said, yeah, what are you talking about? 2003? I knew that tens of thousands, if not hundreds of thousands of programmers would use Rails over the years. I had them at whoops. Yeah, there's no way that I think anyone could have foreseen that. What I did foresee, though, was that it was going to be popular. And the reason I knew this was it just felt so much better. I knew pretty quickly into it that like, holy shit, this is not just like

10% better, 15% better than what I was doing before. This is multiple times, if not an order of magnitude better, and by better defined as enjoyable and productive and all these other things, at least for me. And I thought, if I'm feeling an order of magnitude jump in productivity and enjoyment, well, when I release it, maybe people won't get that order of magnitude, but maybe they'll get two times or three times. Like, they won't get 15%. And I thought, if you're sitting on that kind of leap,

there's no way that's not going to have some uptake. There's no way that people are just going to say, yeah, I don't care. So what if I could have like three times the amount of fun, be three times as productive? It's not a big deal to me. Absolutely not. But it's still a huge, huge jump from that to where we are today. So just on the note of not being, I guess, being surprised by the success, when we go back the line of like the history of Rails, we also sort of indirectly parallel Basecamp too, because they're sort of side by side to a degree in terms of existing, you know? How did the success of Rails lead into the success of base camp and not

just so much the the product but the company of 37 signals and just how you took uh that to backpack and to die and all the other things you've done over the years whiteboards right boards actually not whiteboards right boards how did the you know i guess the success of rails bleed into the success of Basecamp? So one of the things when we started with Basecamp was we didn't have a lot of money, right? We did not take any VC funding. We were funding the development of Basecamp entirely off the consulting projects that we had at the time at 37signals. And as anyone know, if you have a four-person consultancy, you're not exactly swimming in cash.

So it was simply not an option for us to outspend any competition there may have been on advertising or anything else that was expensive. The only thing that we had that we could do was we could share what we learned and we could use that as our marketing. We could build an audience, people who sort of were interested in what we had to say because we were sharing our techniques and thoughts about business, about technology, about programming. And then we were hoping that if they liked our thoughts on these matters, that they would give our product a try. So that was our marketing strategy, very intently so. And Rails, of course, played beautifully into that. Basecamp was the original application. So anyone looking at Rails usually also looked at Basecamp because that was sort of the validation.

Eh, I don't know about this Rails thing, but I guess if it can make Basecamp, it's worth a second look. And I think that that's one of those things that are just so important about extractions, that frameworks invented out of thin air or rational idea, not through experimentation and sort of an empiricist approach, tend to, at least for me, far more uninteresting. Lots of people, they just look at

what was made with this? What can you make with this? Which is, in some ways, it's a funny test to put up because everything is too incomplete. You can make anything with anything, right? We could still be making websites with Visual Basic.

Actually, maybe for all I know, some people still are. I'm sure there's a few. Okay. And so you can make anything with anything, right? So it's kind of a funny test, but I think it's also just a very primal one. We want to see, like, what was it up to?

And I think at the very least, it just leads credibility to the builders. Like, if the first app that was made with Rails was some crappy piece of crap that nobody wanted to use and it looked terrible and it didn't have any customers and so on, that would have made it harder to sell Rails.

Of course it would, right? We had a similar conversation recently with Rob Eisenberg. He created Durandal and then recently Aurelia, two JavaScript client frameworks. And Durandal, the product he created with it, it had since failed not so much because of the framework but because of the business model or company or whatever. I'm not really sure of the details.

But I guess that's sort of unique to look at with Rails. It sounds like what you're saying is that Rails may have had some success because of the fact that you always had the great business behind Basecamp. And you always had, you know, one shining object, at least, you know, Shopify and many, many others, of course, not saying that Basecamp was the only one because there's plenty of other really good successes out there. But you can always depend on Basecamp to say Rails is good because Basecamp is good. And there was this symbiotic relationship that Rails derived a lot of legitimacy from being extracted from Basecamp. And Basecamp got a lot of leads because people got interested in Rails. I think sometimes people over sort of subscribe what sort of how much truly came out of that.

Like these days, if you ask the vast majority of Basecamp customers, do they know what Rails is? I guarantee you that they'll say, what? Yeah. I don't know what that is, but in the early days it helped. And it helped because when you're sort of trying to get a business off the ground, you don't need millions of people. You just need first a few hundred and then a few thousand.

And in those early days, I think the association with Rails was part of that larger marketing strategy that we were going to out-teach the competition. We were going to share more than anybody else. We were going to share more of our recipes and more of our technology. Yeah, I think if nothing else, it probably helped on the talent side,

help you get talent early. I mean, you got Kemper and Stevenson still there today where it probably helped attract developers. Do you think that's the case early on? Absolutely. People that wanted to be working with Ruby? Absolutely. Yeah.

Yes, we got to cherry pick some amazing programmers because not just because of Rails, but in the early days just because of Ruby. Right. Most people were just not being paid to do Ruby back in the day. I recall that first Ruby comp I went to back in 2004, and I recalled asking, oh, so how many people are being paid to work on Ruby? And literally, I think two hands went up out of the 40 people there. Exactly, yeah. Huge sample in any case, right? But just weren't people being paid to do Ruby. And here we came along and we were paying people to do Ruby.

Well, paying people, that's even a big word. The first other programmers beside me that we hired at Basecamp was in end of 2005, I think, James Buck. But absolutely, James was working at the time doing Java at some university, if I remember correctly. And here we were doing Ruby. He was doing Ruby as a hobby side thing, but weren't able to use it at work. And we were saying, come over here. We'll give you a job doing Ruby. And then, of course, even to this day, it still works. It's still a great way of attracting people. And The Basecamp is a place that is still active in open source,

still shares and helps steer Rails, and you're going to get to work on all that. Of course that helps. Absolutely. Let's move forward a little bit. 2.0, we said, was in 2007. Let's look at 3.0, which launched August 29, 2010. If I recall, that was the big MIRB and Rails merge release. Is that correct?

That's correct. Okay. Share a little bit on that. You know, we don't have to go too far into the MIRB and Rails history, but kind of how that came about and how MIRB affected Rails during that time. Sure. So at that time, one of the big Rails shops was Indium Yard. They were doing hosting for Rails applications. And Esra started Merb. Initially, I believe, I'm a little fuzzy

on the history, but as a sort of, oh, well, if you have some performance issues with these parts of Rails, which was something that they issues with these parts of Rails, which was something that they were seeing in their deployments, you can use this smaller targeted thing. It was kind of, at least as I saw it, it was started more as a sort of Sinatra kind of thing, like let's create some microservices for a few things. And then it kind of just grew from there to the point where a lot of what was going into MIRB

was just, from my perspective, a bit of a reimplementation of many of the things we had in Rails. And when I looked at MIRB, I didn't actually see a lot of philosophical differences. I didn't see a lot of things that like, oh yeah, of course this can't be in Rails. I started wondering, this is great work. Why do we not have these things in Rails itself? Like if you're making, let's say, the router more efficient, why wouldn't we just make the Rails router more efficient? So I started talking to people at Engine Yard. And I mean, it was a little bit contiguous at

times. I'm not going to lie. Like there was a little bit of, obviously, Esra and the team around it, they sort of, they had a thing of their own, even if they were reimplementing a fair amount of Rails stuff, that they had created something standalone, and they had some affinity to that. So it took a fair amount of talks, both with Esra and with Yehuda at the time to figure out, do we actually have a shared philosophical base? Is there, are these divisions that we're currently perceiving between Rails and Merp, are they really there? Or are we, what do you call it, violently agreeing? And I think it turned out over a series of conversations

that we were violently in agreement. That the Merp group was focused on a number of real performance and other issues that we just hadn't addressed. It wasn't because we didn't want to address them. It was just because nobody had done the work. And here came a group that did the work. So we found a way to make that happen together, that that work could happen in Rails and we could make Rails better. Since there were no philosophical differences, why should we have two frameworks pursuing the same philosophical goal? In my mind, competition is great when it's a competition of paradigms or it's a competition of different philosophical goals. Like Sinatra is a great example. Like Sinatra is so obviously not Rails, right? It's trying to pursue a very different path that is tangential or sort of separate, not overlapping directly with what Rails is doing.

So that makes sense as its own thing. Merp was moving in a direction that was far more like a reimplementation of Rails to large extents. And we just did the re-implementation in Rails. We spent the time and ported over a bunch of these MERP advances in efficiency and so forth. And Rails turned out to be stronger for it. And we got some new members on the core team, and we enlarged the community, and we didn't splinter the community. I think some of the pains, for example, that Node is currently going through with

Node and I.O. that split we were able to at least fold back in. We didn't avoid it 100% because there was, I don't know, six months perhaps where there was some contentious debate back and forth and splitting of the community. And in the end, we ended up folding it in. Rails turned out to be better for it. And everyone turned out to win

because we now had one strong ecosystem that was even stronger. And no doubt the community bolstered and not divided as a huge win. What were some of the technical wins in your mind of the merge? Efficiency. I'd say efficiency and extendability to some extent.

As we were saying, it was never, there was a perception that the dish of rails, the 21 course meal here was completely fixed and that the chef would accept no substitutions. And that was not my opinion at all. And it was my fault, obviously, for allowing that perception to be adopted out there. But what I just said was substitutions are fine.

It's just not something I want to work on. If you want to work on it, if you want to work on making it easier to swap in another testing framework, more power to you. I'll totally welcome your work. It's just not something I'm going to spend my time on. And that was initially taken, and my fault, for not making that clear that the position was just not one saying like, don't petition me to do it because I'm not going to do the damn work. You want to

do the damn work? Wonderful. We'll get along swimmingly. And so we did, right? Like we erased some of those misconceptions that had arisen and we got a lot of extendability in for it. I think it was after Rails 3 where our spec, for example, didn't require a lot of monkey patching to do its work because we had the hooks and extension points to make it possible. And we got a bunch of efficiency gains. I think the router was one of the things where a bunch of work went in. And I think also in other places, they had just done some optimizations because Engine Yard's work on Merck arose from watching a lot of people deploy apps on their platform and just falling over, right? Because they had done something that either was inefficient or they exposed inefficiencies in the framework. So they

had a lot of data on where this went wrong, where I didn't have that data. Like I was sitting on the data from Basecamp. And when you were using Rails to build Basecamp, I wasn't hitting any of those things, right? And that is the power and wonder of a broad tent, of a broad community, that everyone gets to bring their improvements to the table, and they can improve things even if I do not hit those problems, right? So I was not hitting a lot of these issues, and still Rails became better. And maybe I was going to hit those issues three months later, and then I was thankful that they had done the work but just to clarify there it sounds like merb was created by ezra and yahuda when they were working in the engine yard

because they thought that you wouldn't welcome as the chef wouldn't welcome the additions to the menu is that right and that's part of the reason yes okay part of the reason and and that is a failure of open source governance i think that one of the things I took away from that was it's very easy to cultivate this perception of elitism that there is this hollow core, hallowed core, not hollow core, hallowed core of Rails developers, they make all the decisions. They take no input from anyone. Anyone who posts contributions is going to be ignored. And to be honest, some of that was true. Some of that was true simply from a perspective of who's going to review these pull requests? Like, I was not going to do it.

My contribution to Rails has always been, I'm going to put in my contribution to Rails. I'm not going to spend that much of my time to review other people's contributions. Again, that was taken as then, well, you don't want contributions. No, I just said, I don't have enough hours in the day to man both Basecamp, run it as a business, program the application, and put all the extractions I take from that into Rails and also do all the work on the pull request. We need a larger team of more diverse interests where some people find great pleasure and value in doing the review of contribution work. And we have that today, right?

Like that's basically what I was celebrating when we were talking about the 12,000 pull requests process. There was no way that was going to happen back in the Rails two days because we just didn't have the bandwidth as a community to adopt that and deal with it. And we learned a lot from it. I think that the path today for new contributors is a lot nicer and friendlier than it was back then. And that's prevented us from running into the same issue with the next splinter group who thought that their input

wouldn't be valued. And now a word from our sponsor. Hacker Newsletter is sponsoring the show this week. In front of the show and a great companion to our newsletters, Hacker Newsletter is a weekly email shipped on Fridays that includes the best articles on startups, technology, programming, and more. All links are hand-curated from Hacker News by Cale Davis himself. And one of the things I personally love about this email is that its organization is phenomenal. All the links are grouped into categories to make it easy to scan and find your favorite Hacker News post, like show HN, code, design, books, and more to an almost 30,000 subscribers

and subscribe today to this email at hackernewsletter.com. So there are a lot of changes that went into 3.0 around the modularity, and yet I think 3.1 was probably a bigger deal as far as upgrade trouble. I think GitHub famously stayed on the 2.3, I think, branch for years because of difficulties upgrading. And most of that, I think, was around the asset pipeline. Now, to me, the asset pipeline was like a great idea and somehow a terrible idea all at once. Take us back to the time of the asset pipeline, whose idea it was, how it was implemented. Just give us kind of a gist of how that rolled out. Sure.

So first of all, I don't think that the upgrade trouble was from the asset pipeline. Oh, you don't? The asset pipeline was an optional piece from day one, still is. The difficulty was definitely from 3.0. Because in 3.0, we just changed a bunch of APIs. And we had to make those extendable points that people from the Merp camp wanted to bring to the table. And some of the optimizations, they had API changes behind them too. So we were changing a lot of internals. And when you change a lot of internals and we had a lot of changes like that, it just becomes harder to upgrade. And especially it becomes harder to upgrade if you have a Rails 2.3 application

where you've made a lot of modifications to the framework yourself. Because those modifications no longer work. If you were digging into the internals of the Rails setup, those internals just got blasted to smithereens. The upgrade from 2.3 to 3.0 was not actually terrible if you had no extensions to the Rails framework, but they were brutal if you had deep extensions to the Rails framework because so much of the internal implementation changed. And that's, of course, exactly what a lot of big shops have because Rails 2.3 just didn't address as many concerns as Rails 4.2 does. And a lot of people at the time,

they were making do with their own attacks at those implementations. And they weren't necessarily pushing that back upstream. So GitHub might have all sorts of extensions to, let's say, ActiveRecord that dug deep into the bowels of how the query engine worked or something like that. And then if the query engine changes,

then those didn't work anymore. So I think that was the core of it. But I think the asset pipeline is still a good story because it was one in a long series of adoptions that Rails has made that was not universally liked at the time. Before that, it was REST. And before that, pluralization is one of the earliest ones I can remember having controversy around. Rails has a very long history of making extensions to the framework and meeting resistance from certain camps that like, oh, this is not Rails' responsibility. You should not address this. Somebody can just deal with it in gems or elsewhere. And the asset pipeline was certainly one of those things. And I'm still a little fussy on what the actual core of the opposition was about. Because at least as I saw it, the asset pipeline made it easier for us to deal with JavaScript and CSS in a structured manner instead of just dumping

everything into public. But I think the problem with the exit pipeline for a fair number of people were that it came a little too late. It came a little too late in the sense that they had already tried to hodgepodge their own solution to the problem with their own in-house tool chain. And now here comes Rails and puts this into the core. And all of a sudden they have to change from their own internal tool change to something else. And that's kind of a little painful. So, but there's that, that's the practical concern.

And then I also think that there was that philosophical concern. And we have that every day, almost every week, there's somebody in a pull request saying, why does Rails need to do this? Well, because it's better. Because Rails is better when it also addresses this issue. Is the handling of CSS and JavaScript assets, is that not something that most applications need to do most of the time?

Of course it is. And since it is, we should make that experience as painless as possible, which perhaps that is the third point. The asset pipeline was a fair amount of work. And as any fair amount of work, it had rough edges. It had S cases. And people would hit those S cases that I hadn't hit and other people working on the asset pipeline hadn't hit. And they would think, oh, it's broken. Like they confused hitting a bug with,

is this a fundamentally good idea? And that reminds me of another big schism we had in the Rails community, which was the adoption of Bundler. I think actually the adoption of Bundler came with Rails 3.0. I thought you were going to say CoffeeScript. Well, that too, but that just follows the same pattern. So to me, it's less interesting. I think the Bundler one was even more interesting because the parallels to the asset pipeline are even clearer. To me, I think it was probably Yehuda that showed me this, or maybe it was in a conversation with Yehuda. But very quickly after I saw Bundler, I thought, this is obviously the solution. Obviously, there should be a way to declare your

dependencies and have a way to resolve them. And that should not be checking in a copy of the engine you want to work with in your own source tree. That's a shitty solution. But there was so much pushback around Bundler. And a lot of the pushback came from Bundler was broken. Yeah. Because Bundler was early and Bundler is solving a substantial problem. So there was just a lot of bugs in the beginning. And someone would get bitten by two or three Bundler bugs and they'd think Bundler is a terminally flawed idea that cannot be trusted. Rip that shit out.

Right? And that's what they would take away. I mean, it's funny because this was not just novice uses of Rails that had this opinion. I had epic debates with Jeremy Kemper over Bundler. He did not see the underlying value in Bundler for a very long time. There were some philosophical differences there too, which goes back to the debate of Unix versus integrated systems, which was I, from the beginning, said I want or I want,

I desire the sort of Rails dependencies to work as a bubble. Like when I declare that my Rails app uses, let's say, this plugin, it should just be available. I don't want to use require. Like that's otherwise one of the sort of underpinnings of most programming languages is that you're explicit about your dependencies at the individual subatomic level. Right. That in the individual file that uses a certain library, you include that specific library. And I remember from my Java days where you just see those imports at the top

of the file and they would just be like pages long. And I thought, that is just retarded. That's not how we're going to play this game over here. And we didn't. Today in Rails, most Rails applications do not call require very much. Everything is auto-loaded when it comes to your own models and controllers and helpers and so forth. And even the default for Bundler is to auto-require the gem such that it's loaded at boot, which I thought was a universal good. Lots of other people did not at all think that that was a universal good. So that took months, if not years, for that to become established practice. And today, of course, it's a total non-issue. Nobody is going back and saying, oh, I wish Butler didn't exist. I wish I manly had to assemble my dependencies and so forth. The debate is over,

and we moved on. And I think to a large extent, the same is true for the asset pipeline. There are still some holdouts who have their own build pipes. But I think that the opposition moved on to a different spot, which is more around what should Rails do with client-side MVC? And how should it deal with that kind of stuff? And now there are sort of new opposition there. But the asset pipeline itself, for the use case that Rails uses uses it for that's no longer a point of controversy. Right, the controversy nowadays as you said is on how Rails handles fat JavaScript clients and how it plays nice in that ecosystem

which is becoming more and more popular as time passes. So how does it play? How now and how in the future will it handle JavaScript? So there's sort of two approaches to that. One is some introspection about how large the Rails 10 should be. And at various times, I've been flip-flopping back and forth on this issue. Should the Rails 10 be so large

that Rails is still a great fit for API-only servers, where Rails is not at all concerned with what the whole Vue aspect of things look like, which is kind of what the client-side MVC setup is, right? Treating Rails just as an API server. And for some times I thought, well, that would dilute what Rails is and what it stands for. I've changed my position on that. I don't think that that's true anymore. I think whether you're doing client-side MVC or you're doing server-side generated HTML with JavaScript sprinkles,

which is another term I love because both sides see that as a, it's a point of derision and a point of sort of praise at the same time. I love those terms. I love when opponents of the same idea can agree on the term. It's point of sort of praise at the same time. I love those terms. I love when opponents of the same idea can agree on the term. It's kind of like Obamacare. Right. That like both sides can think that's a good term. That's one of those rare moments I think is great.

But anyway, we're saying, you know, that sort of the appreciation I've come is that we share far more than we differ. So what if we don't generate the view in the same way? To me, in many ways, that's kind of, it's a bigger point, but it's related to, say, some people like Haml and some people like ERB. Okay. So some people are going to build their application in client-side MVC. Why should we not collaborate on an active record, on action mailer, on action controller? Why should we not collaborate on those things just because we differ on how the view is generated? The Rails tent is large enough to fit people who want to build client-side MVC. Of course it is.

And I can divorce that from my own personal opinions about how suitable or not suitable client-side NBC is for a large swath of applications and whether I personally want to build my applications in that fashion. I think that's a key foundation of why Rails is such a big success. It's because we've found a platform where many people can collaborate even if they disagree on some of the particulars. We're not blowing up the community just because there are different opinions on the value of client-side MVC. We share so much more than that. And I think that that's some of the fragility

of certain small tent open source projects where they consider like, this is the way, right? This is the only way. That's not how Rails is. Rails comes with a set of defaults. Those, I am far more particular about how they should be structured. But as we just talked about, so what if you don't want dish number seven? You like the rest of the menu, right? We can agree on the rest of the menu and we can still eat at the same restaurant and have a good time. And that's what Rails is. So I think going forward, we're going to make it even easier for people who want to say, Rails, I don't give a hoot when you have to... Actually, let me restrain that. I don't give a fuck what you have to say about the view which is often the

level of contentiousness that that we have in these debates right we can't get the whole show without that right no i don't give a about what you have to say uh on your opinions on the view it's just like i'm not going to follow that and we can still be friends yeah we still be friends and we're going to move towards that. So with the practical matter of that is perhaps less than the cultural matter. And the cultural matter is basically Rails saying, you guys have a home here too. If you want to make a client-side MVC app where Rails does not generate any views whatsoever, fantastic. Come over here and I'll pass you the salsa. It's still going to be a good party. And we can still work together on making ActiveRecord better.

I'll pass you the salsa. I love it. So what does that look like? Does it look like you flip a switch in a config and just a whole bunch of stuff gets turned off? I think so. I think so. I think it's like Rails new my app dash dash API

or something like that, where it just does not include all those bits and bobs that relate to view logic and generating of HTML and the asset pipeline. That those things are just not relevant if you're treating Rails purely as an API server. That sounds like a good idea to me. I've built Rails API servers and enjoyed using ActiveRecord and ActionController and just not having a view layer rendering JSON.

It's nice, so I'm glad to see. I used the Rails API project, which is a slimmed-down version, so it's nice to see a lot of stuff's going to get into it. That's basically, that's the foundation. That's the spike. So maybe to pause it for a second, if someone out there is working on a project that does what MIRB did in the past,

which maybe not has come to the table with the same opinion as you, they're doing something different that's an offshoot of Rails or a forked version of Rails that is better for an API. How could they come back into the fold? I think the funny part is that

the offshoot that we have is the Rails API project, which Yehuda and a bunch of others were involved in. That's probably going to be a large part of the foundation of it. There's some, I mean, I want to put a little bit of work into the serialization process project that they've been using. One of the points of disagreement has been JBuilder versus ActiveModel Serializers. Yep, ActiveModel Serializer. And I think there's value to both of them. JBuilder versus the serializers. Yep, ActiveModel and Serializer. And I think there's value to both of them. I think JBuilder is probably a better fit when API is just one of the things that you're doing

along with everything else. And then I think the serialization project makes a lot of sense when you're just building an API and you always want the same representation in all of your API setups. And it works very well for, let's say, something that Ember expects. So we'll figure that out. Again, there's no underlying fundamental philosophical differences here. And I think that that's the key realization that you have to make

to be able to have progress and stay in the same tent. That's great. So is that Rails 5 stuff, or is that beyond Rails 5? I'm hoping it's Rails 5. Yep. Awesome. What else is Rails 5? I saw on Twitter you're mentioning native WebSocket support. Yep. So I'm working on a bunch of new stuff for new ideas in Basecamp and a ton of stuff is spilling out from that. And I'm super duper excited about putting that into Rails 5. Rails 5, I think in in terms of breadth of features and what it's going to do, is going to be one of the biggest upgrades in Rails history.

And I think at RailsConf, I'll be ready to talk about that in more specifics because I'm really just in the depths of extraction right now, still trying everything out and figuring out. So it's a little premature to kind of announce anything in particular. Just to say that the things that I care about working on these days is the web application beyond the desktop. That making a desktop web experience

is just one facet today of any major application. And any major application needs to address mobile applications, native applications, and how can you do that in a way where you're most productive and having the most fun and so forth. And we've done a ton of work there now. And it's going to be great to be able to share that. I mean, I've already shared a bunch of sort of the fundamental ideas, which is the notion of the hybrid app, where you have a native shell that works on a lot of WebView HTML content that's being served straight from a Rails app.

And it's basically just third, fourth, and fifth generation of that stuff. And now, a word from our sponsor. Coding is sponsoring the show this week, and they want you to say goodbye to local hosts and code in the cloud with Coding. Coding provides free VMs, an attractive and functional IDE with multiple language support,

awesome shortcuts, and lots of color themes to choose from. Terma comes with full root, pseudo access, and public IPs if you need them. And you can develop in Go, Node, Ruby, Python, PHP, Java, C, C++, JavaScript, CoffeeScript, and more. Or you can even play with Docker, WordPress, Django, Laravel, or create Android, iOS, HTML5 apps, all for free and all in your browser. Coding is great for making your development environment crash-free

and functional on any device with a browser. Coding is also Chromebook-friendly. The Linux terminal and the Chromebook can finally be together at last. Terminal runs nicely inside your Chromebook, giving you the full power of coding on the go. VMs are robust and carry with them the dependability that Amazon's cloud infrastructure is known for, which means you can even run advanced tools like Docker. Join a 500,000 plus global developer community and sign up for free today at coding.com. That's K-O-D-I-N-G.com.

Once again, K-O-D-I-N-G.com. Once again, K-O-D-I-N-G.com. And now back to the show. RailsConf is April 20th and 23rd. Well, 21st through 23rd this year. So that's a couple months away. It's pretty close. It's not that far away. Yeah, it's pretty close.

But it's good because we're also just at that point now where it's not like Rails 5 is going to be released at that point. But it'll give me just enough time to collect my thoughts on the matters at hand and be able to present something cohesive. And I think a lot of people are going to be excited about it because I think, again, Rails or Basecamp is not a unique snowflake. Tons of other shops are hitting exactly the same problems. We want to serve the web, and it should be a great experience on a desktop and a browser, but that's not enough anymore. We have to deal with native applications and so on. And how do we do that without either ballooning our teams to have these mega departments

that just make native applications, or is there a different way that could work for a lot of applications? I absolutely believe that there's a different way. I mean, if we're looking at the timeline of the releases, 4.0 was out June 25th, 2013. So how far do you often do that? Do you look back at like, well, we've got to release a new major release every two and a half years, three years? Or do you just do it whenever it's sort of ready? It's funny because it's pretty much yesterday's weather.

We came up with the internal clock that says we should make a new point release every six months or so. And we should make a new major release every two years or so. And how did we come up with that? We did not just sit down and see which way to exactly guess it. We looked back at yesterday's weather and we realized, oh, that's how it's been turning out so far. It's been roughly two years between major releases and roughly six months between part releases.

So let's just make that the policy since that's what we're doing anyway. So that is thus the policy, which also means that Rails 5 is the next release. That is what Rails Master is pointing at right now. And it's turning out that that miraculously is a great fit now because we just have all this new stuff coming in. And on top of that, of course, Ruby 2.2 came out and Rails 5 is going to be a Ruby 2.2 plus exclusive. So Rails is going to do its part to bring along the Rails community to use the latest version of Ruby.

Does Basecamp track Master or is it sitting on 4.2? We have new developments for Basecamp that are tracking Master. Oh, okay. We'll see how that stuff plays out. You're invited back on the show whenever you want, David.

There's several offshoots of this conversation. I'm sure we could have gone down, but we've been trying the best we can to kind of cling to this 10-plus years of Rails. I mean, in 10-plus years, you've got so much to cover that we really had to restrain ourselves from going down too many rabbit holes. But you're welcome back on anytime, anytime you can make time to come back and talk through some of these offshoots. But one of the things I kind of wanted to talk through just real quick was just looking back at this 10 years. You've, you know, today, thank you for going through some of the,

either accidentally or in preparation for this call, you know, mentioning 3,800 people contributed to the core, you know, Core Rails framework. You talked about how many pull requests that have gone out there. There's still 419 open, but there was 12,000 pull request process that was in the preamble. We're going to try and somehow get out there as a, as an audio clip, but 12,000 pull requests. That's crazy. We talked about the behind that one specific thing that I think, um, I want to ask you before we go into a couple of closing questions, and I think it's because you share so much wisdom because of this 10 years, 10 plus years, is you mentioned Node. You mentioned IOJS earlier.

We recently had Michael Rogers on who heads up IOJS among many other people we've invited Scott Hammond on from Node the CEO of Node to come on this show and talk about yeah sorry joint not Node my bad you know what I'm talking about but we've invited him on the show to come on and talk about the Node foundation what that's going to be like but what advice can you give that community as it relates to what you've learned from the Rails and Merge and just in general this past 10 years when it comes to community and division and opposition and good competition? As you mentioned, Sinatra is not exactly a competitor, but it's a good – you know what you said earlier. Alternative. You know what I'm talking about.

Alternative. So what advice can you share to that community before we close into a couple other questions we have for you? First of all, good luck. I think it's incredibly tough. I mean, even just the – or sort of the, I don't know, spat we had, perhaps you could call it, at the height of the Mervyn Rails stuff, it was tough. And that was a very, that included, I mean, yeah, there were two communities somewhat, but the core actors in the thing, it was a very small group of people.

And yet it was still very hard. There was only one company involved, Indian Yard. Like on the Rails side, there was no specific company. It was just the Rails core group. And that was still so hard and it almost didn't happen. So to think like just the amount of sort of corporate enterprise-y stakes that have been placed in the Node camp. I mean, I cannot even imagine the complexity of that. It's kind of like trying to peace broker, like, oh, let's have universal peace across Africa. Let's invite all the sort of countries, sit down at the table, and we'll figure it out. I mean, damn, good luck. That is,

it's a very hard problem. I'll say somebody deserves the Nobel Peace Prize if they can bring that split back together. I don't think it's going to happen. So good luck is what you're saying. So you're predicting potentially that IO and Node will continue to be forked? I think that that is the most likely outcome, yes. And again, I don't have any particular insight into any of the organizations short of observations of the, I mean, I got to laugh just a little bit when the press release, I think it was for the Node Foundation came out and you got

like, oh yeah, this is like Microsoft and PayPal and IBM. And I don't know, it was a prudential or some financial institution or something. And I just go like, can you imagine sitting down for a meeting with that level of stakeholder enterprisiness and just go like, Jesus Christ, anyone who can sit through that is a more veteran person. Diplomat. Yeah. That is what I want. That was the word I was looking for, is a better diplomat than I would ever be. I mean, it just seems like such a hard intractable problem. And I just don't see where the solution is going to come from in that. But that also is not the end of the world.

Obviously, Node and I.O., they have great momentum. I think it's not a technology problem. It's a community problem they're dealing with, not so much a technology problem. Oh, absolutely. Absolutely. It's about, as you said earlier, you slapped yourself and you said, I want, and it's really about desires. Both camps have different desires, and both camps have different places where the money is coming from, which sort of – So let me ask you this one quick question and summarize that.

So your advice is plain old good luck. Well, that's not really advice, is it? Well, I'm not saying that's your response. My advice is that there is not much I can offer to this. You're going to be more likely to get advice out of a UN diplomatic envoy or something and how they've dealt with the intractable problems of world peace than you are with getting it out from my experiences. They're just not even at the same scale. You're not really giving advice. You're just sort of, you're sort of, meh, I can't really give much.

Commenting. Yeah. Okay. It's accepting the limitations of my abilities and my abilities to solve a problem at that epic scale are truly limited. And it's kind of like saying, hey, you once broke up a schoolyard bully fight. Could you help out with the Palestinians and the Jews in Israel? Like they could really use some mediation.

Like I'm just not qualified at all to deal with that level of mediation. Well, let's talk about some things you are qualified. We got two core topics real quick. I don't think it should be long at all to deal with that level of mediation. Well, let's talk about some things you are qualified. We got two core topics real quick. I don't think they should be long at all. Let's keep them as short as we can because we're really getting basically we're coming close to being over time. But two things we can't leave this conversation without talking about, which is getting paid to work on open source since Rails has got so much breadth.

And we just talked about, you know, node and enterprise level, money being involved, things like that. You've put out a couple of tweets recently that, you know, I kind of knew where you stood, but you've got a clear opinion on getting paid to work on open source full time. The fact that, you know, I'm just pulling some quotes from recent tweets from you, so they're your own words. But Rails is obligation-free software, something you've said before.

You don't owe me anything to use Rails, and I don't owe you anything to use Rails. And you've had a couple conversations recently, but you've got a clear opinion on getting paid to work on open source. Can you kind of summarize how that's played out for Rails? Sure. So first of all, my opinions stem from observing open source software largely within the web community. Some of the opinions that I have do not extend to other domains of software, do not extend to other aspects of software even.

Some aspects of software and some domains of software actually work quite well with people being paid on open source. I pull out security bounties as one example that have worked quite well. Paying people to find vulnerabilities in your software is an area where if you did not pay those people, those vulnerabilities often would not be found. You're not taking something away that otherwise would have happened. I think a lot of where I went sour on paid open source was watching much of the consulting business that sprung out up around certain, particularly

JavaScript frameworks and the complexity that came with that. And seeing what happened to API design when the API designers were removed from working on things themselves and were only working on them by proxy, that they were either just helping out clients or whatever, but they did not have long-term stakes in particular applications. And I did not like what I saw. And on top of that, I've been heavily influenced by a variety of research on sort of rewards. There's a great book called Punished by Rewards by Cohen that deals with what happens to intrinsic motivation once you introduce extrinsic benefits, sticks and carrots. And the answer is, it is not pretty. That oftentimes money does corrupt things. It also facilitates things and it also has upsides. But being blind to the

downsides and being blind to what it does to intrinsic motivation, that's not going to do you any good either. In certain domains, again, as I said, it doesn't matter, right? If somebody's finding a security hole, do you really care whether they were intrinsically motivated or extrinsically motivated? Perhaps not. If you care about keeping a framework like Rails going for 10 plus years and not turning into consulting ware, you do care. I care.

And that's why for all this time, we've rejected thoroughly that Rails was going to be driven by professional open source. Again, that doesn't mean we can't have and get value from some aspects of professional open source. And professional open source, I mean, people who just work on open source.

We do have people. Getting paid full time to work on it. I mean, Aaron Patterson, Tenderlove, has been paid to work on open source software for quite a while. And Rails is so much better because he is helping us and being part of it, not just helping. He's an integral part of Rails today, right? So that's good.

I mean, with all respects to Aaron, I don't think Rails would be the Rails it is today if the core group consisted entirely of professional open sourcers. I think that there are certain aspects of the professional open sourceness that work really well. And Aaron has done a superb job at improving implementation. Right. Making things more efficient, making them better, making them clearer on the internal side of things. Dealing with API design, which is a large part and perhaps the majority part of what makes Rails Rails, the DNA of Rails is the API design. That is an aspect I feel fares quite poorly in a professional open source context where somebody is being paid full time to work on it. What changes when you're being paid and you're with your API design just because you have

to answer to somebody or? There's that. There's the fact that you get removed from sort of extracting problems. You're not extracting your own problems anymore. You're doing things on behalf of others. You're not extracting your own problems anymore. You're doing things on behalf of others. You're isolated. Well, I don't know if you're isolated, but it's just, it's different to... Motivations change. Motivations change, but even the specific of the design changes. When you're making APIs where you're imagining what somebody somewhere might want to use, very different than

when you're extracting what you actually did use and what you actually did need for that particular application. So that's where those things are. And the other thing too is, it's a continuum. I'd actually say the majority, actually not the majority, all of the people who work in Rails core, they are professional open sources to some extent in the sense that they're being paid by their company to also put contributions into Rails, at least some of the time. So it's not this hard line. I think it's just, there's a place at the continuum where it tips, where you have too many people who are being paid to work on the open source on behalf of other people instead of doing their own extractions from their own work. And that's where things, in my opinion, tend to go.

You're really calling for balance. Well, I am. I am calling for balance. And I think that that's also, this is the nuance we can discuss when we don't have to boil things down into 140 characters. Yeah, exactly. That's the one. I mean, the two flip sides is sort of what happens to API design when you're being paid to work on behalf of somebody

versus when you're working on your own stuff and extracting it. And then secondarily, what happens to motivations, particularly around, that's not so much the full-time dilemma, I think, as it is a dilemma of kickstarters and fundraising for individual projects and sort of what that does. And Cohen's book is a great place to start for anyone who wants to look into sort of the psychology of that. I found the link for that. So we'll, if you're listening, we're going to put that in the show notes. So just, you know, camp out at the show notes. This is episode one 45. Um,

so go to the channel.com slash one 45. I'll find show notes there. If not already in your podcast listener catcher thingy or whatever you're listening to it. And, um, David, one more, one last question. I would've had you for so long. We appreciate you taking the time to, I mean, again, 10 plus years, you can't cover it quickly. So it's kind of, don't want to apologize too much, but you know what you were in for. The one thing I want to clarify here, and I'm really glad this question came up today, because this is what I wanted to clarify before we close the conversation, which was to reinvigorate the community listening on leadership around Rails. And the question came to you

just haphazardly today, three hours ago, someone said, I remember running Rails 1.3 in production. You know, so many hands had done good and bad in Rails and it badly needs leadership again. And your response was, I think Rails has never been in a better position regarding code, community, and leadership,

broader and more engaged than ever. So can you expand on that 140 that you had to condense it down to with regards to the leadership around Rails? Sure. I think the group that we have, both the core group, but more importantly, the contributors group, the people who are invested and engaged and interested in working on Rails for more than just a single issue is richer, more diverse, broader, and more skilled than it's ever been. I mean, when I look at the contributors channel, when I look at the activity that we have on the pull requests, when I look at

the stats we have for processing pull requests, and finally, when I look at the result of the Rails framework that I am so happy to get to use almost every day, it's just unescapable that it's never been better. Of course, that's my opinion. Somebody can have a different opinion. But I would be the first, I guarantee you, to land bast if that was not the case, that if I thought that things were heading in the wrong direction.

Rails doesn't owe me anything. If I thought Rails was, as one famous blog post put it in, I think, 2007, a ghetto, I'd just get the hell out of Dodge. I mean, I don't need to continue to work on Rails. I continue to work on rails only because I enjoy it. And I enjoy it in very large parts because of that community, because of that leadership group. And leadership group is even, that's not even that interesting to me. It's the collaboration group that's interesting to me. You can have a strong leadership group, but if nobody wants to work with you, what are you leading? If you're all chiefs and no Indians, then you're not going anywhere.

And that's not even a good division right here because good ideas are good ideas regardless of where they come from. And what I see just is I see more good ideas flowing into Rails than ever have. And that's why it was so shocking to me, actually, to see just the magnitude of that. When we look at those 12,000 pull requests, right? When we look at the almost 4,000 contributors, that is just an avalanche of good ideas. And I am incredibly thankful still to be able to partake in.

And I also think that we've just learned a lot over those 10 years that we have a much better process these days for having somebody show up at the store and say, huh, I kind of like how this looks. How can I help? Like that path today is much better than it's ever been. What led to MER was, I think, in large part because that path was not clear at all. It was not illuminated. You could find it if you had a manchetti and you were willing to cut through the jungle. Today, it's a freaking highway, right? You just drive on it and then you just keep on driving and things just get better and better. And I think you see that when you also look at

the number of new contributors that continue to flow into Rails. The pull requests are not just being opened by the same people. It's not the same group of 4,000 people. We have every single month, if not week, we have new people who show up with their first pull request and say, hey, hey guys, what can we do here? How can we work together? And that's great. And I think the process has just gotten so much clearer over the years and we've ironed out so many of the bugs in that. It's friction of contribution is way, way down, which means that the flow of ideas is way, way up. Awesome, David. Well, we can probably keep you on the line all afternoon and just keep going down these different rabbit holes.

I know I could, but we're going to let you go with one closing question. We asked this to all of our guests. In fact, I think a few past guests probably named you as their programming hero. So it'd be interesting to hear what you say here. If you got one person or if you got a couple, that's fine as well, that you look up to in the community, who's your programming hero? Sure. I definitely have to mention more than one.

I'd go back to those early days, 2003, who were my main influences. And I'd say it's Ward Cunningham, Kent Beck, Martin Fowler, Dave Thomas. That's probably a good group, just sort of rattling off off the top of my head of people who really left a very large impression on my work. And I am ever grateful to have learned from and still be learning from these great programming heroes. And it's satisfying, very satisfying for me to see that all of them are still kicking hard and pushing out great ideas that I continue to be provoked, inspired, and motivated by. Well, David, we, like I said, we definitely appreciate you taking so much time out of your Friday, close to drinking time. Well, I guess if you're in Malibu, it's not drinking time yet for you, but maybe, who knows, you might've been having some wine during this call, but. I had a kombucha just before we got on, so. There you go.

Yeah, we definitely appreciate you taking so much time. I mean, 10 plus years of Rails, congratulations to you and everyone who's been a part of Rails, both as someone who's used to build applications, as someone who's contributed back to the companies that sponsored people, being involved in that community. What a great legacy there is here. I'm sure we're all excited about your talk at RailsConf here in April and Rails 5 coming up and all the stuff we've got to talk about today. But thanks again for so much you've put into it too and just the time you've taken to come on the show today. Is there anything you want to close with just on your side by any means, like how people can find you, how people can follow you if they don't know or anything you want to mention on the closing? Sure. So first of all, I'd say I wouldn't have been doing any of this work

if it hadn't been for my pleasure. And it certainly has been and it continues to be. I continue to be involved in Rails because of enjoying it, not because of obligation, not because defending some legacy or something else, simply because I'm having a lot of fun

and I'm enjoying myself a bunch. If you want to follow me, I guess, Twitter, at DHH, will flood your timeline with all sorts of opinions on both matters of tech and politics. So I think there's probably even people who've heard me on some tech podcast who then started following DHH and thought,

hey, whoa, whoa, whoa, I did not sign up for your opinions on national security or whatever. Higher beware. Exactly. Fair warning given if you choose to do so. But that is the main place. And, of course, Signal vs. Noise. Signal vs. Noise is where I continue to walk about new techniques and so on.

And it's signalsbnoise.com. And finally, my own personal website is david.heinemeyerhansen.com, which you can probably not spell. So better click the link in whatever notes accompany this podcast. We'll definitely link out to that for sure. We'll link out to your... Are you also DHH on GitHub, or did you have to do something else for that?

Nope, I am DHH on GitHub, but yeah, I guess that's a good place to follow me to. Mostly with Browse Commits, obviously. As GitHub makes the personal timeline of the YouFollow better and better over the years,

it'll be more rewarding to follow you and see what you're commenting on and all that good stuff. Well, David, again, thank you so much. And to all the listeners, thank you for tuning in for such a long show. It was a pleasure to have David on. I know 10-plus years is a long road to go down, but thanks for keeping up this whole show. And with that, let's say goodbye, everybody.

Bye. Bye. Thanks for having me. I'm out.