David Heinemeier Hansson Interview (Ruby on Rails, Basecamp & HEY) | The Craft of Open Source Podcast

Check out our open-source Feature Flagging system - Flagsmith on Github! I'd appreciate your feedback ❤️

Episode Overview

On this episode of The Craft of Open Source, I was able to interview one of the most influential characters of the open source community, David Heinemeier Hansson. David's work has been well chronicled over the last few years and his recent spats with Apple have been nothing short of Twitter Gold. I personally learned about David through the massively successful Ruby on Rails project which he created and launched back in 2004.

What stuck out to me in this interview was his level of passion and the underlying reasons that drive him to do what he does.

This was an extremely interesting conversation where we touched on the beginnings of Ruby on Rails, his thoughts on Open Source and what he has been up to in his commercial endeavors.

I hope you enjoy this one as much as I did.

-Ben

Episode Transcript

Thanks for joining us. We’ve got David Heinemeier Hansson on. Open source royalty. Thanks for your time. For those people who don't know who you are, maybe you want to introduce yourself and also your project and business.

I’m David Heinemeier Hansson and I'm the creator of Ruby on Rails. I am Cofounder at Basecamp, now also the makers of HEY, an email service we launched at HEY.com. I’ve been doing open source for twenty years or so. I’ve been part of the Ruby on Rails Projects for more than eighteen years. It was in 2003 when I got started with that. I’ve written a couple of books on business, It Doesn’t Have to be Crazy at Work is the most recent one, and the most popular one is called Rework from 2010. We also wrote about remote work in the ancient times of 2013 with Remote: Office Not Required.

{{divider}}

‍I wonder how that reads now. 

I read through the bulk of it recently and it’s surprising how much of it is still spot on. Including the discussion about what would be the trigger. When is it that are we all going to move to this? One of the things was there’s all sorts of natural disasters that can happen that force you to go remote. We didn’t have the pandemic in there at the top of the bingo card. The Remote Work discussion is intimately tied to open source because virtually all open source has been developed remotely. And it has been developed remote for many decades, which was one of the reasons and arguments we explicitly use in the book. This is not unproven. This is not an exotic imaginary way of thinking. This is the way most of the world’s most important software has been created for the past 30 to 40 plus years.

{{divider}}

That’s a great point. I hadn’t considered that. You’re right, projects are complicated like a Linux Kernel. Back in the day, almost before version control. The original Linux Kernel, was it BitLocker they were using way back?

Yes.‍

{{divider}}

That’s one of my questions for you. It was around the tooling for Rails. How did you discover Ruby, the language?

Back in 2002 to 2003, I was reading IAAA Magazine and it was also ACM Magazine, some of these computer magazines where Martin Fowler and Dave Thomas were both writing about programing concepts, patterns, and the likes. They were both using Ruby to illustrate their examples because Ruby has this quality of reading like pseudo code. It’s like if you don’t know Ruby, you know Ruby. If you know any programming at all you know how it reads. You don’t know the syntax of Ruby to understand concepts explained in Ruby. I thought, “This doesn’t look like the stuff that I’m used to. It doesn’t look like PHP or http://ASP.NET , Java. It looks way better.”

Not only that, both Dave Thomas and Martin Fowler were enthusiastic about this programming language. It would usually preface like, “I’m going to use Ruby to explain this thing.” I don’t get to use Ruby commercially because of reason but if I could essentially, I would. When I had the opportunity to pick my tech stack, where it was a client mandating, “You have to write it in PHP. You have to do this and that.” I thought, “Why wouldn’t I pick Ruby?” Here are some of these incredibly smart people who think highly of Ruby, I like the way it looks and now I have an opportunity to create something new, I should use Ruby. That thing happened to be Basecamp. Pretty much for the first project, I created a Wiki at the same time, it’s now lost in the ages. When I started in Ruby, it was Basecamp. Developing Basecamp and getting into Ruby through the development of Basecamp was also what led to Rails the framework.

It all started with reading some articles, magazines and going, “That looks cool. I want to do that.” I started then giving myself essentially a budget. I was going to spend two weeks and see if I could make something work because I knew how to use PHP, for example. I knew that the thing I wanted to build and I could totally build it in PHP but I was still uncertain whether I could do it in Ruby. I set myself two weeks. Can I get the basics? Can I talk to a database? Can I put something on the screen? Can we render some HTML?

It took less than a week and I was head over heels in love with Ruby. It was like this gift that keeps spreading when you see the galaxy brain at the end. Here’s the whole thing exploding and visions going off. This was how I felt. I’ve been programming for several years, but I didn’t know programming could be like this and it was far more interesting, engaging and it vastly accelerated my sense of learning and capacity as a programmer. It essentially set me on a course where I went from being, if not outright, a reluctant programmer, but certainly a doubting programmer. Was this the thing I was going to do for the rest of my career? This is the thing I’m going to do for the rest of my career.‍

{{divider}}

The tooling at that point must have been pretty rudimentary and the libraries and stuff. Were there database drivers back then? How rudimentary was it?

It was rudimentary. There were raw database drivers in the sense that you could send SQL strings to MySQL as I was doing, but not much more than that. There were some things that weren’t quite to my liking, so I essentially had to build everything myself, which was how Rails ended up being a full stack framework. We had to build the database integrations, the template languages, the controller code, and all the frameworks that were required to build web applications.

I essentially went like, “I’m going to build that myself.” That came after basically reading all there was because there wasn’t that much. I read through the entire standard library, which happens to be in Ruby, so you can read it. You can open it up and read through it. I learned a bunch through doing that. I read a bunch of other code that was released but there wasn’t that much, so it was simply a necessity that I had to write everything from scratch. At the same time, it was also a pleasure. It was a pleasure to show up in a community that was that fresh. When I showed up at the first International Ruby Conference in the US, this was 2004, there were 42 people at the conference.

When I asked how many in the audience were using Ruby commercially, how many people get paid to use Ruby, I raised my hand because I had a contract to build Basecamp and one other person raised their hand. We were two people at that third edition of the International Ruby Conference who got paid to do Ruby. The rest of them were there because they love it. They were there because they were excited about Ruby. That was a quality that was new to some extent.

PHP had been commercial from the get-go. It wasn’t a bunch of people doing PHP because they love PHP the language. Much the same, I’d say in Java. This idea that you show up in a community that has the quality of attracting people simply because they love it was new, invigorating, and inspiring. There were other people who felt the same way I felt; that they’ve been programming and they didn’t even know that they had been searching for what Ruby was the answer to.‍

{{divider}}

I was working professionally back then and it’s interesting how Python as well, to a degree were languages. It feels like back then it was much more around you were doing it out of necessity rather than out of love, and people didn’t tend to love the languages and the tools that they were using, whereas now it feels it’s different to me in a way.

Part of it was one of the other things that Ruby introduced was a complete paradigm shift in thinking about what are your tools supposed to do for you? Up until I would say, Ruby, at least for me and my discovery of Ruby, programming tools and ecosystems were thought of as that, tools. These were things like, “Can you do the job? Can you bang into the nail with this hammer? Who cares what the shaft is like, what the materials are like? Can you get the job done?” This is still a popular strain of thinking about programming language and tools but Ruby came in and already from its inception in ’95.

Ruby’s first mission is to be the programmer’s best friend. It’s to put the programmer first. We’re going to put the machine 2nd, 3rd, or whatever. The first person I’m writing Ruby for is the programmer and I will do things to the machine that it doesn’t want to do, because this makes a language that is more of a joy, more of a pleasure to use and it’s going to be complicated to write the compiler. Ruby’s compiler is famously intricate, complicated, convoluted, and hard to optimize in a bunch of ways because it wasn’t a primary concern for Mats.

The primary concern for Mats was the compiler in the human brain. When you optimize for that compiler, the human brain, you end up with a completely different language and you end up with a completely different approach to language design in a whole way that the thing feels and is constructed. Even that word feel is a thing that now gets evaluated on at least at par if not put higher than memory efficient, runtime performance, and all these other engineering terms you can use to describe whether a programming language is good or is not good. These were factors, but they were secondary factors to how does it feel to be a Ruby programmer? What do Ruby programs end up looking like?

This idea of aesthetics is also a somewhat novel turn at least again, it was for me from the backgrounds I came to. I know that there are other programming environments like Smalltalk, and perhaps to some extent, Lisp or otherwise that has the focus on this. For me, the focus Ruby put on it was quite extreme, that there would be multiple ways of writing the same thing simply to provide the peak aesthetic for a given problem space. Do you put the if before or after the condition? Is there an unless? That’s an If Not. Why do you have an entirely new keyword for a thing that could be expressed as an If Not? Most language design up until that point was much in the vein of doublespeak. Can we reduce the language to fewer terms and it will become simpler through that way?

That’s also one of the key contrasts with Python, for example. Python has it stated that there’s one and preferably only one way to do something. Ruby went the extreme other way. There are preferably as many different ways of doing something as you could imagine in natural languages, more or less, not quite, but far more so than Python has. Ruby embraces this level of divergence that you could write the same piece of code 100 different ways and a lot of them only had aesthetic differences but to me, that was the appeal.

That was what made me fall in love with Ruby, as not a programming language, but as a language, as a way of expressing not only creativity but what you want to do. I look to this day, as programming is writing. Programming to me is not engineering. I don’t think of myself as a software engineer. I do software engineering a minority of the time, where I do structured tests and all these other things but the majority of the thing I do is writing. It’s where I try to optimize something to make it clearer to the reader and to myself to make it beautiful and make it flow in much the same way that when I focus on writing in prose. It’s not about, “Can I convey an idea?” No. I want it to be lyrical to some extent. I want my programs to have a dash of poetry and Ruby allows that like no other language I’ve ever known or seen.

“Ruby’s first mission is to be the programmer’s best friend. It puts the programmer first.”

{{divider}}

You don’t think Rails could have been expressed at that time in a different language? That wasn’t by design, that was a fortuitous accident.

I know it can’t be because many people have tried in different languages and I’ve looked at most of those implementations and they’re fine. They’re good for what they are. They’re not Rails. This is one of the things when Rails first came to the scene and got popular. There were a bunch of other ecosystems that tried to adopt it and at the time the trademark was a little wavering in the wind but it was one of the things that made me trademark Ruby on Rails and Rails itself.

I didn’t want someone calling it, Pearl on Rails or Python on Rails because Rails is so intricately linked with Ruby. It’s a celebration of Ruby and the things that make Rails, Rails, you look at a piece of modeling code that uses an active record and how it reads like pseudo-code, in a way with absolute minimal simple noise is difficult to recreate in other languages. You have to have way more simple noise, in most cases in other languages.

I felt like, “Rails is the celebration of Ruby and it should be that.” Let’s call other things other things. In fact, this whole idea of re-implementing Rails in a different language is a bad way to go. You should take what’s special and unique about the language you’re working in and use it to its best abilities. You don’t get that by trying to re-implement Rails in another language. You get a poorer version of Rails. That’s not what anyone wants.‍

{{divider}}

I remember I was writing Java at the time, and people were tying themselves in knots, smashing around Java, Bytecode, and stuff to try and approximate the magic of a scaffold tag or something. I remember thinking, “This isn’t what the language is designed for.” You mentioned you had a contract to write Basecamp. Can you talk us through from an open source context, how did that work? When did you originally have the idea that this is a framework that should be abstracted out and published as open?

The good thing about this contract I had to write Basecamp, contract is a fancy word that implies that there was something written down that both of us had signed, which was not the case at all. This was a verbal contract for me to do programming for hire to create Basecamp. I was the sole technical person on that. I was working together with 37 Signals, as the company was called at the time, which was three people. Jason Fried the sole owner of the company at the time, and two employees. He didn’t care.

The reason he had hired me was that he wasn’t interested in learning programming and he needed someone to help out with it. I essentially had all the options. I could do whatever I wanted, as long as what we ended up with was good and we could ship this application that we were building. I took that as essentially, “I’m going to do whatever I wanted.” I did and part of doing whatever I wanted was, let’s start with this obscure Ruby programming language that you would never have gotten permission to use if you had asked someone on the merits alone.

Do you want to use a programming language that there are 42 people in the US who will show up for a conference at none of them were commercially in the language? There are no libraries. I have to write everything from scratch. There’s no support system and nothing. Do you want to use that for our new application? You were going to get a no which was exactly what people were getting at the time. This was why there were no commercial Ruby developers at the main Ruby Conferences because when you make the case to, let’s use the stereotype here, the beancounters, the beans didn’t add up. There were not enough beans here.

I never had to make that case, because it was solely up to me. Once I had decided to do it and fell head over heels in love with Ruby, everything else was almost on autopilot. As in, there wasn’t that much considered thought to it. First, I was here. I was doing this because of open source. If I’d had to buy a database license, a web server license, and an operating system license, we would never have gotten off the ground. When we got started with this, I was getting paid $15 an hour.

There wasn’t money for this stuff. We couldn’t have bought big sun servers, application servers, and all this other stuff. Our entire opportunity was created by open source. All of my learnings about programming were thanks to open source. Ruby itself was open source. Now what? I’m going to build something on top of all these things and I’m going to charge money for it. What? Even if that hadn’t offended my moral sensibilities, it also wasn’t practical. At the time, there were basically two entities that could charge for development software were IBM and Sun. Anyone else trying to charge for something like Rails wasn’t going to happen. It was also the only realistic path to getting this out there and getting it adopted.

As I said, I was head over heels in love with Ruby and one of my driving motivations for putting all this personal time into Rails was I want more people to experience Ruby. Why would I throw up barriers to that by putting behind some pay scheme? Secondly, I didn’t want to be anyone’s tool vendor. This was one of the things I stressed repeatedly, infamously in a slide that simply said, “Fuck you,” in one of the earliest conferences around Rails. It was in response to people treating me as though I was IBM, and they had a service contract and they could phone me up and say, “I want this thing implemented. Whatever you’re doing is wrong. You should change that.” I was like, “I don’t work for you.”

The reason I do open source is I’m publishing this as part, sharing my tools, my poems, and because I want to. None of it is because I want to be someone’s vendor, none of it is because I want to fix your bug fixes if they directly further the good of the framework overall, not because I want to do your features. No, this is open source, you fix your bug fixes. I’ll fix mine and we’ll trade. I’ll implement the features I need, you implement the features you need, and we’ll trade. That trading will end us up in a better place and that’ll be good but I don’t work for you. I’m not interested in working for you, and interested in getting paid.

This was perhaps one of the other things, as you mentioned in the intro here is that there’s a lot of different ways of making open source sustainable. I’d say in the past few years, the misconception that the only way to make open source sustainable is that the people who work on it have to get paid directly from that open source, has gained force in a way that’s simply ahistorical and wrong as a sort of categorical declaration of it. There’s never been more open source than exists now. There have never been more successful open source packages that exist now. There are plenty of packages, including Ruby on Rails, where the people who work on it are not interested in being vendor programmers. They’re not interested in doing the Rails part and the Ruby part because someone pays them as a client.

There’s a lot of different ways of going about this. I went through it because I felt the moral obligation to do it, because it was fun, and it was a way to improve my craft. It almost felt like what publishing would do in academia. You have these ideas, you think they’re good ideas, you don’t know, let’s put them out there, and let’s get some peer review, which is one of the great benefits you get from open source software. It’s almost like programmers are incapable of not sharing their opinions once something is like, “That code is wrong.”

The best version of those opinions are expressed as pull requests. When it comes to specific implementation, there are other areas that people can contribute that are also valuable but when it comes to discussing the code, we can discuss it in terms of trading pull requests. We didn’t even have pull requests back in the day. You were talking about version control systems. Rails started on CVS and I took pull requests on email and on Wikis. We had a Wiki at the time where someone would post pull requests, and I was the sole gatekeeper for the first year at least until someone else got the commit bit and maybe we moved to subversion shortly after we have more contributors. All the way back to CVS was how it started.

{{divider}}
One of the things that’s interesting is that a lot of the people that I’ve spoken to on this show, one of the common themes is that you write a database, you open source it, and 95% of the lines of code on that codebase are being written by people that work for the company. There’s almost a fallacy of this idea of sharing. What you said is quite counterfactual to that. What do you think the reasons are for that? Is it, again, down to Ruby, the language? What was it right off the bat with dozens of people submitting code, ideas, and sharing as opposed to it’s basically a company working in public?

One of the key differences here is, as I talked about, I explicitly said from the get-go, “I’m not interested in being a vendor.” I’m not interested in dominating this space to the point that anyone who needs to use Ruby on Rails essentially has to purchase a service contract for me to be able to do that, at least commercially and grand scale, which is how a lot of commercial open source is done. They have a specific interest in dominating that because this is how you end up with those kinds of contracts, whether they’re service contracts, teaching contracts, or consulting contracts of various kinds.

When that is your business, you end up dominating that. Maybe that works out sometimes but that’s not what I wanted to do. It’s not the programming that gets me excited. I get excited about solving my own problems. I’m egotistical in that sense. Solving my own problems meant sharing those and that was an invitation that is far more inviting than I’m a company. I want to solve all of it so I can sell these commercial contracts on it. I said, “I am explicitly showing up with half a solution. Not half a solution, I’m showing up with 7% of the solution. These are the 7% that applied to me if someone else wants to show up with the other 93%, let’s have an open source party.”

That invitation works better and I’ve seen that in other open source projects we’ve done at Basecamp. Not all of them had the adoption that Rails did and some of it was because what we published as the first version was too good. It was too polished. It felt too complete. It’s almost counterintuitive, that if you want to build an open source community around something, you almost have to release something that’s slightly shitty. It has to be a little broken. It has to be incomplete because those are invitations for others to step in and join the party in a way that does not feel intimidating.

When things are incomplete and broken, someone can very well sit down and go, “I could fix that. That’s not hard,” versus you push out this perfect diamond that’s polished and all the ways. People are like, “These people seem to know much more about this than I do. I can’t get involved with that.” That’s part of it. The other part of it is Ruby. The fact that Rails, when it was first published, was 1,000 lines of code. That included an active record, an action pack, and all the stuff you need for templating, talk to a database, and all the stuff you needed to build a web application. It was 1,000 lines of code.

That meant someone could sit down and read the entire framework in a day, maybe two days, and they could understand the whole thing. Read it and understand the whole thing. We’re a little further away from that now after years of development and not 1,000 lines of code anymore but the readability of much of Rails is still approachable in a way that’s not true in a lot of other programming languages. This whole idea, as we talked about, the reason I got introduced to Ruby was that Martin Fowler and Dave Thomas were using it to explain programming concepts.

Someone can open up Rails when they hit a bug or something that doesn’t work quite right, look at the code and probably understand it, possibly even create a pull request on it. To this day, the last version of Rails was released, Rails 6.1, had 700 or 800 different contributors to that version. Over the years, I believe we’ve had 6,000 or 7,000 people contribute code to it. The amount of code that’s left in Rails that I’ve personally written, nowhere close to 7%, I don’t know, 1% or 2%.

We ended up with different outcomes, in part by the design of the language, by the design of the community, and by my egotistical approach to open source and the fact that this wasn’t my full-time endeavor. I’m not a full-time open source developer. I do open source when I need to and I don’t do open source for months at a time. That leaves space for other people to come in and contribute and participate in a way it wouldn’t be if I have dedicated 40 hours a week and I knew everything and built everything so forth.

“Programming is writing, not engineering.”

{{divider}}
It’s one of the things I wanted to talk about or ask you was how you and Jason figured out the balance between writing Basecamp and writing stuff that you knew is going to be open. I’ve never considered that. If you leave gaps of time for people, they can come in and work on it. Whereas if there are five engineers working on an open source project for a company, there’s never a breath.

That’s a key part of it and part of it was that I’ve had mixed feelings about consulting-ware, which is essentially software built by consultants to be sold as consulting. The idea that we’re going to keep going and there’s always more work, I don’t subscribe to that at least not when it comes to the feature side of things. Sometimes you end up with too much. It’s ironic, perhaps that I should say that, given the fact that Rails does so much and often is critiqued for perhaps doing too much. The amount that I contributed is the amount that I need. I don’t build speculative software. I don’t build software because I imagined that other people might need it. I build software because I have needed it and already built it. I extract it and I put it into Rails when there’s been a proven need for it.

This is the bar that we often go through with new requests too. How did you need it? Tell us a story about how you needed this? I’m not interested in speculative software, not interested in possibly maybe. I’m interested in definitely, and here’s how. This is how it was worse if we didn’t have this. The A/B test. Show me the code you had before then show me the code after whatever the thing you want to put into the framework is there. Is it better? Oftentimes code fails that test, even when we are earnestly trying to do so from real code. The amount of times that I’ve thought I had a new idea for something in the framework, built it out, and I do the A/B and it fails the A/B. I was like, “This is not sufficiently better to make it into the framework” is common.

This is also what allows me to step away because I’m not a vendor. I can take six months off from doing Ruby on Rails if this was the commercial thing where you can’t take six months off. You’ve got to show constant progress and so on. In terms of the split between what’s open source and what’s not, for me, it’s clear. Anything that is plumbing, anything that’s generic code that I could imagine using in a different application, than Basecamp, it goes to open source and Rails. Anything that’s specific to Basecamp, doesn’t go anywhere. This is closed software. I don’t have a free software ideology attachment. I don’t even have an attachment to open source, particularly.

There’s a lot of code where I feel, “Why is this even open source?” As we talked about this consulting-ware, a fair amount of it, I go like, “Does this even need to be open source? If there’s one company dominating in any way, what is the point?” I understand that there are some benefits and you could theoretically introspect things, and you theoretically have additional freedoms and different options, but practically speaking, is that true?

Databases, to some extent, have that to me. I’ve used MySQL for more than twenty years. MySQL is open source. I can never in a million years imagine me opening up the MySQL source code and doing something to it. That’s just me. Having that practical approach to it is also why I love the MIT license. The MIT license is essentially me saying, “This is stuff I’m doing anyway. I’m putting it out there, if you want to use it, that’s great. If you find something that breaks or breaks your application, that’s your fucking problem.” You can report it and sometimes there are kinds of people who want to work on other people’s bugs and that’s great but mostly, you report it because you’re going to fix it, not because I’m going to fix it for you.

{{divider}}
I’m terrified to imagine how you were managing this community, source code, and pull requests before they were even, conceptually a thing. How did you avoid getting burned out and walking away from it all? Especially before, not necessarily GitHub, but when definitely before distributed version control? I’m getting scared thinking about that, especially I grew up with CVS and subversion. They weren’t designed for that type of development work, right?

They weren’t. Also, it’s one of those things where you can have a present bias and you go like, “Look at all these wonderful things we have,” and you think, “How did people even cope?” I’m old enough that I’ve used computers with one megahertz of CPU performance. They were computers. They were great. They did a bunch of things. They entertained me and taught me things. You can imagine, and it’s sometimes difficult for so called modern people to imagine ancient things. This isn’t even that ancient, we’re talking about things that are 30 years old. It was fine. It wasn’t a big deal. Yes, the tools have made it easier and tools have made it easier to scale but in the beginning, we also didn’t have that scale.

I was not processing patches from 700 people. There were, in the first year, 50 people who had patches into Rails. There was probably a high mark for it, so it wasn’t that big of a deal. In fact, to some extent, it provided something else. It provided me the opportunity to set a path to pave that path. This is what Rails is going to be. Before it got flooded with contributions that were trying to pull it in 500 different directions, this was one of the things that were a major part of the work in the early days.

It was not about reviewing code but around battling philosophies and values. What should Rails do? How should it feel, what should go into it, and what should not go into it? This was what a lot of the discussions were about. Because it was still so new there were a bunch of people who showed up and are like, “I like this rough thing. I want to take it this direction. I want to take it over here.” I had to, sometimes with less manners than perhaps I’ve refined now, say, “No, that’s not where we’re going to go.” This is my vision for what a framework is going to be and if you want to sign up for that mission, or if you want to complement that vision in ways that I can stand behind, let’s do it. If you want to do something else, go off and do something else.

{{divider}}
Were there ever any forks that made it past the first month?

Yes, one. Out of probably hundreds of either you call it proclamations or threats, but there was one, it was called Merb and it happened around 2008 maybe.We merged it back into Rails in 2009. That was a fascinating story in and of itself and it taught me a lot about what gives rise to forks like this and it’s much the same ways as what gives rise to rebellions of all kinds. Do people feel heard? Do they feel represented? Do they feel the issues that they care about are respected? Through error, miscommunication, at times a bit of malice, that ended up not being true for a bunch of people who wanted it to be true. That was the thing that paved the road for the Merb reintegration. When we finally sat down and talked about the issues, we realized that there was no difference of opinion on a broad scale.

There were a bunch of people who cared about different but complementary parts of a framework, people who cared about making the framework extensible, configurable, and certain parts of the performance that I didn’t care about. I expressly didn’t care about it but I want it to happen. If someone wanted to show up and do the work, I’d want it to be with open arms. I haven’t done a good enough job of communicating that and making that clear that it was okay to show up and part of that was, as I said, my crude at times manners with contributors who wanted to pull things in different directions.

What I didn’t realize enough at the time was that anytime you have an interaction in public, you have an interaction between you and the person you’re talking to and there are possibly 10, 100, 10,000 spectators, and they will all take certain things away from that public interaction and form their own opinions about whether it’s worth their time in the future to engage in likewise. I didn’t appreciate the extent to which that was true and the extent to which people I had never even talked about these issues with thought they knew exactly what I thought about them because they had observed other interactions and drawn their conclusions and their deductions from it.

We finally sat down contentiously so in the beginning and hashed things out. We ended up thinking, “All these things that Merb cares about can totally fit into rails. Why are we re-implementing all the parts of Rails that we are already in agreement upon should be like they are so you can add a bunch of things that could be in Rails as it is?” That was the one fork that made it far. It turned into a whole framework. It was a whole community at the time and the reintegration was difficult but totally worth it and Ruby on Rails as a community is so much stronger. Not because we are in this weird setup, in part that Rails is the only web framework in Ruby of large-scale community success or whatever. I don’t even like the word success. Let’s just say mass because there are other frameworks in Ruby.

Sinatra is a micro framework that’s been quite successful, and it can be complementary to Rails and there are some other things, other frameworks in Ruby that are more of direct competitors to Rails as it were. In terms of the broad scale, mainstream adoption, Ruby and Rails have an equation between them that’s not true in most other ecosystems. If you look at Python, for example. There are multiple choices, which are not clear in the same way that is clear in Ruby. That has its pros, and it has its cons but we’ve done well and we’ve done well for Ruby because of this.

{{divider}}
I’m thinking back to the screencast that you released in 2004 or so, where everything went crazy for you for a while. How did you come up with a design for managing it and delegating decisions, ownership, and commit rights? Did you put a lot of work and thought behind that or did it happen organically?

It happened pretty organically and part of it happened because I walked into the situation with pretty strong opinions about certain things about what I cared deeply about, and I wasn’t willing to delegate. Most of the API design fell into that category. I have, to this day, specific opinions about how an API should feel. I have less specific opinions about how most APIs should be implemented. In many cases, I barely care. You look at the router or even large parts of the active record now, I couldn’t tell you how they implemented it. I could probably sit down and figure it out but I couldn’t tell you how to implement it but all of the APIs that sit on top of that I’ve cared immensely about them.

I’ve finessed them and polished them over years and years of collaboration with people who did care much about the implementation. Having that clear delineation of what do I care a lot about? What do I not care a lot about? How can we work together in that way? It made it easier to get people on board, because I said, “There are thousands of things you could care about. I care about these 30.” Anyone else could show up and claim any of the other spots and you will be welcomed. You will be welcomed by simply showing up and doing the work and doing the work is showing up usually with a pull request but this was even before the days of pull requests, but showing up with a patch, the Wiki page, the mailing list or whatever.

You show up with a patch, you argue for why it should be and I can review that code and be like, “That’s good. Let’s put that in.” The other thing with commit bits was essentially encouraging people who showed a little bit of interest to go further. Someone shows up with a good patch. It’s small, but I see that this person gets it. They have the same aesthetic or at least they can be guided towards the aesthetic and they’re pleasant to work with. These other things. Let me try to rope them in because the more I can rope more people into it, the easier it is for us to make progress faster because I will make progress on the few things that I care about and as we talked about and that will be the 7%.

If we want to get to, if not 100% or 80% of what someone needs, we need more people to do it. I took that quite seriously from the get-go. It’s also more fun. It’s more fun to make software together. As we said, this sense of peer review is important and peer review works more pleasantly, I found, when you do you review with people you trust. It’s easier to trust people who you’ve worked with repeatedly over a longer period of time than strangers who show up in a pull request and start complaining.

It happened quite organically, I would say but it still wasn’t random. It wasn’t un-thought through but at the same time, we didn’t set it up. Rails, to this day, still does not have a foundation in terms of legal organization that stands behind things. In terms of a bureaucracy to process these things, there wasn‘t that. Our license as I said, was essentially the barest bones license you could get away with, which is MIT, which at the time when Rails picked, it was not the default in some sense that is it now. There were much more stringent licenses.

GPL had a huge influence at the time. I looked at that part of open source and I was like, “That’s not the part of open source that I’m interested in. I’m not interested in extracting contributions from people who would rather not give them to me.” I’m doing this for the fun of it. If I want to twist someone’s arm and be like, “You better give me all your extensions to your framework or else.” No. In fact, what I found is if people showed up with this code dump like, “Here are a bunch of things we made. You take it.” I’m like, “That’s a bag of trash. I’m sorry.”

“After 18 years, the readability of much of Rails is still approachable in a way that’s not true for a lot of other programming languages.”

It could be turned into something but right now, it’s a bag of trash and I don’t want the framework. I want the framework to be pristine for as long as possible. That was the other part of it. It’s like, “Yes, I want contributions from people who are like-minded, who want to be on the same path, want to share the same vision but I don’t want contributions from people who are not on the train.” It’s not that you have enough contribution and that makes sense and we should carry it. There are plenty of contributions and half of the contributions over the years have gotten rejected in the sense that this is not where we want to go. More code is by no means always better code, more features, more configuration flags, and everything is not the way to get a better framework. You need to have some crystallization of a vision. Know where you’re going, drive it from there, and invite people into the tent.

The tent is defined that the people inside are there because they want to be there and they enjoy the same kind of show. When people don’t want that they can go to another tent, there are so many tents. One of the things I learned over the years. In the beginning with Rails, people would ask, “When do I not use Rails?” That was one of the earlier questions, “What are the limitations?” Objectively for me, the answer to when to use Rails is always.

The reason for that is, I have designed Rails for my brain to the fullest extent. The class of problems I work on are all solvable by Rails. You’re not going to find this objective definition of when Rails fits and when does not fit because, for everything it was designed to do, minus is 5%, it is an answer. It is a great answer but it doesn’t mean it’s the answer to everyone because there is are plenty of people who don’t have a brain that works like me and don’t think of themselves as software writers, who very much think about themselves as software engineers.

For example, think of type safety as a baseline requirement of a language and anything else is a scripting language, a toy language, or whatever. You have these dividing lines where Rails is the correct answer to none of their problems not because of the problems but because of them. That is something I’ve come to appreciate more, but not something to appreciate that people are different but as in, “The world is way more interesting when people are different and when we don’t all write Ruby.” It’s so fascinating that we have an amazing software platform called the Web that allows people to bring whatever programming language they want and they did. I’m pretty sure that there is a web page somewhere on the internet that is powered by every single programming or language that has ever been invented. I don’t know what the count of that is but it’s high. Isn’t that awesome? Isn’t that wonderful?

Part of what makes the world so interesting and also what makes it possible in a language like Rails and Ruby on Rails is to be strict in the vision we pursue because we can go into that and know, “This doesn’t have to work for everyone.” Not all learning types and brains have to be compatible with this because there are options they can do. We can take this vision that we have and say, “It appeals to maybe 10%, 20%, or 30% of people out there and we can make it the best it possibly is.” It doesn’t have to appeal to 100%. In fact, if we try to make it appeal to 100%, we will end up with this mush that doesn’t taste of anything and needs enterprise salesforce to push it because no one would want to pick it by volition.

{{divider}}
Are there any languages, projects, or frameworks that you see? I’m feeling like there seems to be a vibe of the Ruby community that you talked about that seems to be reflected a little bit in Rust, to a degree in terms of people doing it out of enjoyment rather than professional necessity. Are there any things that you see Rails in?

Rust is a good example. There are several members, or people who’ve worked on Rust, who used to be in the Ruby and Rails community and some still are partly in both camps. Rust solves a problem that I don’t have. I don’t do any system-level programming, so it’s not something that I’ve particularly engaged in but I love seeing it. I love this idea that even after all this time, you can still make a new programming language, and you still do something awesome, new, novel, and take a different spin on things. It means that there’s still progress because one of the things that I thought when I first started Ruby on Rails is technology doesn’t last as long. It’s probably a five-year thing. In five years, we’ll be done. We’ll be on to something else. Ruby won’t be an answer anymore because if you looked historically speaking, it happened a lot.

{{divider}}
I was thinking about how frameworks have a half-life of two years.

They still do. One of the communities that have the biggest framework churn is in JavaScript. The vast majority of things that get announced today are forgotten next week. I thought that it was most likely that Ruby and Rails would go through the same thing. We’d have a 2, 4, or 5-year run and that’d be good and here we are 18 years later, and not only has that not happened, but we’re also stronger than we’ve ever been. We’re moving faster than we’ve ever had but that’s a rarity and exception.

Even if that’s true, I still appreciate this idea that there is fresh blood and ideas that are new concepts. They’re radically different and Rust is quite different in quite a lot of ways from the system-level languages that it’s competing with are trying to replace. I love seeing that. Another example of this is Elixir. I absolutely love the influx of that. You take something old, Erlang, which at the time was niche in much the same way that Ruby used to be niche. Perhaps it was less niche, well known, or more well-known than Ruby was because it had been used to implement big things with WhatsApp and so on so forth but it was still not something a lot of programmers were using.

Some of it was because of the ergonomics of the language and here you have Jose Valim come in, “I’m going to take all the things I learned in Ruby land and I’m going to combine it with five different influences I have. I’m going to turn Erlang into this other thing that has better ergonomics and is more appealing.” I love seeing that because it also felt that was what Ruby was and is. There’s a postmodern language in the sense that it isn’t a single paradigm.

Ruby goes like, “Functional programming. That sounds great. Let’s have some blocks. Let’s have some of this, that, and the other thing. Let’s import that in. Object-oriented program. That’s great. Let’s have that too. Procedural program. That’s great, too. Let’s put it all in.” It’s a patchwork language that takes influences from many different sources versus there are other languages that are pure. Functional programming is one of the things that in the time I’ve been a programmer went from totally niche to quite mainstream. Some of those functional programming languages are single paradigm. It’s no everything, no side effects, no this, no that, and the other thing.

I love to see these things where you go, “There are some influences of that.” That means that we’re not done because wouldn’t that be boring? It wouldn’t be boring where we’re like, “The perfect programming has been invented, we might as well all go home. We don’t need language designers anymore. We don’t need any new ideas.” In some ways, I’m disappointed that it doesn’t happen more often and with more impact. In some ways, I remain head over heels in love with Ruby. I am surprised. How is it that it’s Ruby? Ruby is from ’95? How are we still writing Ruby? It so happens that those evolutions happen inside of languages too. Ruby itself has gone through quite a lot of evolution over time and it had a base that was flexible in a different way. I remember when I first implemented a new method on string.

{{divider}}
It’s a mad language, in some respects, right?

It’s completely mad. In the dominant respect as to how people used to look at languages. If you go back and read some of the stuff that James Gosling wrote about Java and about how you needed to protect programmers from themselves, so on so forth. If you go in, and you nod your head at everything he’s saying, and you look at Ruby, you go like, “This is a madhouse. This would never work. People are going to override string five different ways from Sunday. It’s all going to trample over each other. You can never build large systems.”

That’s what’s so great about this. We got the answer to the skepticism, which was wrong. You can absolutely build huge systems like Shopify. By one account, it had a million lines of Ruby in their application. There are a million lines of Ruby running an enterprise worth $140 billion or something. I guess you can scale pretty hard to several thousands of programmers working on that. They probably have their issues, as does any organization that tries to push any program or language, or environment to those scales.

It’s been fun to see those academic disputes play out in fact and in reality, which we talked a little about but the remote thing has been the same thing with remote. Right up until 2020, people were legitimately saying remote doesn’t work. It doesn’t scale. Unless you have a water cooler and whiteboard, you can’t get creativity, you can’t get serendipitous interaction. It doesn’t work. Reality forced a verdict on that bullshit and the verdict was, “It’s bullshit. It could totally work,” as we talked about open source had proved for 40 years, but now the proof was definitive.

Ruby brought a bunch of definitive proofs to programming that were novel. You can focus on the programmer first to the sacrifice of the computing cycle and still create a language that’s not only fast enough but the speed that you produce is the speed of the programmer’s ability to implement code. That speed is more valuable, particularly directionally speaking for the industry at large, which was totally not a thing that was the case in the ’80s, or whatever.

They were trying to make Lisp machines and Smalltalk machines. You couldn’t do it and so forth. With Ruby, it bet on the human. They’re like, “We’re going to make our bet one way or the other. Are we going to bet mostly on the computer or mostly on the human?” They bet on the human. It’s an overwhelmingly successful bet. Computers have never been faster, cheaper, and programmers have never been more expensive. That fundamental economic calculus turned out to be exactly right for the vast majority of web applications, which is the domain that I ply my trade in.

{{divider}}
I’m conscious of closing things out. I know, you’ve had interesting few months having a spat with the second largest company in the world and all that stuff. Give us a brief overview of what you’re working on, and how your new product is going?

Over the summer of 2020, we launched a new email service called HEY.com that we’ve been working on for several years. We’ve invested millions of dollars into it. It’s created an absolute faucet of open source releases. On the front end, we’ve released something called Hotwire, which is novel in its presentation and its breath of an alternative to the single page application approach where you use React or whatever. We’ve spun off a bunch of things off of it but it almost didn’t come to be. The day we launched HEY, we had an app in the App Store and we submitted an update to that app and Apple rejected it because they wanted 30% of our revenues.

We went into an existential fight with the biggest most valuable technology company in the world and that lasted an utterly grueling two weeks or so where we battled Apple on all sorts of fronts, mainly in the medium, on Twitter, and elsewhere. We finally arrived at a reprieve that we won the right to exist without handing 30% of our revenues to Apple, in trade of some other minor yet still annoying concessions. That whole experience further emboldened my view that we’re in a bit of a rough spot right now with technology. It’s all due to monopolists that have power. I remember the Microsoft monopoly power. I remember the Windows monopoly power and it almost seems quaint in comparison.

{{divider}}
It seemed impossible to get out of at the time. I remember thinking no one’s ever going to defeat this.

“More code is by no means always better code.”

A thousand years of darkness and it did get defeated. One of the reasons it partly got defeated was because the American Department of Justice launched a lawsuit against Microsoft. It reset what Microsoft thought they could get away with or what they could do, whether they could just cut off the air supply to new, emergent platforms. It gave the breathing room for companies Google and Facebook to come up and exist. We’re in need of another grand reset like that. For several years, I thought that it’s not coming. We’re in another thousand years of darkness.

All of a sudden, just in the past year, you can sense the light. You can sense that the sun is below the horizon but there are already rays coming up. Perhaps it doesn’t have to be a thousand years of darkness. Perhaps we can push back against these monopolies and bust this death grip they have over the distribution of software when it comes to mobile devices. This is what made it an existential fight for us. We’ve been a web company since the beginning and to some extent, taken for granted what an utterly historical anomaly the web is as a software distribution platform.

The freedom it allows creators to reach consumers directly without mediation, without gatekeepers and we lived through the glory years of that from let’s say, the early 2000s through the early 2010s when the mobile devices and platforms became ever more important to the point where they’re now essential. If you want to launch a mainstream major service and you are not present on mobile devices, you’re not a serious consideration for the vast majority of the mainstream consumers. This was exactly what we faced. We’d built this wonderful email platform.

We had built it with six different clients but the two clients that mattered the most, in fact the client that mattered the most for our demographic of trying to sell commercial email services for money, not for privacy, not for attention, not these other things. It just so happened to be that the majority of the customers for that service were on Apple. About 90% of the customers that we have for HEY, use at least one Apple device. Something like 70% of the paying customers use Apple devices predominantly.

{{divider}}
That’s a crazy statistic.

It’s bananas. It’s a completely dominant market force to the point when people say, “You don’t have to do an iPhone app.” In the same way that if we don’t have to have 70% to 90% of our customers. That’s not a choice. It’s the same false choice that people were presented back when there were other monopolies. In the US, the railroads were one of the main monopolies that the state power took on and the argument then went, “You don’t have to use the railroads. You have some cotton or barley you need to ship from one area to another, donkeys still exist. Carrier pigeons can probably carry a few grains. You could do something else. You could walk it there. You’re going to have to use the railroads.” Yes, you do.

You can’t be competitive if you don’t use the railroads. Today. Apple and Google control the entire railroad system of software distribution for the two only mobile platforms that matter. They have 99.9% of the market share between the two of them in the US, at least. I know there are other things going on in Asia, China, and so forth. It’s funny because Jason said at the time and I felt the same pain. This was the thing. This monopoly power was the thing that if I’m going to retire, if this is what it’s going to be, if I can’t make software anymore without having to growl in front of Apple or Google and give them 30% of our revenue, maybe I’ll pick up a spade and start farming. I’ll do something else.

{{divider}}
It’s interesting how much we took the web for granted back in the late ’90s and early 2000s. It was a glorious thing. Pretty quickly, that was the safe assumption. As time goes on, there’s definitely been a divergence there. The problem that there is now is those antitrust questions and those questions about what you do are much more difficult to solve, than if you’re trying to break up Standard Oil or something like that. You don’t think?

No.

{{divider}}
Maybe on the App Store, not so much but definitely around the question of, what would you do with Google, for example, or what would you do with Facebook, WhatsApp, and Instagram?

I don’t think the questions are as difficult. It behooves the tech giants to make it seem the remedies are difficult. You take the app stores, for example. Barring the app stores from forcing applications to use a certain payment processing would solve the 30% question overnight. If we were simply given the choice, “You can use the Apple system, which by the way, is a pretty great system. The credit card is already on file. It’s a single touch to pay. It’s extremely low friction.” For lots of applications, that’s the right way to go but it becomes abusive the moment it’s not a choice. When you say, “You have to use it,” so you could ban that. You could simply say that the app stores do not have the right to mandate that this has to go through that way. That solves the app stores.

Google, for example, one of the ways that has been thrown around to promote the growth of alternatives is A) prevent them from becoming an ever larger conglomerate. This applies to all the big tech companies. Don’t allow them to use their existing monopolies in certain areas to gain new monopolies in new areas. Bar them from mergers and acquisitions. Don’t let them buy new, nascent competitors. Unwind the acquisitions done so far. Facebook should never have been allowed to buy Instagram or WhatsApp, whether they were smart acquisitions at the time or not is irrelevant. Break it up. Force those breakups.

This is the Standard Oil playbook. You break up companies that have too much integrated power and suddenly you restore an open marketplace where there is room for competition in a way that isn’t right now. This is the thing that gets me. Once you start reading about antitrust history, particularly in the US, you go like, “Everything old is new again.” It’s the same thing. It’s the same fundamental clashes between power and democracy, particularly in the US, where you have a political system that’s so dominated by corporations, funding, and so forth.

It is a struggle that is more than technology that once you have companies that are this large and this powerful, they also suddenly are vested with the jurisdiction to police all expression on the internet. Is that great? Do we want three private companies dictating who could say what and when and how? No, we probably won’t. A lot of that ties back again, to the monopoly question, which ties into whether it is possible now to build something to compete with them.

To a large extent, it isn’t unless we have something that upsets the cart and that’s what hopefully we’re getting now through the legislative action through the enforcement action that people are going, “What we have now is not a good place. We don’t want more of that.” The irony is that in the past year we’ve gotten way more of that. All the big tech companies have gotten dramatically more powerful and rich in this time, during this pandemic, and we’ve managed to wipe out ever more small companies that should have been the ones who are going to grow up and give them a fight.

That’s one of the things that I care about a lot now and it feels like it’s one of those things where if you were an open source advocate back in ’95 and you were looking at Microsoft, you’d be like, “This is impossible. The Office monopoly is too strong. How can Linux ever have a chance? How could anything else ever have a chance?” All of a sudden, there’s a fork in history, and the DOJ launches their case and Microsoft gets thrown off their balance. The web comes up and not a thousand years of darkness. Hopefully, that’s what’s happening now, but also possible that doesn’t happen. You look at all these forks in history and you go, “In many ways, we turned out quite lucky but the odds are it could have gone the other way.”

I don’t want to make the comparison in terms of monopoly but look at 1945 and ’39, the world could look quite different if things had gone slightly different. There’s this idea that there’s a historic inevitability that things are going to go right and in the end, “The good side is going to win.” It’s absolutely not guaranteed. We have to fight tooth and nail every day to make that happen, both in terms of open source and the ability to use software largely. We go with open source. I mentioned earlier that I’m not that much of a free software activist or purist. Has there ever been a greater affirmation of all the stuff that the free software movement talked about back in the ’80s, and ’90s than what we’re living through?

{{divider}}
That’s pretty amazing how prophetic that was because, at the time, everyone was like, “This guy is nuts.”

Totally. Perhaps he still is in other ways but sometimes you do need to be a little nuts to be able to clearly see what others aren’t seeing because the paradigm and the normalization, the well-adjustedness is adjusted to a certain paradigm, a certain society. If you’re outside of that, you can diagnose it in a way that looks prophetic. Absolutely, some of those diagnoses were prophetic and it’s one of those things where you can’t listen until it’s too late. It reminds me a little bit about the pandemic response. Anything you do too early looks alarmist. Anything you do too late looks negligent. We’re the negligent phase of tech monopolies.

{{divider}}
David, that’s been super interesting whirlwind. Thank you so much for your time. Thank you, again for Rails. I remember seeing the percentage of Y Combinator companies that were built on top of Rails, and it was 60% or something. Thank you from me. Good luck with HEY. Hopefully, I can pay you without paying Apple at some point in the future.

Hopefully, that’s part of the equation here, too. It’s to get people to realize that they can vote for the future they’d like to see with their wallet and it’s not all of it. It won’t bring total relief, but it will bring some relief and we’re trying to offer at least some options in that regard.

{{divider}}
Thanks again for your time and stay safe.