Transcript: Ruby on Rails & Django- David Heinemeier Hansson
Hello, and welcome to another episode of Django Chat, a weekly podcast on the Django Web Framework.
I'm Will Vincent, joined as always by Carlton Gibson. Hi, Carlton.
Hello, Will.
And this week, we have a very special guest, David Hennemeyer 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, Dave.
Yeah. So we're actually at Django Conf 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 Conf 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 sure um so in the rails world rails
conf 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 um this started back in like 2001 so almost 20 years of history there for 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 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 an avatar because
i don't actually have anything to do with the organization of uh rails conf or any of these
other ruby conf 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 a overlap whereas most other languages
have a little bit more of a sort of, I don't know,
competition amongst web frameworks.
Django 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 which is just sort of a funny thing.
I'd actually argue in some cases it's a bad thing.
I'm not generally a fan of monopolies or any of that.
It can lead to sort of a closed eco-chamber mirror 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, yeah.
But you're still very much sort of – in Django, we used to have the benevolent dictators who were the founders and they created.
But you're still very much in that role for Rails, right?
Yes.
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 associate with or whatever.
No, I totally get what you mean, right?
I'm reflecting on the fact that 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 or something like a director, right?
Like you don't do everything in the movie.
There's someone who 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 an 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 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 1,000 lines of code, which was what we originally, or what I originally launched with.
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.
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 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.
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 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 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 for Rails.
And just as a user of a language and of a framework, that's just an incredible, fortunate position to be in like 15, 16 years into this thing.
Yeah, that's what I wanted to ask you.
You're still excited about it.
You're still there and, you know, you feel it in your mouth.
You're like, yeah, I want this.
That's a great metaphor for it, 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, is just as fun now as it was 20 years ago or whenever 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. Well, that's the attitude to have.
It's one thing I'm struck by is people often, so 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
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 minds attach 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'm just curious your thoughts on why, why aren't there more batteries included frameworks out there? Because it seems like there should be more than two default options in 2019.
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 viewpoint, right? Because I believe the opposite. I believe that wasting your time clicking together 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 16, 64 by 64 blocks, huge blocks of integrated, essentially wisdom, in the most authentic sense of that word, knowledge captured, hard won over time because people kept doing the same things.
And we learned 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 do you think it's an education
effort 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 a value okay i think we are in opposition to the values
that most programmers are born with.
Well, not born.
I mean, that is, 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.
It's also, there's a discipline to it.
Wouldn't you say, I mean, for example,
we've, you know, when do you,
folks are at a company a 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
in sort of medium-large companies,
which I haven't thought of that angle until recently.
Yeah, I 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 five, six, seven years.
I'm 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.
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 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 than even Basecamp is.
And Basecamp 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 or something.
And at Shopify, 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 everyone.
And we can work together as a community by sharing the things that we develop that seem custom to us and that we're better off for it.
And I think that requires, again, the word of discipline, I think 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 sort of a guilty discipline that if I just sort of get myself together 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 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 microservice over here and we're going to do it in this bespoke little thing.
And before you know it, you have 47 of those running all sorts of different languages and people come and go as they do particularly in large organizations.
And now you just have another mess on your hand, right?
So the discipline of keeping a 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 who's there at the time.
Speaking of discipline as an organization, it's 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 in the latest Rails.
We can make it such that both GitHub and in many cases Shopify, they're 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 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 programmer who goes through a coding school knows how to use.
Like, that's clearly not good enough for us.
So I see that very much as 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 vanilla stack at a greater scale the higher your comp and the further
you can push it the bigger the product you can build because you're not you're bitty building
the product not working on the stack i'm curious we compare and contrast uh versions and so rails
you just released or rails just released version six so in django we're on um it took a long time
to get to 1.0 and then it went all the way to 1.11 then 2.0 we're on 2.2 now and 3.0 comes out
this december um 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 that versioning is probably
one of the clearest implementation of post-modernism in programming that like
everything can mean everything and there's 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 samvar 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 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 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.
You could have called that Rails 5.3.
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 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 6 will get Rails 6 defaults.
And any app you bring into Rails 6 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 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 like 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 up 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
versioning in rails that we give these marketing signal yeah okay things that says rail six ohs
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 rail six for like
six months in advance of the actual release what happens on the actual release does the software
go from 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.
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, Django
has this 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 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 that cycle works we have the LTS
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 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 in the LTS is
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 um i would say most companies follow the lts yeah in practice
i wish we could communicate how that's that's no longer necessary but you're with ed python
two to three is that's another story i don't know what to say there like that's going to be
difficult and companies are just going to have to bite the bullet and do it um but like jango well
It's a coming storm in our world, I mean, because a lot of companies are behind the eight ball on it and don't see the issue.
I don't envy that situation.
I think the closest we had was Ruby 1.8.6 to 1.9.
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 even more conservative.
I mean, as it probably should be as a language,
but it's very conservative as a language
and basically hasn't changed.
There 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 6 depends on Ruby 2.5,
but it's been a very long time
since I can remember any drama
about upgrading a Ruby version.
So, Ruby 2.6 comes out and we just say, yeah, now you got to use that because there really isn't any issue with it generally for most people most of the time.
The Python 2 to 3 thing is a little painful to watch from the outside.
I can imagine that perhaps it's painful to be on the inside.
But at least there's something there, right?
Like, what was it, Perl 5 to 6, where 6 took like, what, 15 years or something to come out?
At least you're not in that situation.
Like, there's something out there.
I mean, it's been out for 10 years.
I mean, and if you're on Python 3, it's, you know, Python 3.4 to 3.5 to 3.6.
It's very smooth.
It's just this one jump.
Right.
I think that's also part of one of those things where I was just saying, like, the monopoly that Rails to some extent enjoys 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 use
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 2.2 or whatever it was, right?
most of the Ruby world moves along.
Like 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 pull for, for example,
moving the Ruby community forward,
I think in large degrees have worked out quite well.
And does it, you think that comes from Rails?
Rails is the pulling engine, is that for Ruby?
Is that the case or?
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
who saw all 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
or 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 1.8.6 to 1.9 transition that had something about strings.
I also think it was something about UTF-8.
I've blissfully erased all that from memory.
We had that same thing where we said, like, all right, 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?
There was really a very strong pull.
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.
Yeah.
Believe that 3 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.
Interesting.
Related to Python 3, 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 async built in, right? I'm just curious your thoughts on, do people ask you to make Rails async? And is that even possible?
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 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, it just gets stuck on a queue.
It just gets sent out of order.
You never hang up a response to deal with that.
So, in that sense, I mean, we've been kind of async for a long time.
It hasn't been a big deal.
Like, it's not an area of discussion, really.
Like, performance is always an area of discussion, but usually by people who are not using Ruby or Rails.
Right.
Usually, it's a spectator sport to some degree.
Well, I mean, I've seen that Go benchmarks whatever, Hello World, like, 100 times fast.
and I'm like, 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 a $100 million 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 poo-poo
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 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 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, it's because we did a bad algorithm, essentially, right?
Like we programmed it 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 uh that we worry about yeah well to switch gears slightly
i'm curious could you talk about how rails core works 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 django con 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 i mean there are
there are exactly half a dozen maybe a dozen core people who are really busy actively contributing
they do 80 90 of the work and then yeah you know 200 300 contributors who make him one two pull
requests over the release cycle so there's talk of uh dissolving uh django core developers in terms
of it's an ongoing discussion of trying to have them both make it more uh more inviting to new
to beginner contributors you know to make it not seem like this um this this ivory tower of people
that are somehow different and that new contributors can get involved and you know they're
welcome and can but can contribute back to django and you know we'll do valuable stuff yeah i think
it's a it's a great topic and i don't know if rails has sort of 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 at 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 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 are 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…
Well, I just looked up because Carlton's working to add this to Django.
I mean, I think 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—
It is.
So that was what I was looking at.
For the 6.0 release, we have 801 contributors.
Wow.
So that's sort of a pretty high number, right?
Like, kind of a lot of people have contributed.
And 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, done documentation, and done all these other things.
But just on the code part alone, there's 801 contributors.
So I'd be quite surprised if those 800 versus the, what, 12 people on Rails core aren't the majority drivers of lines of code that actually go 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 can you make it less gamified?
How can you make sure that 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.
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. 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 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 a fair bit larger group called sort of Rails contributors where 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 are sort of just interested in talking to these smaller rings of people sort of can join in.
Then we have the Ruby on Rails core mailing list, which is a very widely distributed list.
Then we have avenues like 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.
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 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 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, perhaps you could talk to that a little bit because it's something that I've always, you know, followed you for.
I think those things go all the way through.
I have a very congruent approach to software development that ties in from the work I do at Basecamp to the work I do 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.
It was basically just me and George at Basecamp doing 90% of the work and then releasing the framework into the Rails group once it was only 90% done and then finishing the last 10% with maybe another 50 people.
And now, once it's been out for a release or two, 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 Rails 6 for their full diverse opinions on software development, you're going to 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 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 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 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 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 has just come up at the ground.
It's very fragile.
If there's 200 people who all want to take a picture of it,
someone's going to 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
so that 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 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.
It's 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 a 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.
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, at 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.
That's a great thing to ask about, and maybe I'm the wrong person to answer because Rails has a 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.
Right, okay.
And I'm not on that group because there are people who are much better equipped and interested and capable of doing that work than I am.
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 there's at least one commercial company that does an LTF.
version where they'll commercially backport security fixes for you okay that's a good
service and and does that you can subscribe to that 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 base camp we have
rails applications back until i was going to say before the beginning of rails time which is
sort of adequately describing the fact that base camp 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 base
camp and whatever we're working on like that's on the latest version but everything else is kind of
on a stacker 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 factor or figuring out
may be very complicated, huge 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, it's not this dramatic, difficult thing, especially in a 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 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 whole process for how you submit it to Rails.
And I think for a while, maybe we still use it.
We have HackerOne.
I don't know if there's this platform for submitting, 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 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 addressing it.
It's never fun.
It always sucks.
And we've had some, there's never been some terrible ones.
There's been some that didn't even affect sort of the Rails code.
But a recent one, which was RubyGems, 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 look at everything again.
And one of the things we did was anyone who has access to push Rails code must have 2FA turned on with RubyGems.
Like you're no longer allowed to be part of the Rails release group if you don't have 2FA turned on for RubyGems.
Yeah, I mean, that 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 great repositories where you can just, you know,
npm install or gem install or pip install.
It's super, but, you know,
how do you trust the code that you're downloading?
It's a good question.
As we wrap up, are there any topics we haven't asked you about
or you want to ask us about?
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, I don't know, Django and Rails.
But I think it's going to 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 sharing a lot in common around community
and maintenance and ongoing features.
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 had done some Java.
I had done some JavaScript and so on.
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?
Because here I was, for example, in the Java community, which 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 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 Java programmer, actually, working at this company writing Java at daytime.
And 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 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 hadn't found that myself.
Like I had been working, as I said, in three different, 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 fell into this almost trance of working with Ruby that this was just, yes, both things were called programming, but this felt like a categorical difference.
It didn't feel at all like these other environments.
And what I learned from that in part, then studying some more Python, was that it's funny because I'm otherwise not a romantic.
But there was something romantic about this notion of 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 poo-poo this idea of the one and only and 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 my soulmate, my brainmate.
And you've nurtured it because 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 framework her language.
You 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 RubyConf in the U.S.
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.
I don't, I mean, it's been really nice.
As I said, it's wonderful to look at, like, 801 contributors to the latest 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 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 base camp who used ruby i'd still be using ruby right i mean again i'm 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 a 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. 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. But he had still found his one true love. And I know for
In fact, he still works with Python 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 what I want to say is that 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.
Right. 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 an intellectual decomposition of why that is.
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 len.
Like that was the one thing that kind of put me on, right?
Which is again, which is such a non-utilitarian argument.
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 so on and so forth.
and what I wanted to say with that was
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
yes 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
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, 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 that should be the dominant thing.
I've thankfully outgrown that.
I've retained my love for Ruby and outgrown the fact that there's something valiant in trying to convert everyone in the world.
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 the programming language.
And you can have 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, do you know what?
I just don't, I'm not in the market.
Like, I get this all the time.
Oh, so what program language are you looking at?
Like, yeah, I look at sort of everything that comes out.
I've done some Go stuff.
These days I do a fair amount of JavaScript stuff and so on.
But I'm not in the market for a program language.
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 going to come out and I'm just going to fall head over heels in love with it ever more so 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 programmers who've been around longer than me.
And for the ones that are romantics, like I talk to small talkers occasionally.
There's a lot of romantic small talk programmers in the world who essentially radiate this romanticism that small talk was the one and true.
They may not be working with it anymore, but like that's where their true love still lays.
Yeah.
Brilliant.
Super.
That was a beautiful way to wrap it up.
Well, thank you so much for taking the time.
I know people anecdotally at DjangoCon were really excited to hear that we were going to talk with you about this.
And so I really appreciate you taking the time to share your views.
Yeah, me too, David.
My pleasure.
And yeah, I just shout out 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.
Perfect.
Beautiful.
Okay.
Well, thank you, David.
All right.
Later.
Thanks, guys.
Bye.
See you.