David is the creator of Ruby on Rails. We discuss "batteries-included" web frameworks, maintaining an open source community, versioning, upgrades, and falling in love with a programming language.
Will Vincent 0:06
Hello, and welcome to another episode of Django chat weekly podcast on the Django web framework. I'm Will Vincent joined as always by Carlton Gibson. Hi, Carlton Halliwell. And this week, we have a very special guest, David hen. Mr. Hansen, who's the creator of Ruby on Rails, co founder, Basecamp, author, prolific Tweeter, and lots of other things. We're very happy to have you on. Thanks for joining. Thanks for having me. And thanks for coming on. So we're actually at Django calm, or Django con right now. And so there's always discussions about maintaining and operating Django and I wonder if you could speak to how you organize rails because I know there's rails comp and you spoke this year, I thought it'd be great to talk about the similarities and differences there. Carlton is a Django fellow. So he's one of two people paid to work on Django, but it's really seems much more community based, whereas I know there's a large rails community but you still are the figurehead, at least. So I wonder if we could talk about that and the pros and cons of those approaches. Sure.
David Heinemeier Hansson 1:01
So in the rails world, rails comm is put on by Ruby Central, which is the longest running organizing group behind Ruby, which even predates rails itself. It was Ruby Central, I believe, that put on the original Ruby comps. This started back in like 2001. So almost 20 years of history there for Central. And for a while when rails was just taking off, or Riley did the conferences, and they kind of did their whole thing. And then at one point, they decided that they didn't want to be in the business of doing these kinds of conferences anymore. And Ruby central stepped up and took over the organization of the conferences. And it's been doing a phenomenal job ever since. And I'm really I mean, when you say I'm the figurehead, I think, in a very literal sense that make sense as a figurehead being someone who doesn't have to have any authority is just here. As an avatar, because I don't actually have anything to do with the organization of rails comm for entities or Ruby comm for that matter, or any of these other things, I just show up, and I speak for an hour and hang out with a bunch of people and have a good time. But there's, as you say, there's a very broad and deep community around Ruby on Rails that functions entirely on its own, no influence whatsoever from me, thank God. And I think that that's how it should be. I think one of the funny things about rails and Ruby is the fact that there's such a overlap, whereas most other languages have a little bit more of sort of, I don't know competition amongst web frameworks. Django is a is a big heavyweight in the Python world, but there's also a lot of other choices that are prominent versus with rails, particularly at this sort of full stack scale. There aren't a lot of other problems. It choices there are other things at different scale like Sinatra is a sort of micro framework that's popular, but which is just sort of a funny thing. If you think I'd actually argue in some cases as a bad thing, I'm not generally a fan of monopolies or any of that to a, it can lead to sort of a closed echo chamber, mirror that that's not good for anyone. So I'm actually surprised how well it's working out. But maybe I would say that right as the quote unquote, figurehead, and you should ask someone else in the Ruby community. But
Carlton Gibson 3:38
yeah, you'll, you'll still very much still. In Django. We used to have the benevolent dictators who were the founders and they'd rarely but you're still very much in that role for rails. Yes,
David Heinemeier Hansson 3:48
for the Rails framework.
It's funny, like, I don't know where the benevolent dictator thing came from, but it's got a weird sound to it that I don't know. associated with or whatever. I'm remark or reflecting on the fact that, like, I, I wouldn't really want to have that title and I don't think I do either. I like, sort of if you were to use a film metaphor, something like a director, right? Like you don't do any everything in the movie, there's someone who does editing, there's someone who does the release, or someone does all sorts of different things. But when it comes to like, how should this scene looked? Yeah, the director has a outsized influence on that. And I like to think that that's sort of what I provide for rails, and particularly around the design of the API's. I mean, if you were to look at the rails code base, I don't even know how big it is these days, but it's certainly not 1000 lines of code, which was what we originally or what I originally launched with, it was literally 1000 lines of code when the framework was released in 2004. It's not that anymore. It's, I don't know, 50,000 lines of code 70,000 lines, I have no idea right. The vast majority of that code is not written by me the vast majority of that code code is not reviewed by me. I don't know what the vast majority of that code does in sort of a per line basis. What I do know and what I do care about is how the API feels, how the integrity of the framework sort of feels cohesive, that there is some thought behind how all the pieces fit together. And that's the part I continue to be very much involved with, and very much involved with designing new API's. As new frameworks come out. We keep putting new frameworks into rails. I don't even know what the count is now. But I think we're up to like seven or eight or nine major frameworks within rails itself. And whenever we do a new framework, I'm usually intimately involved with the API design. And in some cases, also actually writing the framework, the last couple of frameworks, we put into active storage, I wrote a fair amount of that
action text that was involved with that. So
that's, that's sort of sort of the role and then I continue just to be a big fan of rails because I continue to use Use rails, I use rails in all of my daily work, right? So I get to use all the stuff that I make myself around. And then I get to use all the wonderful stuff that other people make for rails and just as a user of a language and a framework, that's just an incredible, fortunate position to be in, like 1516 years into this thing.
Carlton Gibson 6:21
Yeah. So I want to ask you, you still excited about it, you're still there. And, you know, you feel it in your mouth. You're like, yeah, I want this.
David Heinemeier Hansson 6:28
That's a great metaphor for feeling in your mouth like that. Just a taste of it. And I'm just coming back from three weeks of parental leave, in which I barely touched a computer, beyond perhaps my phone and tweeting too much. But I didn't touch my iMac. And I didn't touch code for all that time. And I just sat down yesterday, opened up textmate to and created to pull requests for the latest project we're working on at Basecamp in Rails, and I was like, holy shit, this just feels so great. Like this act of of programming making things. It's just as fun now as it was 20 years ago, or whenever I, I got started with it and using rails, using all the elements of it and tasting those elements. One of the things I always, or brings a smile to my faces, I'll come back to an editor after having not programmed for a while maybe that's just a couple of days, maybe it's a week, maybe it's in this case, it's three weeks. And I see the rendering of how textmate renders, like a controller or a model with just the right syntax highlighting and it just it's a smile moment. You just go like, yeah, this is good, man. I'm happy to be back.
Will Vincent 7:36
Well, that's the attitude to have. It's one thing I'm struck by is people often, so I I teach Django for a living. I've written some books and beginners often look at Django and Rails is competing, when in practice, they really are share so much in common. And one thing I'm struck by is the fact that there aren't more batteries included frameworks right now. It's really Django rails. There's a couple other ones but I wonder if you have thoughts on why aren't there more you Why isn't there another? Is it just because it becomes monopolistic? We're all the minds attached to one in a given language. You know, so for example, Django is adding now async support. That's a big thing, partly to do with. So we can say, Well, why use node? It's like we could use node, but now we're building it into Django just as it's built into Python. I just curious, your thoughts on why why aren't there more batteries included frameworks out there? It seems like there should be more than two default options. In 2019.
David Heinemeier Hansson 8:28
I think part of it is that batteries included was always a heretical opinion. And it just happened to be this weird moment in time where both Django and rails took off despite the fact that my belief is that the majority of programmers character orientation is against that. They don't want batteries included. They want to tinker and tailor and specify and be a unique snowflake who puts together just their little bespoke unit of things. And that as soon as there was another, quote unquote, modern or popular hip alternative that wasn't batteries included, most people reverted to that primal stage. And I think that that is unfortunate, I think. But I think it also just represents just how deep the Unix philosophy flourishes in most people, this idea of independent tools that work together because you put them together. And actually, we don't really like if anyone puts our Legos too much together, we like just a big box of small pieces that we can tailor and put together and that's where we find enjoyment as programmers Now, that's not me at all. I'm just sort of presenting this this viewpoint, right because I believe the opposite. I believe that wasting your time clicking together to the same damn two by two blocks over and over and over again is an other waste of time that I very much don't want to waste my time on right, I want to put together 16 by 1664 by 64, blocks, huge blocks of integrated, essentially wisdom. Yeah. In the most authentic sense of that word, knowledge captured hard won over time, because people kept doing the same things. And we just, we learn all that stuff. And we packaged it up, and then we leveled up and built on top of it. But yeah, I continue to think that that is not how most programmers come to think they have to be converted. Okay. Yeah, for a while. We were really good at converting people both with Django and with rails, but it just it didn't. We were cutting against the grain.
Carlton Gibson 10:40
Do you think it's an education effort?
David Heinemeier Hansson 10:42
Like it's, you know, no, no, actually not. I don't think it's education. Education implies that someone just doesn't know that if just they're taught, like if they get the information, that then they will be converted. I think it's valuable. I think we are in opposition to the values that most programmers are Born with, well not born, I mean, that is a, as they become programmers, they adopt a certain stance, a certain orientation towards the world. And for most programmers, I think that orientation is at that low level that we like putting these blocks together. And we're inherently skeptical of big constellations of things that go together.
Will Vincent 11:20
It's also there's a discipline to it. When you say, I mean, for example, we've, you know, when do you folks are at a company and certain size and they need something, and Django doesn't have it yet. And so once they break out of the mold of Django, and build something custom or use flask for one thing, then they've kind of opened Pandora's box. And now they're behind Django, because Django has updates now every nine months, and sort of like once they jump off, they find it hard to come back in. So I see it almost as a discipline question and sort of medium large companies, which I have started long ago till recently. Yeah, I
David Heinemeier Hansson 11:50
think that it's funny in the rails world, GitHub, more so than anyone else probably represented, what you were talking about for a very long time. I think for Maybe 567 years I sort of not entirely sure on the timeline, they were stuck on like rails two, three, a version that was released in 2009, I think or 2008, because they had all these little tweaks, GitHub fell into the same trap that almost any growing company falls into, which is to think that their special is that their needs are so unique and so custom and so bespoke that only they and their programmers can solve for them. And it took a very concerted effort over several years by some rails core members who kind of infiltrated that ideology and then busted it up for rails for GitHub to come back on rails. And now you have a situation where two of the biggest Rails applications GitHub and Shopify, they're running not just the latest rails, they're running like on rails master. Sometimes they're further ahead on keeping up with the latest changes, then even Basecamp base and base camp has been more or less running on master for like 15 plus years. But there was a time where both of those very large applications both are companies like, I don't know how many work at GitHub now, I think it's like a few thousand years or something. And at Shopify, it's it's many thousands, that they fell into that trap of thinking that they were so special. And then sort of through various happenstance has got back on the gospel, so to speak, that they aren't that special, and that the things that they come up with, they can benefit in everyone. And we can work together as a community by sharing the things that we develop, that seemed custom to us, and that we're better off for it.
And I think that requires,
again, the word of discipline, I think it's there's two edges to it. There's one the discipline of sort of like, Well, I know that working out is good for me, I just can't get myself down into gym. Like that's a sort of a guilty discipline that if I just sort of get myself together and wake up a little earlier, I'll do it. Then there's the discipline of basically imposing a set of values on an organization, at the discipline of like, we will all march in the same direction here, we're not going to go in 15 different directions. Even if you think that your direction is great for your little thing that you just want to do a microservices over here, and we're going to do it then this bespoke little thing. And before you know it, you have 47 of those run in all sorts of different languages. And people come and go as they do, particularly large organizations. And now you just have an utter mess on your hand. Right? So the discipline of keeping and whole organization technically, on a coherent track. I think that discipline is indeed very hard. And you'll see organizations kind of drift in and out of that discipline. Much determined on like, Who's there at the time, that speaking of discipline as an organization is very much about influential individuals at the right moment at the right time. GitHub for a while had some very influential people. Who were more in the like, we are bespoke and unique. And let's do our own forks. And we can't share this. And now they have a different discipline by a different set of people who go like, I don't think that was true. Like we can give back, we can be part of the community, we can run on the latest rails, we can make it such that both GitHub and in many cases, Shopify, their vanilla Rails apps, which is again, one of those ideas that just bounces straight off the normal character orientation of most programmers, this idea that Manila is actually bad, right? That you're not really worth it. You're not working at Internet scale, you're not doing something groundbreaking, a modern unless you break out of vanilla, unless you break out of just the standard tooling that every programmer who goes through what a coding school knows how to use, like that's clearly not good enough for us. So I see that very much at this value. struggle between having enough confidence in your own competence to believe that my competence is not defined by the exoticness of my stack. My competence is very much defined by the outcomes of where I can take that stack. And in fact, I would even argue that there's an inverse relationship, you the more, you can use a Manila stack at a greater scale, the higher your call, and the further you can
Carlton Gibson 16:24
push it, the bigger the product you can build because you're not you barely building the product not working on the stack.
Will Vincent 16:30
I'm curious, we compare and contrast versions and so rails your you just released or rails just released version six. So in Django were on. It took a long time to get to 1.0. And then it went all the way to 111. Then 2.0 run 2.2 now and 3.0 comes out this December. I wonder how how do you think about or how does rails think about the versioning? Because I know, like what makes six versus five different versus a micro release. I mean, for Django, we're sort of saying that async is What makes it 3.0. But you could also argue it's sort of a 2.3. And we're just switching to 3.0. I'm curious how you all think about that.
David Heinemeier Hansson 17:08
That versioning is probably one of the clearest implementation of post modernism. Everything can mean everything, and there is no truth there is just relative perspectives. And this is one of the reasons why for a long time, I've been on this horse basically saying that sandbars bullshit, at least as a declarative notion of sort of distinct cutoff points, because every feature is a regression, there's someone somewhere, and every change and every conflict update and so on. Again, that doesn't mean that there isn't something to the spirit that you shouldn't willy nilly be breaking big things between minor versions, but I have simply come to embrace that. version number ending versioning is marketing. It's a way to communicate with your country. unity with your users with prospective users, what's going on and what's worth paying attention to? When we smack a label of rails 6.0 on something, it's because we say, hey, there's some major new shit here that you might want to check out. There's nothing like new, they'll draw people in to take a second look. And rails six oh, includes a bunch of new frameworks and includes a bunch of major upgrades. All of them are actually backwards compatible, right? You could have called that rails five, three, there's nothing breaking in any of the individual headline features that we have. We've been chosen to break some things because we just wanted to update things like that's usually what we use the big version number as a permission for like this is now we can sort of break things we barely really do anymore. We used to now we've come up with a better approach, which is basically saying any new app you start on rails six will get rails six defaults. And then the app, you bring into rail six that we're From before that time will keep its own defaults. So we essentially end up not breaking things even when we want to change things. So one of the things I'm a big believer in, is moving forward. And if you swear too much by backwards compatibility, you're going to stop moving forward, or you're going to end up painting yourself into a corner, because you're trying to keep backwards compatibility with something that happened seven or eight years ago, which when I think of my programming ideas of seven or eight years ago, yeah, there's some of them are still valid, and some of them are total bullshit and should be changed. And I want to have the power to change that if I have to be locked into 15 years of bad decisions until the end of my time working on Ruby on Rails. Well, that time will come up sooner rather than later. Because I don't want to be bound by my ideas from 15 years ago, if they're no longer good, like, a bunch of them are decent, good enough. still works. I liked them. Let's keep those and then let's change the ones where we got better information or we became wiser. This whole idea of packaging of wisdom. Integrated frameworks and so on only works if you give yourself a license to use that wisdom. So that's what we're trying to do with the versioning in rails that we give these marketing signal. Yeah. Things that says REL six oh, which in itself is such a, I get it right. Like I get it, you're not involved with the development of a framework. You don't really know where the cutoff is. But I've been running rails six for like six months in advance of the actual release, what happens on the actual release? Does the software go from like, totally shitty to totally functional? Of course it doesn't. There's just given commit that we say, Yeah, that'd be it. That'd be the sixth. Oh, there's still plenty of bugs, and there's some bugs that have been fixed. So I think it's a mistake to ascribe too much technical importance to version numbering. To me, it's a communication tool. Interesting. Well,
Will Vincent 20:55
Django has this long term support theory which actually may be called if you want Talk about that, because there's a big issue with Python two is no longer getting support and 2020. And the new versions of Django don't support Python two, but there's still a lot of people on Python two, as well as older versions of Django. But do you want to explain the LTS? Carl? Yeah, so we have that cycle where we have the LTS
Carlton Gibson 21:18
C, I guess simply because back in the day Django was, was more flexible, you know, things didn't change what you just said about how not rails six doesn't really break anything from rails five. That's kind of where we're at with Django now is we don't break. You know, we do change things. We update things, we get rid of the Crafty stuff, because otherwise the framework would die. But we do it in a way which is measured and managed and we give good deprecation notices and all these things, so it's really easy to upgrade. But people back in the day, that wasn't the case. And they needed something more stable. So we had the LTS. Now Actually, my view in the LTS is we should you don't need it anymore. You should be on the latest version, because that's the happy place and you can do it and it's easy to upgrade. But still we keep the LTS because there's companies that On the note on that,
Will Vincent 22:03
I would say most companies follow the LTS. Yeah, in practice,
Carlton Gibson 22:06
I wish we could communicate how that's that's no longer necessary. But you were that Python two to three years. That's another story. I don't know what to say. They're like, that's gonna be difficult and companies are just gonna have to bite the bullet and do it. But like
Will Vincent 22:19
Django water coming storm in our, in our world, I mean, because a lot of companies are not are behind the eight ball on it and don't see the noise. There's
David Heinemeier Hansson 22:28
Yeah, I don't I don't envy that situation. I think the closest we had was Ruby 186219. There was some change very minor in comparison around something with strings that took a bit of a community push to get upgraded on. Thankfully, it happened pretty early in the evolution of everything. rails hadn't really taken off at that point, I think. And now, Ruby is, is even more conservative. I mean, as it probably should be as a language but it's very conservative. As the language and basically hasn't changed, there's been hasn't been any issues for people upgrading for many, many years. And at this point, we basically, we pin like one version back when we release a new version of rails. I think rails six depends on Ruby to five. But it's been a very long time since I can remember any drama about upgrading a Ruby version like, so Ruby, two, six comes out, and we just say, yeah, now you got to use that because there really isn't an issue with it. Generally, for most people, most the time. It's the Python two to three thing is, it's a little painful to watch from the outside. Perhaps it's painful to be inside. But at least there's something there, right? Like, what was it Perl five to six where six took like, what, 15 years or something to come out at least there's not an you're not in that situation. Like there's something out it's been out for 10 years. I mean,
Carlton Gibson 23:49
if you're on Python three, it's you know, Python 3.4 to 3.5 to 3.6. It's very smooth. It's just this one jump. It's an right
David Heinemeier Hansson 24:00
I think that's also part of one of those things where you were just saying, like, the monopoly that rails to some extent endures as the batteries included framework. And really web framework in general in Ruby allows us to move at a different speed sometimes than a language that has like a lot of very diverse views and very diverse packaging and installations and so on where it isn't so easy just to upgrade Ruby, in that sense, I think has benefited from a maintenance perspective of just having a smaller constituency and having a tighter constituency in terms of the diversity of people using by the time that rails, for example, said like, okay, rails requires Ruby to or whatever it was right. Most of the Ruby world moves along like that, that is some of the gravitational pull that we have. And sometimes that's a bad thing, right? Like it can be a gravitational pull for new ideas or alternative approaches, but the gravitation pool for, for example, moving the Ruby community forward, I think in large, decrease have worked out quite well. And does that you think that comes from rails Rails is the pulling engine? Is that for Ruby? Is that the case? Or did there's a fair amount of that? I mean, it's hard for me to talk about it, because obviously, I see mostly the good ends of that. And I know that there are other people in the Ruby community, perhaps less these days, but more so in the early days, we saw the negative effects of that, that like, hey, there's an outsized gravitational pull here of a single framework that's pulling the language forward with it in these certain ways. But I think when we can use that gravitational pull for good is that we can basically drag everyone to the latest version of Ruby with very little effort. And at the time where there were these issues, like we had the 186219 transition that had something about strings, I also think it was something about UTF eight I blissfully erasable memory. We have that same thing where we said like all Rails is now supporting it. So if your gem doesn't work with the latest version of Ruby, it doesn't work with rails. Right? So, I mean, yeah, you can just leave it as it is. Or you can fucking update your shit, right? Like there was really a very strong pool and there wasn't so much perhaps we were also lucky. Or perhaps it was a time of a smaller community and a tighter knit community that there wasn't a large disagreement, at least from the outside. When I look at the Python world, there's some people who were very affectionate about Python to believe that three perhaps wasn't the right way to go or the right way to go about it or blah, blah, blah, versus there wasn't a lot of that in the Ruby and Rails world. Yeah.
Will Vincent 26:40
Interest related to Python three. I'm curious how you think about async? Because obviously, that's Django 3.0. That's sort of the marketing angle of what's changed, I believe. I mean, I know you have active jobs, right for background async tasks, but Ruby doesn't have a sync built in, right. I'm just curious, your thoughts on do people ask you to make rails async? And is that even possible?
David Heinemeier Hansson 27:00
Yes, so first of all, rails has been thread safe for a long time. Now it used to not be it used to not be thread safe and everything was process based and the prominent web servers were all process based. Now we ship with the default Puma as the web server. It's all running on threads. It's all sort of thread safe. And it's just not a thing I think about now in terms of async. And pushing things out of the main queue, for example, you want to send an email as a response to an update or something. We built that in with with sort of jobs way of doing it. And we've built it into such a place that most people don't even notice the action mailer setup in Rails, when you trigger an email, by default, it's just async. By default, that just gets stuck on a queue. It just gets sent out of out of order, like you never hang up a response to deal with that. So in that sense, I mean, we've been kind of a sink for a long time. It hasn't been a big deal. Like it's not a area of discussion really like, performance is always an area of discussion, but usually by people who are not using Ruby or rails, usually it's a spectator sport to some degree. Well, I mean, I've seen that go benchmarks, whatever hello world like 100 times faster and I'm like, Oh, okay. Yeah. Like it has no relevance to my work, as I am fond of saying. Ruby was fast enough for me 15 years ago on a shoestring budget to launch 100 million dollar business. Same with Shopify, right, like a $42 billion business was launched on a Ruby that was good enough in 2004. I mean, that's not to completely poopoo the idea of performance and I always love getting free performance. Ruby has been really steadily eked out like a couple of percent improvement every new release, and they have these, this idea that Ruby three was going to be three times faster than Ruby two, the three by three And I'm like, Oh, great. Like, that's nice. Like, I'm like, oh, some free candy. Okay, I'll take a few. Like it's not something that really occupies my life in any meaningful way. And performance. With languages like Ruby, and I'm sure Python as well, it's just it's not within my area of work to really worry about it when I worry about performance is because we, we did a bad algorithm, essentially, right, like we programmed did wrong. We forgot caching, we did something else, right. Like it's never Oh, Ruby can't compute fast enough. That's just not a thing that that we, that we worry about.
Will Vincent 29:41
Yeah. But just switch gears slightly. I'm curious. Could you talk about how rails core works? Because certainly in the Django world, there's there's a big effort to have the core team, such as it is, reflect the community which is much more diverse in the core contributors. So I'm curious how, how do you how does rails think about that? Because Cuz, I mean, we're at Django con. So kind of everyone here sort of gets it. But we still have this challenge of I mean, Carleton, you mean you do this every day? What is it? It's a half dozen a dozen people do a huge amount of work. And then it's a really long tail of Yeah,
Carlton Gibson 30:13
I mean, they're they're exactly half a dozen, maybe a dozen call people who are really busy act actively contributing, they do 80% 90% of the work. And then yet, you know, 200 300 contributors who make him want to pull requests over the release cycle.
Will Vincent 30:28
So there's talk of dissolving Django core developers in terms of it's an ongoing discussion of trying to have them both make it more more inviting to new to beginner contributors, you know, to make it not seem like this.
Carlton Gibson 30:44
This this ivory tower of people are somehow different and that new contributors can get involved and you know, they're welcome and can vet can contribute back to Django and you know, we'll do some valuable stuff.
David Heinemeier Hansson 30:56
Yeah, I think it's a it's a great topic and I don't know of rails has so Have any final answers in that regard, we have a Rails core team, that's 12 people, consisting of people who've made large code contributions to the framework. And in that way, there's definitely some outdated notions of contributions. I think that as a community and as an industry, we've moved beyond just looking as code as this sole measure of contributions. But in the way that rails core is sort of comprised, it is still mainly programmers who've worked on the framework directly for a very long period of time and have a lot of commits all over the different kinds of frameworks. And what they do then is, I think, more than necessarily write all the new stuff themselves is that they are versed in the framework and help other people actually contribute. I'm curious if you look at I haven't looked at this, but if you look at the lines of code contributed to a new release. Like rails six, how many of those are from the rails core group versus how many of them from the community? I'd be surprised if not the vast majority actually are from the community, that the majority work that the rails core team does is pull request, review and guidance. And if you look at sort of the number of contributors, let me actually, I just
Will Vincent 32:19
looked up as we're Carlton's working to add this to Django. I mean, I think you have, there's the like, All Time list where you're number three. I'm not sure how it's broken down by release. It may be I didn't,
David Heinemeier Hansson 32:30
it is. So that was what I was looking at for the six oh, release, we have 801 contributors. Wow. So that's sort of a pretty high number, right, like that kind of a lot of people have attributed and that that's just the code part. Right. As we just said, there's a broader discussion about what does it mean to contribute and there's certainly far more people who've advocated showed up at conferences, written blog posts and documentation, and all these other things, but just on the code part alone, there's 801 contributors. I'd be quite surprised if those 800 versus two what 12 people on rails core aren't the majority drivers of lines of code that actually go into into the framework. I think that may not be true on sort of, say, a new framework. Usually, that actually is a new framing actually, in almost, I'm trying to think back when the last one was, but a lot of those I'm very heavily involved in those either by writing the code myself, or it's something we're extracting from Basecamp. Or it's something that one of the other major companies in the rails community that have people who more or less full time work on rails work to extract. So I don't know if that really answers your questions. I think that there's a great discussion there for how can you make it more transparent how you can make it less gamified? How can you make sure that like, commits isn't this sort of one ladder that you judge everything upon? I think that's worthwhile, but at the same time, I'll also say that Having rails core having 12 people, having a small group of people to turn ideas over with is incredibly liberating, and psychologically rewarding. Now, I love the rails community. I love all 801 contributors who have code in six Oh, right. I can't have a conversation about something with 800 people. That's just not, it's not a useful working group size. Like I get frustrated at Basecamp. When we have like six people on the call, I go like Jesus, that's three too many. So just this whole idea of having these enormous groups or doing everything in quote, unquote public, I also don't think is a healthy idea at all, either. I think that there's a way of making progress and making decisions and forming bonds with other individuals that simply happen differently at different group sizes, and we should have all the rings, it's not that there should just be a Rails core group that decides everything, but having one rails core group and then we actually have a slightly or But larger group called. So Ralph, contributors were more frequent contributors join in maybe we have a base camp for that that has maybe I don't know, 40 or 50 people on that, then we have an even greater group that's called rails community where people who sort of just interested in talking to these smaller rings and people sort of can can join in. Then we have the Ruby on Rails core mailing list, which is a very widely distributed list, and we have avenues like rails conference on to where I think it's healthy to have all the rings, like if you just sort of go like, Oh, well, let's go to the widest possible ring and try to do all our work there.
Carlton Gibson 35:37
I don't think I would enjoy that you need a smaller group to decide make decisions to work together to, you know, come up with the ideas to plan them out. The thing that ties in ties in with that you've recently released is the shape up guide that Basecamp just put out, because one thing I've always followed you for is your views on software development or methodology. You know, don't make a mistake. Don't don't plan in advance, because that's just guessing. I mean, you know, to a certain extent, obviously you make plans. But, you know, could it perhaps you could talk to that a little bit because it's something that I've always, you know, followed you for.
David Heinemeier Hansson 36:11
I think those things go all the way through I've ever congruent approach to software development that ties in from the work, I do a base camp to the work I do add with rails, and a lot of that ties into small groups making progress. Now, that doesn't mean that those small groups can't be informed by a larger community. Absolutely, they should be. But when I sit down and for example, any of these new frameworks that I've been working on active storage, for example, I worked a lot with George like, it was basically just me and George at Basecamp, doing 90% of the work and then releasing the framework into into the rails group once it was only 90% done, and then finishing the last 10% with maybe another 50 people, or now once it's been out for a release to There's been 200 people on it, I think that most cohesive visions of software needs to be established by a small group of people. And then once you have that in place, it is so much easier to open the floodgates and invite everyone in. But if you invite everyone in, when you barely have an idea of what the thing is, or how it should work, you're just going to end up getting pulled in 400 different directions, and it's going to end up feeling like nothing. And that goes back to this idea of director, right like that. There is someone or a small group of people who have to infuse the project with a cohesive vision for where we want to go. If you ask 800 people or 801 as contributed to REL six for their full diverse opinions and software development, you're gonna get probably, I mean, if not 800 different answers a lot of different answers, right? We can't just by consensus arrive at good software, not in the definitional stage, not in the architectural stage. I find it much easier to scale up for development once that there is a scaffold a skeleton of something once that there is a defined set of both technical decisions and priorities, but also values, that's one of the reasons why I wrote the rails doctrine. I don't know how long that's ago, six, seven years ago, kind of trying to write down what drives my decisions for rails development, such that we don't need to, well, we don't need to, we can have an argument about those values. But then let's argue about the values. Let's not introduce an argument about the values in our technical discussions about how this feature should work, we can just refer back to them. This is the value set that governs the majority large decisions at rails. And when we're doing something that's congruent with those values. We don't have to bring that up for review in every single pull request, right, like debating whether convention over configuration is a good concept or not a good concept. That's not a discussion. That's a problem. To have in every single pull request, like we can have the discussion once and the rest community did, it was just like 14 years ago. Right? Like, again, doesn't mean you can't revisit your foundational values and principles, it just means that like, you got to do that out of band. So I think that that has been quite helpful. And I try to sort of view it in that way that bring ideas and ideas are often they're fragile in the beginning, they're like a little seed a little flower, that it's just come up with the grounds very fragile. If there's 200, people who all want to take a picture of it, someone's gonna trample all over that idea. So there needs to be a little bit of a stem, there needs to be a little bit of sort of rigidity to it, since it can withstand all this scrutiny. Because the scrutiny is good. It's just about how you time the scrutiny. Don't apply the scrutiny of 2000 people to day one, apply that scrutiny on day I don't know 45 or 300, or whatever it is, in the early days of rails. I kept Commit bit for like a year. For like the first year of rails release, no one committed code to the codebase. beyond me, part of that was the sort of arcane technology we had at the time, we're using CVS and we were sending diffs back and forth over email. Now, I'm really dating myself. Not like a GitHub where you just had a pull request, and you just commented on that, and so on and so forth. But the bigger point was not so much technology, it was that I still felt like Rails is fragile as an conceptual idea and where we want to go with it, it's fragile. And I want to protect that until it's sturdy enough that it can carry all these people who want to be part of it, because that's also wonderful, right? You want the disagreement you want the scrutiny you want the opposing viewpoints,
just can't have them all at once on day one.
Carlton Gibson 40:52
One thing I wanted to ask you, David was about how rails handles the security process because it's something that we take very seriously in Django, and you know, times Django and rails have collaborated on security fixes, particularly around CSRF and such like that. So I wanted to ask you about rails and the security process.
David Heinemeier Hansson 41:10
That's a great thing to ask about. And maybe I'm the wrong person to answer because rails has security group that's comprised of some rails core members and some other people who are interested in doing that work. And I'm not on that group. I'm not in that group, because the people who are much better equipped and interested and capable of doing that work than I am. I think the overall questions those is something I happen to run into, for example, when we have a security issue, how far back Should we go with releases? That's one of those things where I think LTS and long term stable. And so and that's one of the key drivers of the demand for that, that people go like, well, I might not want to upgrade, but I don't want to have an unsecure application either. So how far back should we go? I don't know if we've ever come up with a perfect answer. We have a security policy that says, Well, we were released for the most recent one and the major line and then one back for most things. But in several cases, we've extended that sort of courtesy beyond what the policy itself says. And then there has actually also been, there's at least one commercial company that does an LTS version where they'll commercially backport security fixes for you. Okay, that's a service and does, you can subscribe to that I haven't actually looked that much into it. It's funny, though, because we have a bit of the same issue at Basecamp. We have Rails applications back until I was gonna say before the beginning of rails time, which is sort of adequately describing the fact that Basecamp proceeded rails, yet it is a Rails application. So we have this entire history of like 15 years of different applications at different stages of rails, right like they were locked in. We don't upgrade all our I don't know Meaning we have at this point, but we have this policy of maintaining all our applications until the end of the internet. So there's like, I don't know, 1015 applications or something, we don't upgrade all of those to like latest version of rails, when that comes out, we always keep the current version of Basecamp. And whatever we're working on, like that's on the latest version, but everything else is kind of like on a staggered release of when we stopped doing feature development on it. So we've been in the position of having to essentially backport security fixes. And it's kind of an interesting thing is that most security fixes that I've seen, and I've been involved with the attack backer or figuring out maybe very complicated, huge lineup write ups, and then the fix is like one character online 247 of this one file, like the actual backporting of the fix, in most cases is not this dramatic, difficult thing, especially in the language, high level language like Ruby where you're not mucking about with like buffer overflow or any of these other issues. You can deal with, right? And again, that's not all the cases and I don't actually do the work. So it's easy for me to say it's easy. But that's kind of how we approach making sure you have a group that's on it. Have a process you've established for how to report securely, don't post it on like, get up, right, like you found a zero day exploit for rails don't post that and get up. There's a whole process for how you submit it to, to rails. And I think we for a while, maybe we still use we have a hacker one. I know, there's this platform, we have essentially exploits. And that kind of gives you a little bit of a process and so forth. And I think that's worked out pretty well. I mean, all major framers all major pieces of software, it's going to have security issues. All software has security issues. It's just a matter of whether you found it or not. And we've found some security issues and we've, I think, done a pretty good job at putting it out there and dressing. It's never fun. It always sucks. We've had some been some terrible ones. There's just been something that didn't even affect sort of the rails code, but a recent one, which was Ruby gems, a couple of accounts got taken over. And someone pushed essentially bad code that had some surveillance built into it. It wasn't a major thing. It didn't affect that many other people, but just the fact that it happened was one of those things where you go like, shit, let's let's look at everything again. And one of the things we did was, anyone who has access to push rails code must have to have a turned on with Ruby gems, like you're not no longer allowed to be part of the rails release group, if you don't have to have a turned on for Ruby gems.
Carlton Gibson 45:41
Yeah, I mean, it seems very sensible these days. But like that's happened in the node ecosystem. I don't know if there's been one in Python where a package has been compromised, but you know, it has made everybody rethink packaging and these these great repositories where you can just you know, npm install or gem install or pip install It's super hot, but you know you do how'd you trust the code that you're downloading? It's good question.
Will Vincent 46:05
As we wrap up, are there any topics we haven't asked you about? Or you want to ask us about, um, you know, I'm thinking already in my head. I don't want the title of this to be Django versus rails, I want it to be Django and rails. But I think I think it's gonna be shocking to a lot of certainly beginners, because I teach beginners who just see Django and rails as these different forks in the road versus being both on the same pathway learning web development and sharing a lot in common around community and maintenance and ongoing
David Heinemeier Hansson 46:31
future. And I think they are I mean, what's funny about this was, I was exposed to Python, before I was exposed to Ruby. And I had this friend who worked with me at a Java shop back in, I think, 2000 or 2001. Back in Copenhagen, he was a big Python fan. I'd never used Python or worked with Python. Before that I had done some PHP, I'd done some Java and JavaScript and so on, and he was just so in general, about Python and like, I needed to try and use and so on. And I just found that just mesmerizing, really interesting, right? Like, because here was, for example, in the Java community, which was I was on the fringe for some time. I never heard people talk with that level of love in their voice, not to say that those people don't exist. But it wasn't this common thing that Java programmers were just effusively in love with their language. They were like, no, this is this is a good language. It's very performant. It's like you get kind of like the monotone rundown of why you should use Java. Right? And then I had this friend who was like a Java programmer. He worked at this company writing Java a daytime and didn't we would go out at night, he would talk about Python. It'd be like this kind of voice. And you'd be like, Wow, this is so exciting. I really got to look into it. So this was sort of one of the early exposures to someone being really happy with the programming language and I was a little incredulous at that at The time because I had found that myself like, I had been working as I said, in DC, three different invite for different moment. I also done some ASP. NET, none of these four things ever happen. We talked like that, right? And then I found Ruby. And then I realized what the fuck he was talking about, right? Because I fell into this almost trance of working with Ruby that this was just, yes, it both things were called programming, but it's felt like a categorical difference. Yeah, feel at all like these other environments. And what I learned from that, in part is then studying some more Python was that it's funny because I'm, I'm otherwise not a romantic, but there was something romantic about this notion of falling in love finding the one programming language for you. And that's how I actually felt about Ruby. I usually don't feel about this about anything and I poopoo this idea of the one and only in all sorts of other different domains, but I must admit, when it comes to programming, I absolutely am a romantic and I'm very romantic about that. Ruby and I feel like I found like, my soulmate my brain mate when you've nurtured it, because I mean, that is it's heartbreaking to fall in love with something that others don't feel that way and it dies a slow death rather than a fast death. And then you
Will Vincent 49:13
well, framework or language you might
David Heinemeier Hansson 49:14
say that right? You say that. But by the time I fell in love with Ruby, no one else gave a damn. In the grand scheme of things I showed up to Ruby calm in the US there were like 42 people. And when someone asked like, who does Ruby professionally, like one or the hand wind off, like no one in the sort of comparable scale was using Ruby by the time I fell in love with it, which is perhaps also one of those differences. I don't mean it's been really nice. As I said, it's wonderful to look at like 801 contributors to late version rails, this huge community, whenever I go to Ralph's comp talk about all these new people who were stemming in all the time, it really is wonderful, but on the purely technical day to day level, it's all this hazy bonus for me. The main benefit is I get to use Ruby. And you know, what? If it was just me and the What do we have 15 other programmers at Basecamp, who used Ruby, I'd still be using Ruby, right? I mean, again, I brought a bad example here since I literally fucking wrote a framework from scratch just such that I could use Ruby, but such as my affection for Ruby. And the point I want to make with that is not everyone is romantic. For some people, it's just a tool. And it's just a way to get from A to B. It's a way to get an application. Sometimes I envy those people. Like I think like that, that is a really utilitarian way of looking at the world that I'm sure serves people very well and gives them a lot of flexibility in how they want to address problems. I'm also honest enough with myself to realize that that is not me. And I also have met enough other people to say, I'm not that special. There's a lot of room antics sometimes hidden. Yeah, like my friend, the Python programmer who was clearly romantic, right? He just happened to work in Java by day because that was how you put food on the table. But he had still found his one true love. And and I know for a fact, he still works with Python does To this day, 20 years later, even if he's worked with other things along the way, and there's definitely people like that. So when I say it was, if you are romantic, you'll find out just trying a few different things. It didn't actually, it didn't take me like three years to fall in love with Ruby. It took me like two fucking weeks. Like, right, like I had this explosive love affair with this programming language. And it's lasted for 20 years. And I've seen sort of similar things where a certain way of looking at code just resonates with them. Which is why I never tried to like, oh, why don't you like Python, yet? You know what I could try to give you in Intellectual decomposition of why that is and like, Oh, it's the blogs or it's the DSL or it's the blah, blah, blah, all these other things, it's the one I always pull out, which is somewhat disingenuous. But it's the double underscores before Len, and after Berlin, like that was the one on there to kind of put me out, right, which is, again, which is such a non utilitarian argument it doesn't. So I've kind of tried to stop convincing people, because it feels a little bit of like, either you are romantic, and you will, after some exposure, feel just drawn to a certain programming language in a way that resonates with your brain and your heart. to such a degree that it's almost hard to describe or it sounds silly to describe or you're not and you're just a utilitarian, everything is just a tool and you can jump from one language to another and, and so on and so forth. And what I want to say with that was that that's why there's nothing wrong for me with say Python, there's nothing wrong with a lot of things. There's just something that's right for me and that for me is Ruby.
Carlton Gibson 52:59
You There's no battle there. It's like you fall in love with your language. And it's what gets you and someone else has a different aesthetic or a different whatever, and they fall in love with something else. And that's fine. And there's no dispute, there's no contract.
David Heinemeier Hansson 53:14
It's funny, because I've had to that part I've had to learn. I've had to learn that the diversity of it is good. I will actually admit to the fact that in the early days of rails, I had such an affection. And I had seen the light in such a blinding way, that for anyone who were doing web development, I was like, You, I thought about it as a knowledge thing, right? You just haven't heard the argument. You just haven't seen the code. You just haven't seen the AP. If I can show you all the stuff, you will come to the same conclusion as I have, that Ruby and Rails are clearly superior platforms and that like that should be the dominant thing. I've thankfully outgrown that, like I've retained my love for Ruby and outgrown the fact that there's something valiant in trying To convert everyone in the world like that, that doesn't work, I still believe in advocacy. And I still believe in projecting this affinity for programming because I also remember, the days before I became a romantic programmer. I remember at the time, like I did programming of some variety for a couple of years before I found Ruby and became a romantic programmer. And I want to at least just open people's mind to the possibility that you can fall in love with a programming language. And you can have these, this emotional connection that is so deep and so strong with a certain platform and with a certain environment. And I think from there, even with a certain community that you go, like, you know what, I just don't, I'm not in the market. Like I get this all the time, though. So what programming Do you looking at? Like? Yeah, I look at I look at sort of everything that comes out. I've done some ghost stuff I do. I do a fair amount of JavaScript stuff and so on. But I'm not in the market for a programming language like that. That ship has already sailed. I won't Say it's necessarily sale forever. And always, it's certainly within the realm of possibility that some language is going to come out. And I'm just going to fall head over heels in love with it ever more so than than Ruby. But it just seems unlikely at this point, like, I'm about to turn 40. I'm like halfway through life, I'm probably at least halfway through my career as a programmer, perhaps. odds are that that language is not going to appear, that language is going to remain Ruby. And I say that in part because I look at other programs who've been around longer than me. And for the ones that are romantics like I talked to small talkers, occasionally, yes, a lot of romantic small talk programmers in the world who essentially radiate this romanticism. The small talk was the one and true they may not be working with it anymore. But like, that's where their true love still lies. Yeah,
Will Vincent 55:52
no, brilliant. Super, that's a beautiful way to wrap it up. Well, thank you so much for taking the time. I know people anecdotally again Go con. We're really excited to hear that we were going to talk with you about this. And so I'm really appreciate you taking the time to share your your views.
David Heinemeier Hansson 56:06
Yeah. My pleasure. And yeah, I just shout out to, to the Django community for pushing the batteries included. Philosophy. I think it is needed more than ever. I think I like to call it that what we're in right now is a little bit of the Dark Ages. And we need to bring light and enlightenment back to the world. Okay.
Will Vincent 56:27
Because Yeah. Okay, well, thank you, David.
David Heinemeier Hansson 56:30
Right later. Thanks, guys.