Transcript: Ruby on Rails & Django- David Heinemeier Hansson

I'm Will Vincent, joined as always by Carlton Gibson.

Hi, Carlton.

Hello, Will.

And this week we have a very special guest, David Hennemier Hansen, who's the creator of Ruby on Rails, co-founder of Basecamp, author, prolific tweeter, and lots of other things.

We're very happy to have you on.

Thanks for joining.

Thanks for having me.

Yeah, thanks for coming on today.

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 RailsConf and you spoke this year.

I thought it'd be great to talk about the similarities and differences there.

Carlton's a Django fellow, so he's one of two people paid to work on Django.

But it 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.

So in the Rails world, uh RailsConf 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 Confs.

Um this started back in like 2001, so almost 20 years of history there for Ruby Central.

And for a while, when um Rails was just taking off, O'Reilly did the conferences and they kind of did their whole thing.

And then at one point they um 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 um it's been doing a phenomenal job ever since.

And I'm really, I mean, when you say I'm the figurehead, uh I think in a very literal sense that makes sense.

As a figurehead being someone who doesn't have to have any authority, is just there as a as an avatar.

Because I don't actually have anything to do with the organization of uh RailsConf or any of these other or RubyConf 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 and Rails that functions entirely on its own, no influence whatsoever from me, thank God.

And um 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 an overlap, whereas most other languages have a little bit more of uh sort of I don't know, competition amongst uh web frameworks.

Uh 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 the sort of full stack scale, there aren't a lot of other prominent choices.

There are other things at different scale, like Sinatra is a sort of micro framework that's popular, but um which is just sort of a funny thing.

You think I I'd actually argue in in some cases it's a bad thing.

Um, I'm not generally a fan of monopolies or uh any of that.

So it can lead to sort of a closed eco chamber mirror that that's not good for anyone.

Um so I I'm actually surprised how well it's working out.

But maybe I would say that, right, as the uh quote unquote figurehead.

Um and you should ask someone else in the Ruby community.

But um yeah.

No, I I I totally get what you mean, right?

It's just I'm remarking or reflecting on the fact that like I I I wouldn't really want to have that title.

And I don't think I I do either.

Um I like uh sort of if if you were to use a film metaphor or something, like a director, right?

Like you don't do any everything in the movie.

There's someone who do does editing, there's someone who does the release, there's someone who does all sorts of different things.

But when it comes to like how should this scene look, yeah, the director has uh outsized influence on that.

And I I like to think that that's sort of what I provide for with Rails, and particularly around the design of the APIs.

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 a thousand lines of code, which was what we originally, or what I originally launched with it.

It was literally 1,000 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 of code.

I have no idea, right?

The vast majority of that code is not written by me, the vast majority of that 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 um 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 APIs 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.

Um, 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 um we put into active storage, I wrote a fair amount of that.

Um action text that was involved with that.

Uh 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 Rails.

I use Rails in all of my daily work, right?

So um I get to use all the stuff that I make myself for Rails, and then I get to use all the wonderful stuff that other people make f for Rails.

And just as a user of of a language and of a framework, that's just an incredible, fortunate position to be in, like 15, 16 years into this thing.

You're still excited about it, you're still there and take it, you know, you feel it in your mouth.

You're like, yeah, I want this.

Feeling it in your mouth, like that, just the 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 2, and created two 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 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 it brings a smile to my face is 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 as 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.

So I I teach Django for a living, I've written some books, and beginners often look at Django and Rails as 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 know, why isn't there another?

Is it just because it becomes monopolistic where all the mines attached to one in a given language?

Um, you know, so for example, Django is adding now uh async support.

That's a big thing, partly to do with um, 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.

Uh I'm just curious your thoughts on why aren't there more batteries included frameworks out there?

Because it seems like there should be more than two default options in 2019.

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 or hip alternative that wasn't batteries included, most people reverted to that primal stage.

And I think that that is um unfortunate, I think.

Um, 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 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 don't I believe the opposite.

I believe that wasting your time clicking together the the same damn two by two blocks over and over and over again is an utter waste of time that I very much don't want to waste my time on, right?

Like I want to put together 16 by 16, 64 by 64 blocks, uh 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 learned all that stuff and we packaged it up and then we leveled up and built on top of it.

But yeah I I continue to think that that is not how most programmers come to think.

They have to be converted.

Okay.

And for a while we were really good at converting people both with Django and with uh Rails but it just it didn't we we were cutting against the grain.

Like it's you know

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 a values battle.

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.

Which I have until recently yeah I I

I think for maybe five six seven years I I sort of not entirely sure on the timeline they were stuck on like Rails 2.3 a version that was released in 2009 I think or 2008 because they had all these little tweaks uh GitHub fell into the same trap that almost any growing company falls into which is to think that they're 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 the not just the latest Rails they're running like on Rails master sometimes they're further ahead on keeping up with the latest changes than even Basecamp is and Basecamp has been more or less running on master for like 1

5 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 or something and at Shopify it's 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 happenstances 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 any everyone and we can work together as a community by sharing the things that we develop that seem custom to us um and that we're better off for it.

And and I think that requires again the word of discipline I think it 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 if I just sort of uh get myself together and and wake up a little earlier I'll do it.

And then there's the discipline of basically imposing a set of values on an organization.

The discipline of like we will all march in the same direction here.

We're not gonna go in 15 different directions um even if you think that your direction is great for your little thing that you just want to do a microservice over here and we're gonna do it in 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 other mess on your hand right so the discipline of keeping an whole organization technically on a coherent track um 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 right latest Rails we can make it such that both GitHub and in many cases Shopify they're vanilla Rails apps um which is again one of those ideas that just bounces straight off the normal character orientation of most programmers this idea that vanilla is actually bad right that you're not really worthy you're not working at internet scale you're not doing something groundbreaking or modern unless you break out of

vanilla unless you break out of just the standard tooling that every like programmer who goes through a what a coding school knows how to use like that's clearly not good enough for us.

So I think I see that very much as this value struggle between um 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 vanilla stack at a greater scale the higher your competence

Because I know like what makes six versus five different versus a 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 how you all think about that.

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 SEMVAR is bullshit at least as a declarative notion of sort of distinct cutoff points because every feature is a regression to someone somewhere.

And every change and every config 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 numbering or versioning is marketing it's a way to communicate with your community with your users with prospective users uh what's going on and what's worth paying attention to when we smack a label of rail 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 that'll draw people in to take a second look and rails 6.0 includes a bunch of new frameworks and includes a bunch of major upgrades all of them are actually backwards compatible right like there's you could have called that Rails 53 there's nothing breaking in any of the individual headline features that we have we've then chosen to break some things because we just wanted to update things like that's usually what we

use the big version number uh 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 rail six will get rail six defaults and any app you bring into rail six that were 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 gonna stop moving forward.

Or you're gonna 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 they 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 like them.

This whole idea of packaging of wisdom as integrated frameworks and so on only works if you give yourself license to use that wisdom.

So that's what we're trying to do with the um versioning in Rails, that um we give these marketing signal things that says Rails 6.0s, 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 6 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 a given commit that we say, eh, that'll be it.

That'll be the 6-0.

There's still plenty of bugs, and there are some bugs that have been fixed.

Um so I think uh it's a mistake to ascribe too much technical importance to version numbering.

Uh to me, it's a communication tool.

Well, Django has this uh long-term support theory, which actually maybe Carlton, if you want to talk about that, because there's a big issue with Python 2, is um no longer getting support in 2020, and the new versions of Django don't support Python 2, but there's still a lot of people on Python 2, as well as older versions of Django.

But do you want to explain the LTS, Carlton?

Well, yeah, so we have how that cycle works.

You know, things didn't change.

What you just said about how not Rails 6 doesn't really break anything from Rails 5, 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 on 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 aren't they're not on that.

Python two to three is that's another story.

I don't know what to say there.

Like that that's gonna be difficult, and companies are just gonna have to bite the bullet and do it.

Um but like Django.

I mean, because a lot of companies are not are behind the eight ball on it and don't see the

I think the closest we had was Ruby 186 to 19.

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.

Um Rails hadn't really taken off at that point, I think.

Um, and now Ruby is uh is even more conservative.

I mean, as it probably should be as a as a language, but it's very conservative as uh as a language and basically hasn't changed.

There's been hasn't been any issues for people upgrading uh 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 6 depends on Ruby 2.5, but it's been a very long time since I can remember any drama about upgrading uh a Ruby version.

Like so Ruby 2.6 comes out and we just say, eh, now you gotta use that, because there really isn't any issue with it generally for most people, most of the time.

It's the the the Python 2 to 3 thing is is a little painful to watch

Um but at least there's something there, right?

Like uh what was it, Perl 5 to 6, where six took like what 15 years or something to come out?

At least there's not in you're not in that situation, like there's something

It's all it's very smooth.

It's just this one jump.

It's an right.

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 2.2 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 gravitational pool for, for example, moving the Ruby community forward, I think in in large degrees have worked out quite well.

Rails is the the pulling engine, is that for Ruby?

Is that the case?

Um I mean it's hard for me to talk about it because obviously I see mostly the good ends of that.

And and I know that there are other people in the Ruby community um perhaps less these days, but more so in the early days, who saw all the negative effects of that.

That, like, hey, there's an outsized gravitational pool here of a single framework that's pulling the language forward or with it in these certain ways.

But I think when we can use that gravitational pool 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 186 to 1.9 transition that had something about strings.

I also think it was something about UTF 8.

I've blissfully erased from my from memory.

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 poll.

And there wasn't so much, perhaps we were also luckier, 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 are very affectionate about Python 2.

And I 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.

I I believe, I mean, I know you have active jobs, right, for background async tasks, but Ruby doesn't have async built in, right?

I'm just curious your thoughts on do people ask you to make Rails async, and is that even possible?

So, first of all, um Rails has been threat safe for a long time now.

It used to not be.

It used to not be threat safe, and everything was process-based, and the prominent web servers were all process-based.

Now we ship with the default uh Puma as the web server.

It's all running on threads, it's all sort of threat safe, and it's just not a thing I think about.

Now, in terms of async and and pushing things out of the uh main queue, for example, you want to send an email as a response to uh an update or something, we built that in with sort of jobs way of doing it.

And we even 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, it just gets stuck on a queue, it just gets sent out of uh out of order, like you never hang up uh a response to deal with that.

Um, so in that sense, I mean we we've been kind of async for a long time, and it hasn't been a big deal, like it's not um area of discussion really.

Like, performance is always an area of discussion, but usually by people who are not using Ruby or Rails.

It's usually it's a spectator sport uh to some degree.

Well, I mean, I've seen that Go benchmarks, whatever, hello world, like a hundred times faster.

And I'm like, okay, yeah.

Like it has no relevance to my work.

As I am fond of saying, uh, Ruby was fast enough for me 15 years ago on a shoestring budget to launch a $100 million business.

Same with Shopify, right?

Like a $42 million billion dollar business was launched on a Ruby that was good enough in 2004.

Uh I mean, I that's not too completely poo-poo, the idea of performance.

And I always love getting free performance.

Uh, Ruby has been really steadily eked out, like a couple of percent improvement every new release, and they have these this idea that Ruby 3 was going to be three times faster than Ruby 2, the 3x3.

And I'm like, oh, great.

Like that's nice.

Like, I'm like, oh, some free candy.

Okay, I'll I'll take a few.

Like it's not something that really occupies my life in any meaningful way.

Um, and performance um with with languages like Ruby and and I'm sure Python as well, is just it's not within my um area of work to really worry about it.

When I worry about performance, it's because we we did a bad algorithm, essentially, right?

Like we we programmed it wrong.

We 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 uh that we worry about.

Yeah.

Because certainly in the Django world, there's um there's a big effort to have the core team uh such as it is reflect the community, which is much more diverse than the core contributors.

Uh so I'm curious how how do you how does Rails think about that?

Because I mean we're at DjangoCon, so kind of everyone here sort of gets it, but we still have this challenge of I mean, Carlton, you I 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.

They do 80%, 90% of the work, and then yeah, you know, 200, 300 contributors who make in one, two pull requests over the a release cycle.

We have a Rails core team that's 12 people, uh, 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 uh as a community and and as an industry, we've moved beyond just looking at code as this sole uh measure of contributions.

But in the way that Rails Core is sort of uh 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 uh versed in the framework and help other people actually contribute.

I I'd be curious if you looked at I haven't looked at this, but if you looked at the lines of code contributed to a new release like Rails 6, how many of those are from the Rails Core group versus how many of the 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 um sort of the number of contributors, um let me actually I have to do that.

I mean, I think you have there's the like all-time list where you're number three.

I'm not sure if it's broken down by release.

It may be I didn't

We have 801 contributors.

Wow.

Like the kind of a lot of people have contributed, and that that's just the code part, right?

As we just said, there's a a broader discussion about what it does mean to contribute, and there's certainly far more people who've advocated, showed up at conferences, written blog posts, done documentation, or done all these other things.

But just on the code part alone, there's 801 contributors.

Um, so I'd be quite surprised if if those 800 versus the what 12 people on Rails Core aren't the majority drivers of lines of code that actually go into um into the framework.

I think that may not be true on sort of say a new framework.

Usually that actually is a new framework, 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 um companies in the Rails community that have people who more or less full-time work on Rails, uh, work to extract.

Um so I don't know if that really answers your questions.

I think that there's a great discussion there for how you can make it more transparent, how you can you 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 6.0, right?

I can't have a conversation about something with 800 people.

That's just not it's not a useful working group size.

Um like I get frustrated at Basecamp when we have like six people on a 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 um 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 uh uh Rails core group that decides everything, but having one Rails core group, and then we actually have a slightly or a fair bit larger group called um sort of Rails contributors, where more frequent contributors join in.

Maybe uh 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 um Rails Community, where people who sort of just interested in talking to these smaller rings of people sort of can can join in.

Then we have the Ruby on Rails core mailing list, which is a very widely distributed list.

Then we have uh avenues like uh RailsConf and so on, too, 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.

You won't get it done.

The thing that ties in um ties in with that you've recently released is the shape up guide that uh Basecamp just put out.

Because one thing I've always followed you for is your views on software um development or methodology.

You know, that don't make estimates, 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 perhaps you could talk to that a little bit because um it's something that I've always you know followed you for.

I have a very congruent approach to software development that ties in from the work I do at Basecamp to the work I do at with Rails, and a lot of that ties into um 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.

Um but when I sit down and 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 the framework into the Rails group once it was only 90% done, and then finishing the last 10% with maybe another 50 people.

Or and now once it's been out for a release or two, there's been 200 people on it.

I think that most uh 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 gonna end up getting pulled in 400 different directions and it's gonna 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 um infuse the project with uh a cohesive vision for where we want to go.

If you ask 800 people or 801 as contributed to to Rail 6 for their full diverse opinions on software development, you're gonna get probably, I mean, if not 800 different answers, a lot of different answers, right?

Like we can't just um by consensus arrive at good software.

Um, not in the definitional stage, not in the architectural stage.

I find it much easier to scale software 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 uh Rails doctrine uh 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 appropriate 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 gotta do that out of band.

Um, so I think that that has been quite helpful, and and I try to sort of view it in that way that um bring ideas, and ideas are often they're fragile in the beginning.

They're like a little seed, a little flower that has just come up of the ground.

It's very fragile.

So there needs to be a little bit of a stem, there needs to be a little bit of uh sort of rigidity to it so that it can withstand all this scrutiny.

Um because the scrutiny is good, it's just about how you time the scrutiny.

Don't apply the scrutiny of 2,000 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 the commit bit for like a year.

For like the first year of Rails release, no one committed code to the code base beyond me.

Part of that was the sort of arcane technology we had at the time.

We were using CVS and we were sending diffs back and forth over email.

Now I'm really dating myself and the Rails community.

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 the technology, it was that I still felt like Rails is fragile.

As in uh conceptual idea and 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.

Um, just can't have them all at once on day one.

So I wanted to ask you about Rails and the security process.

Right, okay.

Um I think the overall questions though is something I have been drawn 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 on.

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 unsecured application either.

So how far back should we go?

And I don't know if we've ever come up with a perfect answer.

We have a security policy that says, well, we will release 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 um 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 good service.

I haven't actually looked that much into it.

Um it's funny though, because we have a bit of the same issue at uh 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 preceded 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, and we don't upgrade all our, I don't know how many 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, 10, 15 applications or something.

We don't upgrade all of those to like the 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 stackered release of when we stop 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 factor or figuring out may be very complicated, huge line of write-ups.

And then the fix is like one character on line 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?

Um, 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.

Um, but uh that's kind of how we approach it.

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 GitHub, right?

Like you found a zero-day exploit for Rails, don't post that on GitHub.

There's a phone process for how you submit it to um to Rails.

And um I think we for a while, maybe we still use we have a Hacker One.

I don't know if you've there's this platform for submitting essentially uh exploits.

And and that kind of gives you a little bit of a process and and so forth.

And I think that's worked out pretty well.

I mean, all major frameworks, all major pieces of software is 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.

It's never fun, it always sucks.

We've had some um, there's never been some terrible ones.

There's been some that didn't even affect uh sort of the Rails code, but uh a recent one which was um uh Ruby gems, uh a couple of accounts got taken over, and um 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 2 of A turned on with RubyGems.

Like you're you're not no longer allowed to be part of the Rails release group if you don't have 2FA turned on for uh RubyGems.

Um 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 comp 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, but you know, you do how do you trust the code that you're downloading?

It's a good question.

Um you know, I'm thinking already in the in my head, I don't want the title of this to be Django vs Rails.

I want it to be I don't know, 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 of learning web development and um sharing a lot in common around community and maintenance and ongoing features.

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 uh back in I think 2000 or 2001, back in Copenhagen, and 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, I'd done some JavaScript and so on, and and he was just so evangelical about Python and like I needed to try it and use it and so on.

And I just found that just mesmerizing, really interesting, right?

Like, because here I was, for example, in in the Java community, which was I I was on the fringe of 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 you get kind of like the monotone rundown of why you should use Java, right?

And then I had this friend who was like Java programmer actually working at this um company writing Java at daytime, and didn't we would go out at night and he would talk about Python and it'd be like this kind of voice, and you'd be like, wow, this is so exciting!

I I really gotta look into it.

So this was sort of one of the early exposures to someone being really happy with the programm language.

And I I was a little incredulous of that at the time because I hadn't found that myself.

Like I had been working, as I said, in these three different environments, four different environments.

I also done some ASP.net.

None of these four things ever had me talk like that, right?

And then I found Ruby, and then I realized what the fuck he was talking about, right?

Because I I fell into this almost trance of working with Ruby that this was just, yes, it both things were called programming, but this felt like a categorical difference.

It didn't feel at all like these other environments.

Um and what I learned from that in part is then studying some more Python was that it's funny because I'm all 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 uh Ruby.

I usually don't feel about this about anything, and I poo-poo 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 Ruby, and I feel like I found like my soulmate, my brain mate.

You 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 RubyConf in the US, there were like 42 people, and when someone asked, like, who does Ruby professionally, like one out of the hand went 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 is I don't, I mean, it's been really nice.

As I said, it's wonderful to look at like 801 contributors to late version of Rails, this huge community.

Whenever I go to RailsConf, talk about all these new people who are stemming in all the time, it's 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 perhaps a bad example here since I literally fucking wrote a framework from scratch just such that I could use Ruby, but such is my affection for Ruby.

And the point I want to make with that is is um not everyone is a 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 uh 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 romantics, sometimes hidden out there.

Yeah.

Like my friend, the Python programmer, who was clearly a romantic, right?

He just happened to work in Java by day because that was how you put food on the table.

Um, but he had still found his one true love.

And and I know for a fact he still works with Python this to this day, 20 years later.

Uh even if he's worked with other things along the way, and and there's definitely people like that.

So when I say when I say this, if you are romantic, um 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?

Which is why I never tried to like, oh, why don't you like Python?

Yet you know what?

It's the the one I always pull out, which is somewhat disingenuous, but uh it's it's the double underscores before Len and after Len.

Like that was the one thing that kind of put me on.

Right, which is again, which is such a a non-utilitarian argument.

It doesn't um so I've kind of tried to stop convincing people because it it 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 um 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.

Um, and what I wanted to say with that was like 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.

And there's no dispute, there's no conflict.

I've had to learn that the diversity of it is good.

I 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 I thought about it as a knowledge thing, right?

You just haven't heard the arguments, you just haven't seen the code, you just haven't seen the A-B.

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 I've thankfully outgrown that.

Like I've retained my love for Ruby and outgrown the fact that um there's something valiant in trying to convert everyone in the world.

Like that doesn't work.

I still believe in advocacy and I still believe in projecting this uh affinity for programming because I also remember the days before I became a romantic programmer.

I remember 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 the 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 I I get this all the time.

Oh, so what program language are you looking at?

Like, yeah, I look at I look at sort of everything that comes out.

I've done some Go stuff.

I've these days I do a fair amount of JavaScript stuff and so on, but like I'm not in the market for a program language.

Like that that ship has already sailed.

I won't say it's necessarily sailed forever and always.

It's certainly within the realm of possibility that some language is gonna come out and I'm just gonna 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.

Um, odds are that that language is not gonna appear, that that language is going to remain Ruby.

And I say that in part because I look at other programmers who've been around longer than me.

And for the ones that are romantics, like I talk to uh small talkers occasionally.

There's a lot of romantic small talk programmers in the world who uh essentially radiate this romanticism that small talk was the the one and true.

They may not be working with it anymore, um, but like that's where their true love still lays.

Yeah, no, brilliant.

Super.

Well, well, thank you so much for taking the time.

I know people anecdotally at DjangoCon were really excited to hear that we were gonna talk with you about this, and so I'm I really appreciate you taking the time to share your your views.

Yeah, me

And uh 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, um, and we need to bring light and enlightenment back to the world.

Okay, so perfect beautiful.

All right, later.