Transcription

Back in 99 or 2000, I'd had this web design company called 37 Signals, and I had two partners in the business, and we were doing some web design for people. But I had this side project that I was also doing called Single File, which was this online book database thing that I was trying to build, and I was building it out of PHP. I didn't know how to program, but I picked up a book on PHP, and I started making this thing. I got pretty far, but then I got stumped. So I wrote this post online asking for help. It was a general call for help. There's my problem. Anyone know how to do this? This was way back before Stack Overflow and all the places you could get answers. There were no answers. So help, someone. And it turned out this guy wrote me from Denmark. Back then, I was here in Copenhagen, Denmark, working in the web industry, and I was just a big fan of the company. Right from the inception, there was a web blog, Signal vs. Noise, that I followed religiously right from the get-go. It was just such a weird company. This was a design company that was focused more on writing than it was on pretty pictures or graphics or anything else that I associated with design at the time. So I was following this company for a couple of years, and then in 2001, Jason Fried, one of the original co-founders and still my business partner to this day, posted on the blog a question about programming. I saw this question, and I went like, hey, I know the answer to this. This is a way for me to give something back to someone I've enjoyed reading and learning from in the past two years. So I did just that. I wrote up an answer explaining how to do this thing he wanted to do in PHP with great detail, the best as I knew it. I wasn't an expert programmer, really, but I knew the answer to this question. His answer and his help was so thorough, and there was this quality and this character to his answer that made me feel like he really wanted to help and not just respond, but he really wanted to help. And so we started talking back and forth about this help, and then we got deeper into it, and he's like, can I see the whole thing? And I said, sure, and I showed him the code, and he's like, this sucks. We should really start over. Let me do this for you. And so that's how my relationship with David actually began. I got my first computer when I was six years old. This was in 1985. It was an Armstrong 464, and that was my first exposure to programming, typing video games in from the back of a magazine. I wasn't very good at them. I only made a couple of them work, but this was how I got started. Next up was trying to learn programming once more when I was around 10, 11, 12, a programming environment called EC Amos. It was not easy for me. It may have been Amos, but it wasn't easy. So I failed once more to learn programming. I had a hard time with even the basics of variables and loops and conditionals and all the basic constructs you need to learn how to program. So I gave it up once more, and it wasn't until I discovered the internet in 1995, getting involved with making HTML, that I thought, hey, here's another opportunity for me to be able to create something. And in 1999, I started working on a gaming website with another programmer in PHP, and that was really the first time things clicked. At that time, I'm 20 years old. This is my third attempt at learning to program, but now I understood it. And that was really the prep I had before a year later I would write Jason that email. So the first time I met Dave was in Chicago. We had been working together for quite a while, actually, but we'd never met in person, just on Skype. So I'm at the John Hancock building in Chicago, which is a famous building in this big plaza, waiting for him to arrive. We agreed we were going to meet in the morning. And so I'm waiting there, and I'm looking around, like, is that him? Is that him? Is that him? And then, no, it wasn't him. But then this guy shows up, and he comes around the corner, and he's wearing all white, rail-thin, like white T-shirt, really short sleeves, white capri pants, white shoes. I'm like, there's Denmark right there. That's David. And so, and I think, actually, you know, I'm thinking he had white shoes, but I think he may have had rollerblades on, now that I think about it. I'm not exactly sure, but it was so obvious that it was him. After we'd worked on this book thing for a while, we worked on another client project, then, actually, a few, because we were a web design firm, so we were just doing web design. We did a few more things together, and then we started getting really busy and needed a way to manage our projects. And so we had this idea to build this project management tool for ourselves, and now David was still a student at this time. He was still in Copenhagen at business school there, so he didn't have a lot of time. He wasn't a full-time employee or anything like that. And I hired him to do this right at the back end of Basecamp, and at the time, he's like, I don't want money. I want laptops. I want computer equipment, because it was very hard for him to get modern Apple stuff in Denmark. So every time he came to the U.S., and this is probably illegal, but anyway, every time he came to the U.S., I gave him a laptop, or I gave him, you know, whatever he needed at the time, right? And that was payment for Basecamp, and he would only give us like 10 hours a week, because that's all the time he had. 2003 is when we decided to start on Basecamp. We had worked together on these consulting projects, and most of the organization around that had been over email, an experience everyone feels, I think, if they try to organize projects over email. So we thought, do you know what? We know how to make web applications. Can't we just make an application that will make this easier for us to do, so we don't have to deal with all these email threads, and which version of the file is the latest, and what's left to do before we can launch? And that's what we did. And I had just earlier that year discovered Ruby. Through the writings of Martin Fowler and Dave Thomas, who were using Ruby to illustrate programming concepts that they were writing about in programming magazines, I just thought, this is a really interesting programming language. First of all, I hadn't heard about it before, and I'd been working with the web for quite some years at that point. That was intriguing. It was out of Japan. That was intriguing. I saw the code, and it looked just like pseudocode. You know how if you're trying to explain a programming concept, sometimes you won't write the exact right syntax. You'll just write something that more looks like English? And that's exactly what Ruby looked like. And I thought, this is just really interesting. And here are these two titans of the industry, Dave Thomas and Martin Fowler, who were clearly very enamored with the language, expressing that they would wish to write systems in this language if they could only get permission to do so. And I thought, do you know what? Here's a project where we can choose to do whatever we want. So I got to make the choice, and the choice was, let's try Ruby. I remember in the early days of building Basecamp, I didn't have any input on the back end. But David's like, you know, I'm going to use this thing called Ruby to build Basecamp. Because we'd been working in PHP previously. And I'm like, what the fuck is Ruby? I've never heard of this. He's like, it's this thing out of Japan. I'm like, alright. I mean, really, I truly, I didn't care, because it's his part of the project. It's not my job to tell him what to use. And I trusted him. When we started working on Basecamp in 2003, I was getting proficient enough in programming to start to develop a taste for what I liked in programming. But I hadn't found yet somewhere to express that taste. It really wasn't until I discovered Ruby that I found the programming language that simply clicked for me. And what I loved about Ruby was the sense of combining the immediacy of PHP, being able to get Hello World onto the web with a minimal amount of fuss, together with a really sophisticated, well thought out, coherent, object oriented programming language. That was the appeal I found in Java. That there was all this intellectual rigor, the software patterns, and all the other stuff that serious system development engineers were all about. And Ruby, to me, brought both of those things together. Or at least could bring both of those two things together. And that's where I saw an opportunity. It started out really simple. I had a two week window that I gave myself of could I build just the basics of a web application? I had an HTML up on the screen that was rendered from Ruby and I was talking to a database. And could I simply make those things happen? So there wasn't a lot of libraries. There were not a lot of frameworks. There were certainly not a lot of things to help you with database access or with web development in general. And that's how Rails came about. That I simply had to build the tools myself in order to be able to use Ruby as my programming language for this new system we were creating. It wasn't because I had already looked at a bunch of other things in Ruby. I had looked at other things in PHP, I had looked at things in Java, so I had a good idea of what I wanted. But Ruby was the language that gave those ideas wings. Where I thought I could write code that wasn't just functional, but it was beautiful. Over the next 6-7 months, we created Basecamp and during that process I extracted Rails. Not as a big upfront design that I want to create this grand framework, web framework and release it to the masses. There was not even a thought of releasing it originally. I simply needed these things. So I did that in the period between the summer of 2003 and the release of Basecamp in February of 2004. That was the main gestation period for the framework itself. But I didn't really release Rails until later in 2004. Because I had this vision right from the get-go that here's something that could be special. The first version of Rails needed to be good. And good not just in terms of the code, but also good in terms of the documentation. So I spent a good 6 months, I think it almost was, after the release of Basecamp polishing things up, polishing the documentation before putting it out there. Right here behind me is where I lived when I started working on Rails. So when Rails started to take off, it was pretty wild. And there was a bit of two minds about it. On the one hand, it was great to see that something I had created was creating this much excitement. And at the same time, it was also highly protective of the integrity of the vision I had put into Rails. More and more people were interested in Rails. And some of those people were interested in pulling Rails in one direction or another. I think it's very easy to lose control when something like that happens. Be so enamored and just pleased with other people's contributions that you put it all in and you have a hard time saying no. If you say no to someone, you are risking a conflict. And I said no to a lot of things. I said no to certain things I did not want Rails to be. There was this infamous slide at an early Rails conference in Canada, where I simply just put up the words, fuck you. And I put up those words as a way of expressing my, at times, frustration when someone would show up with what I consider an unreasonable demand for me to put something into Rails that followed up with a threat. Unless you put this thing into Rails, you will fail. Fuck you. That's just not... You don't get to tell me what to do. I'm working on Rails because I want to work on Rails, and I will solve my problems, and I will protect the integrity of the framework. I'm not here to be your servant. I am not allowing you to buy anything from me. This is one of the main reasons I love open source so much. It is not a commercial relationship. You don't get to tell me what to do. You don't get to tell me the direction that Rails has to take. I'll make those decisions on my own, thank you very much. I'll take input. Absolutely, I'll take feedback. And Rails is what it is today because thousands of people contributed really great work that I had no hesitation saying yes to. I arrived in the Ruby community because I thought Ruby was cool. I like programming languages. I would dabble in them and just try things out in them, and when I tried Ruby, I really liked it. It just... It stuck with me in a special way that I kept coming back to. Just felt close to my heart, and I didn't try to analyze it too much of the time. As the years went by, and I did web development in Java and PHP and Perl and other languages, I kept thinking about, feeling that old tug of, why isn't Ruby here? Why hasn't Ruby showed up? Here comes this guy announcing on the RubyTalk mailing list, I've got a plan. It's like, what, are you coming down from Mount Sinai with your tablets of... Who gave you these commandments, the way to develop for Ruby and the way to develop for the web? We haven't seen you before. So it was a provocation, and there was some spice to it. It's like, is this guy an asshole? Or is there something to it? And it was a little bit of both. Here's this guy with a kind of well-carried arrogance about having the right ideas, and willing to set those ideas out for everybody to see, and they were great. They were good ideas. Sure, some of them were old ideas, reconfigured, but they weren't pitched as anything but that. The active record pattern says it right on the tin, now it took it from a pattern to being a framework. And that added, it was a jolt of energy and kind of electricity in a Ruby community that was very generous, very kind, and now had this kind of aliveness, like, what's going on here? How do we channel this energy? What are we going to do with this person? And it varied from tolerate this person to embrace and see what he brought. I first heard about Ruby on Rails at the 2004 International Ruby Conference. I was working for Brigham Young University at the time, and not using Ruby, but I received permission to go to this conference because I was very excited about the Ruby programming language and was doing a lot with Ruby on the side, and even sneaking it into the system, so to speak. And I went, I was actually presenting about something that I had been working on, on the side. It was not a big conference. There was maybe just 30 or 40 people in total, but I remember sitting there, and one of the presenters was David Heinemeier Hanson, who I had never heard of before. I had never heard of Ruby on Rails. It was brand new, just barely released. And he got up and was talking about why he wrote Rails. He really was pushing a better experience for programmers. And I remember him standing up there, holding an imaginary piccolo to his lips, and talking about how, like the Pied Piper of Hanlon, he was going to lead programmers to a better experience, a better way of living. For about the first year, there was no one else but me making commits directly to the code. I took patches from people. We took patches over email. I think we used a wiki at the time. This was well before GitHub was created and made everything so easy. But I didn't expand the access to the code itself until, I think, almost a year in. At that time, we instituted the Rails core team, which were basically just a group of people who had sent me the most patches, who had sent me the best work. Those people got access to the code base, and amongst those people was James Buck. I remember being struck by just how excited he was about this project. He was very passionate about it. He never showed a line of Ruby or Rails code, that whole presentation. It was all about why he wrote it, what he was hoping to accomplish with it, which I think disappointed some people, especially those who had heard about Rails, maybe played with the very early releases of it. I think there were some there who were hoping for a little bit more of a technical presentation. But his was all about the charisma. His excitement and passion about the project was contagious. It was easy to see that this was something he was really excited about. And even then, I mean, this was 20 years ago, almost. You could see his idea that this was going to change. Vandermeer Hansen, who I had never heard of before, I had never heard of Ruby on Rails. It was brand new, just barely released. And he got up and was talking about why he wrote Rails. He really was pushing a better experience for programmers. And I remember him standing up there, holding an imaginary piccolo to his lips, and talking about how, like the Pied Piper of Hamelin, he was going to lead programmers to a better experience, a better way of living. For about the first year, there was no one else but me making commits directly to the code. I took patches from people. We took patches over email. I think we used a wiki at the time. This was well before GitHub was created and made everything so easy. But I didn't expand the access to the code itself until, I think, almost a year in. At that time, we instituted the Rails core team, which were basically just a group of people who had sent me the most patches, who had sent me the best work. Those people got access to the code base. And amongst those people was James Buck. I remember being struck by just how excited he was about this project. He was very passionate about it. He never showed a line of Ruby or Rails code, that whole presentation. It was all about why he wrote it, what he was hoping to accomplish with it, which I think disappointed some people, especially those who had heard about Rails, maybe played with the very early releases of it. I think there were some there who were hoping for a little bit more of a technical presentation. But his was all about the charisma. His excitement and passion about the project was contagious. It was easy to see that this was something he was really excited about. And even then, I mean, this was 20 years ago, almost. You could see his idea that this was going to change the world. James ended up then being the first programmer I ever hired at 37signals as Basecamp was taking off. And I remember reading James' Ruby code and just thinking, wow, this guy is really good. He just had such a methodical approach to it that I was in awe and I was eager to be able to work with him at Basecamp, on Basecamp. And that's how we got started. We hired the good number of the early people at 37signals were all hired out of the Rails core team or other folks who had been contributing to Rails. Something that was exciting about the Rails pre-release announcement is that it was coming from 37signals. I knew about 37signals and just the fact that they were dipping their toes into Ruby, like, it was interesting, like, it was really curious, like, why are they showing up here? This wasn't just somebody coming up with their favorite way to build web apps. It was somebody doing something in a 37signals way. And that the mark 37signals had made on the design world was showing up to the Ruby world of all places. It felt different and kind of odd and neat, interesting, curious, kind of odd. So it gave it kind of an instant reputation. You didn't know what it was yet, but the fact that it could power something like that spoke for itself. That reception was, of course, very warm and loving. This was a bunch of Ruby enthusiasts seeing something interesting happening in Ruby. The reception from the rest of the world was a bit more mixed. Of course it was. In part because when I went into full marketing mode for Rails, I was a little brash about it. I knew that the odds of creating awareness from something like Ruby, such an unknown programming language, couldn't just be a whisper. It had to be a shout. And I went out shouting. I did a bunch of controversial comparisons between Java implementations of certain problems and Rails implementations of the same problems that at the time were characterized as poking Java developers in the eyes. So of course part of that reaction, completely expected, was pushback. And this was why it was so helpful to have this one-two punch. A real application with real success and growth and paying customers in Basecamp. And just the code speaking for itself. Things like the 15-minute blog video and other write-ups contrasting what does it take to solve this problem in Ruby on Rails and what does it take to solve the same problem in something else. Here we go. So I hope you can read the text. The first thing we do is call the Rails command to generate... 2002 I moved from Germany to Canada. I tried to work for local companies in Canada right after and found out I couldn't because I didn't have a work permit and I had to work for these kind of things. So I found myself with time. My now wonderful wife suggested, you know, you've been talking about starting a company and this seems like an awfully good time to do it. I didn't feel that spark anymore during those times and what I decided I needed to do was reclaim programming as that passion hobby again. What I was looking for is some opportunity of, I'm going to build something that would allow me to make money while I go snowboarding and while I go program for fun. That was my plan. I've been extraordinarily unsuccessful on that particular plan because here's the way things happened. I decided because of all the snowboarding I was doing, I knew a lot about snowboarding. I was just like, you know, online stores, this seemed like the right thing to do. I couldn't find a good online store. It turned out that there wasn't good software to use. I tried to use different packages, they're all horrible. So I just sat down and said, okay, well, if I can use anything, like I don't have a boss anymore, I can use any technology no matter what it is. It just needs to respond to web requests. I remember thinking, man, I would just love to use Ruby. It's just this moment. I think the way I best explain it is I just realized my brain was running on Ruby since I started first programming. Shortly thereafter, I got just very lucky in that I was paying attention when what David must have for the first time started talking about him doing the thing I wasn't brave enough to do, right? Like building from scratch everything that's needed. This may well have been me sending a private message and him sending a zip file back. The details are a little bit hazy at this point, but he gave me access very early. I tried. I just fell in love with it. I was building Snowdevil. It took two, three months. I was certainly the only engineering team on planet Earth during this time who was doing this alone. Everyone else who was building online stores had a team of 100 people, and yet I was more productive simply because it's hard for people to understand this these days, but that is the difference of effectiveness of what Rails did, and it made it possible to build systems alone again. It just became a very natural thing based on just what I was seeing to take Snowdevil and turn it into Shopify afterwards. It seemed like the right thing to do, and you can clearly see the inferences in it. I love working on Rails. I love working on the tool. I love working on the technology. Being inspired by the tools that you use to reach higher than you thought you could or you were allowed to or what would be possible is rare and possible and underexplored, and in fact, literally what Shopify is attempting to do right at the end of the day. I don't remember us calling it a core team right away, but it kind of became that from those beginnings of Jeremy and me and David committing to the repository. It wasn't long before there were more committers, Marcel, Melina, Scott Barron, Sam Stevenson, some of these others, Michael Koziarski, these early Rails committers, and it really was a wonderful thing. I had never really been part of a team like that, but there was something about all of us having the same vision and working at such an early stage on something that felt like it was going to change the world. It was exciting. Being part of a core team meant that you had David's trust to build something on the quality bar that he owned. If you had an IRC channel specifically for that, that's where the real conversations were about what was Rails, what would Rails become, what would be the next features, and this has been going on for the last 20 years and is still active. We have much, much better tools these days with GitHub, thanks to another thing that grew out of Rails, but when we started Rails, there was no GitHub. The cost of having multiple people work on a code base was a much higher trust affair back in those days. That was a 10x environment, and I think David made it, created it for us. A lot of us came out of those early years as completely changed programmers afterwards. Rails, A, compelled me to realize what my potential was there, and it also gave me the ambition to reach high, because a lot of people's potential limitation is learned rather than inherent, and it gave me the configuration of my life by allowing me to be a programmer. I remember reading James' Ruby code and just thinking, wow, this guy is really good. He just had such a methodical approach to it that I was in awe, and I was eager to be able to work with him at Basecamp on Basecamp, and that's how we got started, that we hired The good number of the early people at 37signals were all hired out of the Rails core team or other folks who had been contributing to Rails. Something that was exciting about the Rails pre-release announcement is that it was coming from 37signals. I knew about 37signals, and just the fact that they were dipping their toes into Ruby, it was interesting. It was really curious. Why are they showing up here? This wasn't just somebody coming up with their favorite way to build web apps. It was somebody doing something in a 37signals way, and that the mark 37signals had made on the design world was showing up to the Ruby world of all places. It felt different and kind of odd, and neat, interesting, curious, kind of odd. It gave it kind of an instant reputation. You didn't know what it was yet, but the fact that it could power something like that spoke for itself. That reception was, of course, very warm and loving. This was a bunch of Ruby enthusiasts seeing something interesting happening in Ruby. The reception from the rest of the world was a bit more mixed. Of course it was. In part because when I went into full marketing mode for Rails, I was a little brash about it. I knew that the odds of creating awareness from something like Ruby, such an unknown programming language, couldn't just be a whisper. It had to be a shout. I went out shouting. I did a bunch of controversial comparisons between Java implementations of certain problems and Rails implementations of the same problems that at the time were characterized as poking Java developers in the eyes. So of course part of that reaction, completely expected, was pushback. And this was why it was so helpful to have this one-two punch. A real application with real success and growth and paying customers in Basecamp. And just the code speaking for itself. Things like the 15-minute blog video and other write-ups contrasting what does it take to solve this problem in Ruby on Rails? What does it take to solve the same problem in something else? Here we go. So I hope you can read the text. The first thing we do is call the Rails command to generate... 2002 I moved from Germany to Canada. I tried to work for local companies in Canada right after and found out I couldn't because I didn't have a work permit and I had to work for these kind of things. So I found myself with time. My now wonderful wife suggested, like, you know, you've been high, didn't feel that spark anymore during those times. And what I decided I needed to do was reclaim programming as that passion hobby again. What I was looking for is some opportunity of, like, let me, I'm going to build something that would allow me to make money while I go snowboarding and while I go program for fun. So that was my plan. I've been extraordinarily unsuccessful on that particular plan because here's the way things happened. I decided, like, because of all the snowboarding I was doing, I knew a lot about snowboarding. I was just like, you know, online stores, this seemed like the right thing to do. I couldn't find a good online store. You know, it turned out that there wasn't good software to use. I tried to use different packages, they're all horrible. So I just sat down and said, okay, well, if I can use anything, like, I don't have a boss anymore, I can use any technology, no matter what it is, it just needs to respond to web requests. I remember thinking, man, I would just love to use Ruby. Like, it's just this moment, I think the way I best explain it is, like, I just realized my brain was running on Ruby since I started first programming. Shortly thereafter, I got just very lucky in that I was paying attention when what David must have for the first time started talking about him doing the thing I wasn't brave enough to do, right? Like, building from scratch everything that's needed. This may well have been me sending a private message and him sending a zip file back. The details are a little bit hazy at this point. But like, he gave me access very early, I tried, I just fell in love with it. I was building Snow Devil, it took two, three months. I was certainly the only engineering team on planet Earth during this time who was doing this alone. Everyone else who was building online stores had a team of 100 people. And yet, I was more productive, simply because it's hard for people to understand this these But that is the difference of effectiveness, of what Rails did, and it made it possible to build systems alone again. It just became a very natural thing based on just what I was seeing to take Snow Devil and turn it into Shopify afterwards. It seemed like the right thing to do, and you can clearly see the inferences in it. I loved working on Rails, I loved working on the tool, I loved working on the technology. Being inspired by the tools that you use to reach higher than you thought you could or you were allowed to or what would be possible is rare and possible and underexplored. And in fact, literally what Shopify is attempting to do right at the end of the day. I don't remember us calling it a core team right away, but it kind of became that from those beginnings of Jeremy and me and David committing to the repository. It wasn't long before there were more committers, Marcel, Melina, Scott Barron, Sam Stevenson, some of these others, Michael Koziarski, these early Rails committers. And it really was a wonderful thing. I had never really been part of a team like that. But there was something about all of us having the same vision and working at such an early stage on something that felt like it was going to change the world. It was exciting. Being part of a core team meant that you had David's trust to build something on the quality bar that he owned. If you had an IRC channel specifically for that, that's where the real conversations were about what was Rails, what would Rails become, what would be the next features. And this has been going on for the last 20 years and is still active. We have much, much better tools these days with GitHub, thanks to another thing that grew out of Rails. But when we started Rails, there was no GitHub. Concept of having multiple people work on a code base was a much higher trust affair back in those days. That was a 10x environment. I think David made it, created it for us. A lot of us came out of those early years as completely changed programmers afterwards. Rails, A, compelled me to realize what my potential was there, and it also gave me the ambition to, like, reach high, because a lot of people's potential limitation is learned rather than inherent. And it gave me the configuration of my life, like, by allowing me to be an entrepreneur. When I first released Rails, it wasn't even a consideration not to make it open source. We had been building our business. Everything that I had worked on for the web had been with open source tools, and not to make it open source. We had been building our business. Everything that I had worked on for the web had been with open source tools. These were cornerstones of what enabled me to be able to work with the web. So when I finally had something, my own toolbox to share, I didn't even think twice about it. Of course this had to be open source. I remember one of the most fascinating conversations that I've had the pleasure to be part of in my life was a conversation, definitely David, I think Jeremy, like, I was part of it, and definitely a few others. And there was one where we said, like, hey, we are building companies, we are building important companies. They are working. We are clearly more effective with small teams than larger teams with lesser tools. Is open source the right model here? Like, A, shouldn't we check? These were cornerstones of what enabled me to be able to work with the web. B, should we even share that at all, or just, like, use it as a competitive advantage? And I remember asking, like, hey, how many lines of authorship have you put into your work? Okay, any ideas about making a company open? Except for what? Or how often you try to bring the data into the process, while still doing research, trying to work on open source projects, because who would ever draw in the data? was part of it, and definitely a few others. And it was one where we said, like, hey, we're building companies, we're building important companies, they are working, we are clearly more effective and small teams than larger teams with lesser tools. Is open source the right model here? Like, A, shouldn't we charge money for Rails? Should we even share that at all, or just use it as a company? Open source is important, in fact, MIT licensed open source is important. And open source is important, in fact, MIT licensed open source is important. And they're going to make Rails extraordinarily successful. And I'm like, I remember pushing this thing, hey, David, that's not something you can just sort of decide. Like, you can't just decide something is going to be successful. That is, like, an outcome that happens, that requires luck and all these components. And he said, no, we can decide this. Then this discussion happened, David must have been, like, 24, and I'm just like, I'm trying to figure out where you get that from at that age. It still seems remarkable, because I, you know, I'm now in my 40s, and I still don't run into a lot of people who have that kind of conviction and out-of-the-box meta understanding of markets, dynamics, attention, drama, and frankly, business development. I think I got a business degree during those years accidentally, playing out right in front of me while just trying to get work done that I wanted to get done. And so that's just remarkable, I'll say remarkable. When I was first hired by 37signals, they asked me, one of my first tasks was to create a way to deploy Basecamp. At the time, Basecamp was deployed to a single server, database and web server, all on one machine, which is laughable now. But shortly afterwards, they grew. And now we needed two machines, and we had to figure out how to deploy Basecamp to more than one server. And this became my baby. Jason and David actually told me, you can have ownership of this product. Even though you wrote it for us, this is your baby, you can do what you need with it. And that was extremely fulfilling to be able to work on this product called Capistrano. And that stuck. Yeah, there were some really key moments in early Rails development and Rails 1.0 was a big one, but it was the starting point of what makes a 1.0. There were some key moments after that, that really kept the sense of momentum. Rails 1.2 was a watershed for me, I still love that release. It was a very stable early release, we started having those glimmers of this is what it's like to be a kind of mature web framework. And I still feel excited thinking about the audaciousness of, we're just going to switch the way we do development. And everybody's along for the ride, and everybody wanted to be along for the ride. And it was that same year, December 2007, when we released Rails 2.0. Rails 2.0 brought cookie-based sessions, brought things like named scopes, so it started to be successful. And I'm like, I remember pushing this thing, hey, David, that's not something you can just say. Well, there was a look at what it looks like to see our products and applications mature. One of the big criticisms of the detractors of Rails back in the day was that Rails can't scale. That was their mantra. They would chant that at us all the time. And we could point at Basecamp and say, this is non-trivial, we're not doing a million requests a day, but we're serving people's needs, we're providing value, isn't that, at the end of the day, isn't that the important thing? So even though at the time people poo-pooed our accomplishments, they were accomplishments nonetheless. And we never reached a point where we were like, oh, well, I guess Rails can't scale. We've reached a number where we can't go beyond it, we're done. We continue to be able to scale. It actually became a bit of a meme joke, but will it scale? This was a serious thing that people said in the early days of Rails. But that question wasn't so much about technology as it was about FUD. Fear, uncertainty, and doubt. People who saw an interest in putting Rails down would often bring up scalability because it was something you could throw out there before Rails had major applications like Shopify, like GitHub, or even like Basecamp at the scale it's at now. It never really had a foundation in reality. Rails was essentially scalable from day one. I guess people took this pretty seriously. Some people so seriously that they would rewrite the system at some point, as well documented in some cases. You know, making things fast is pretty fun. It's like, if you use the right algorithms and data structures, we know how to make computers really fast. My personal experience, Shopify is a significant percentage of internet traffic. It's about 10% of e-commerce global. It's a large code base, a very large code base. By the way, if you would look at it, same folder structure as any Rails application that you would just generate on your laptop right now. It's on the latest version of Rails. So most of the lines of code of Shopify are in Ruby. We are not religious about using Ruby. We use the best tool, and Ruby's the best tool for a lot of the types of problems that are being solved by the thousands of engineers around Shopify. Shopify's pretty fast. It's totally doable to build. I don't know who is supposed to see the kind of scale that you couldn't handle with Shopify. We have unique complexities that most people don't face. What's harder to scale than performance of web servers? Finding foundational ideas that scale for 20 years and still feel good. That requires a level of foresight. You don't get it. That do-over is very, very hard to get. On the security side, it was a bit more tricky because there were things we needed to do explicitly to prevent common attack vectors. And we made a bunch of concerted efforts to ensure that security was a thing you could just rely on Rails being good at. The next big release for me was Rails 2.3 in March 2009. A little bit longer and a lot more depth. A release that felt like Rails had arrived. This framework had everything a modern web developer needed to develop small-scale, large-scale apps and everything in between. At that time, jQuery was coming on the scene and we were bound and determined to make room for it. There was energy happening in the JavaScript world and Rails wanted to meet it where it was arriving. After Rails 2.3, we had everything we needed. The toolbox was full. We were happy with the way all the tools behaved. There weren't gaps among them. We didn't have too many tools. It felt like we were at the sweet spot for web development. Where do we go from here? There was a new Ruby web framework on the scene called MIRB. Rails 3.0, that was a merge with MIRB, right? Holy hell, that took some doing. Oh my god. By the way, has this ever happened? Have frameworks merged ever and became just better? That's a singular story too. We had a competitor. MIRB came on the scene as a young upstart Ruby framework that challenged Rails by being faster, lighter, slimmer, doing less. Kind of the Rails to Rails itself. It lit a fire under us as Rails developers. We wanted those things too, and we felt like we had an outcome that worked for us, luck in all these components. And he said, no, we can't decide this. Then this discussion happened. David must have been like 24. I'm trying to figure out where you get that from at that age. It still seems remarkable, because I'm now in my 40s, and I still don't run in a lot of people who have that kind of conviction and out-of-the-box, frankly, business development. I think I got a business degree during those years. Our team showed us the way. We put a significant effort into re-engineering the internals of Rails to be configurable, recomposable, modular, so that you could build a framework like MIRB from it. The Rails and MIRB teams talked and decided to merge together. This Ruby approach, this Rails approach, for some people, not all, not most, it's not better. But for some people, it is a hundred times better. It's not a bit better. And this is why you see the bifurcation about this thing. This is why you see the love and the hate, and very little indifference. Most technologies were done that I wanted to get done, and most of the spectrum is indifference, because it's not relevant to you that this exists, or is good or bad, it doesn't matter. Rails, people have very strong opinions about, because it comes from a different place. And I think that's precious and exciting. It's been, you know, honestly, like an honor to be part of it, just like, again, it's been important. I know these terms are so weird. It's so weird to talk about an honor to hang out in an IRC channel that you got invited to, but man, it was, like, this is, it was special, that I would be a completely different human being at a completely, life would not have gone the way it did if I wouldn't have, some of those dots I'm now looking at, and can connect in a way of a mirror, would have gone any which other, into another way. So I'm deeply thankful for that. Just the community that we were building, the friendships that we shared, and it's like, we had always been this team. It just felt so natural and so exciting, and I had never had anything like that before, to that degree. And it was, it was really fulfilling in a way that nothing had fulfilled me before. Seeing the Rails community grow and seeing everybody, seeing others have that kind of experience of it's all, it's theirs, it's individual. Each person has the opportunity to be in a place where I was, and I can help create an environment that's, that's there for them, and supports them, and, and respects them. But that's all I can do. And I have just, I have a deep appreciation for others being able to share in that with me, and whatever small part I've had. One of my first tasks was to... Things like Rails, things like Basecamp, things like 37signals, you can't plan these things. These things don't happen because you set up a business plan, or something in advance. These things unfold, and like anything that unfolds, it needs time to unfold. And I think that time proves these things out to some degree. As it says on the website at the moment, Rails really does allow you to go from Hello World to IPO, with a tiny team as you get started. We have a one-person framework where a single developer is able to make a huge amount of progress in a miniscule amount of time. The community, the framework, the code base has never been in better quality than it is today. I have so much respect for what David has built, and what David's approach to leadership. I love it, hate it, and do not deny its effectiveness, and do not, and this is important, ever, ever think that Rails is what it is, despite of anything David does. It is what it is, it's as successful as it is, it's as good as it is, because of everything David does. These things are not separatable, there is no Rails without David. Ruby on Rails is full of people who were not trained to be computer scientists, who were not trained to be programmers, who came from all walks of life, who simply developed an interest in creating web applications, were able to learn how to do it with Ruby on Rails because it was easy, because it did not require this extensive background training to get something going. Ruby on Rails has from the outset focused on making it simple to get started, because if you can't get started, you can't keep going. That initial wall, for so many people, is so tall. I faced that wall myself when I was trying and failed to learn programming several times in my life. Ruby on Rails has to have this kind of slope. You start down really low, really simple, having to learn very little, and then you can go all the way to become the top goals. I love that part of Ruby on Rails, I love the diversity of the people who've been able to create a career in programming because of this framework that we've created. Thousands of developers find jobs across Europe using Honeypot. If you're up for a new challenge in one of these European cities, sign up at honeypot.io. If you want to see more tech documentaries, then subscribe so you don't miss the next one. Which is laughable now. But shortly afterwards, they grew, and now we needed two machines and we had to figure out how to deploy Basecamp to more than one server, and this became my baby. Jason and David actually told me, you can have ownership of this product, even though you wrote it for us, this is your baby, you can do what you need with it, and that was extremely fulfilling to be able to work on this product, called a Capistrano, and that stuck. There were some really key moments in early Rails development. Rails 1.0 was a big one, but it was the starting point of what makes a 1.0. There were some key moments after that that really kept the sense of momentum. Rails 1.2 was a watershed for me, I still love that release. It was a very stable early release where you started having those glimmers of, this is what it's like to be a mature web framework. I still feel excited thinking about the audaciousness of, we're just going to switch the way we do development, and everybody's along for the ride, and everybody wanted to be along for the ride. It was that same year, December 2007, when we released Rails 2.0. Rails 2.0 brought cookie-based sessions, brought things like named scopes, so it started to change the way that, well, it was a look at what it looks like to see our products and applications mature. One of the big criticisms of the detractors of Rails back in the day was that Rails can't scale. That was their mantra. They would chant that at us all the time. We could point at Basecamp and say, this is non-trivial, we're not doing a million requests a day, but we're serving people's needs, we're providing value, isn't that, at the end of the day, isn't that the important thing? Even though at the time people poo-pooed our accomplishments, they were accomplishments nonetheless. We never reached a point where we were like, oh, well, I guess Rails can't scale. We've reached a number where we can't go beyond it, we're done. We continue to be able to scale. It actually became a bit of a meme joke, but will it scale? This was a serious thing that people said in the early days of Rails. But that question wasn't so much about technology as it was about FUD, fear, uncertainty, and doubt. People who saw an interest in putting Rails down would often bring up scalability because it was something you could throw out there before Rails had major applications like Shopify, like GitHub, or even like Basecamp at the scale it's at now. It never really had a foundation in reality. Rails was essentially scalable from day one. Those people took this pretty seriously. Some people so seriously that they would rewrite their system at some point, as well documented in some cases. Making things fast is pretty fun. If you use the right algorithms and data structures, we know how to make computers really fast. From personal experience, Shopify is a significant percentage of internet traffic. It's about 10% of e-commerce global. It's a large code base, a very large code base. By the way, if you would look at it, same folder structure as any Rails application that you would just generate on your laptop right now. It's on the latest version of Rails. Most of the lines of code of Shopify are in Ruby. We are not religious about using Ruby. We use the best tool, and Ruby's the best tool, for a lot of the types of problems that are being solved by the thousands of engineers around Shopify. Shopify's pretty fast. It's totally doable to build. I don't know who is supposed to see the kind of scale that you couldn't handle with Shopify. We have unique complexities that most people don't face. It's harder to scale than performance of web servers. Finding foundational ideas that scale for 20 years and still feel good. That requires a level of foresight. You don't get it. That do-over is very, very hard to get. On the security side, common attack vectors.