Big Think Interview With David Heinemeier Hansson
David Heinemeier Hansson is a Danish programmer and the creator of the Ruby on Rails open source web development framework. He is also a partner with Jason Fried at the web-based software development firm 37signals. In 2005 he was given with the Hacker of the Year by Google and O'Reilly award for his creation of Ruby on Rails. He and Fried have also co-authored the New York Times bestseller "Rework," which reveals their secrets for boosting business productivity in the Internet age.
Question: What inspired you to create Rails?
David Heinemeier Hansson: Rails really started as an application. It never started as Rails. It just started as me wanting to build Basecamp in this new program language—new to me program language—called Ruby. And as I was starting to build a Basecamp, our project management tool at 37Signals, I found a need to just build a bunch of tools for it. I had to have something to talk to the database, something to generate some HTML. All these things I weren’t finding good existing solutions for in Ruby, so I basically just had to do it myself.
And what I found was someway, halfway into the creation of Basecamp that I had this big toolkit now. I’d been building all these little things that I needed as I needed them, and now I discovered that I had a whole toolkit. And I also discovered that I like programming now so much better than I ever had in the past. So what was making me happy about this? Well, first of all, obviously, the Ruby language, but also all these tools I’d built for myself. They just felt just right in a way that no other programming language or environment had before.
So I started thinking: hey, if I’m having so much fun building with these tools, building with Ruby and then what became Rails, it can be selfish not to share that. All the things that we build at 37Signals are built on top of open source tools. We use Linux, MySQL, Ruby itself. All of these infrastructure components are open source; they’re free, and you can use them, you can change them, you can do whatever you want. So it kind of feels like once you’re in that world, you’d be an ass if you just developed something you liked a lot, and then you just kept it to yourself. Like, “This is my toy, and nobody else can play.” So that seemed like a bad idea.
So about halfway through the development of Basecamp I just realized I’m going to release this. I’m going to put it out into the world, but, before I do so, I want it to be good. I’d used a bunch of software that I found really, really frustrating to get into because either the documentation was bad, or the examples were lacking, or it just didn’t feel polished. So I wanted Rails to feel really polished. I wanted it to have great documentation, be easy to get started with and get into, so I actually waited about a year from when I decided I was going to release this, until I actually did. And it wasn’t until that year later where it felt good enough for somebody else to use.
Question: If you were to start again, would you choose Ruby as the basis for Rails?
David Heinemeier Hansson: If I had to do Rails today, I would absolutely choose Ruby. Since discovering Ruby, I really haven't been all that interested in other program languages. It's kind of funny; when I used to develop in PHP or the stuff I did in Java, I was always looking for something else. I was always looking for another programming language, another... just something else, in part just to distract me from being bored in the languages I was in.
But with Ruby it was kind of different. Ruby right from the beginning just fit like a glove. It was this magic language that sort of like your thought's been waiting for. Like this was the language that was going to express what I have to say in such an eloquent way that I'm frequently just astonished. I'll write a piece of code and look at it and say, “Geez, that's beautiful!” And I would not have that reaction before, just because other program languages just to me don't have that emotional appeal. Ruby has just a deep emotional appeal of how beautiful you can write something. It feels much closer to my thought process. It feels like I'm expressing exactly what I want to say in code without translating it. Usually you call it code because it's sort of hard to read and hard to understand, but Ruby really shouldn't be called code because it's much closer to human thought than code is.
Question: What exactly is the relationship between Ruby and Rails?
David Heinemeier Hansson: Ruby is sort of the basic language. You can say anything in Ruby. You can talk about anything in Ruby. There's no limits to that. Rails is much more like a genre, so rails is like "thrillers." Like, if you want to make a thriller, you use Rails for that. If you're using something else, if you want to write a love story, then you probably use another framework or something else entirely. Ruby is great for both of those things, but Rails is really the tool that sits on top of Ruby that just makes Ruby great for web development... talking to a database, outputting, HTML, putting all these things together and making great web applications.
Question: What makes Ruby a special language?
David Heinemeier Hansson: To me good programming is just like good writing. It's succinct. You're expressing what you want to say in as few words as possible. You're picking just the right words for the sentence, and it's sort of a grand thing. A program is just like an article or a book; it's composed of tiny things like words that form into sentences, and paragraphs, and chapters, and so forth. A programming language—a good programming language—allows you to build a program in just the same way.
So you'll have methods that are really short. A big part of what makes Ruby so special to work with is just how much expression you can pack into few lines of code. When I compare it to something like Java where it takes perhaps ten lines to express a very simple operation, that same operation can be expressed in a single line of Ruby. And that just makes understanding the entire program that much easier when the density of expression is so much higher, and it's not just because it's short. There's plenty of programming languages where you can write exceptionally short code, and it's completely unreadable afterward. Ruby has this uncanny ability to just be shortened the same way your thought would be short, but no shorter than that.
The other part of it is also having a grand or free mode of expression that there are many different ways that you can say something. So for example: Lots of programming languages have—or all program languages have—conditionals. If something is true, do this. Now, sometimes you want the positive version of that. Like, “If employee works here, then print this screen.” Sometimes you want the opposite. In most program languages, you would go about that by saying, “If not programmer works here, then do this.” That's not a very natural way of expressing that. You would never say that in real life.
In Ruby, you can say, “Unless the programmer works here, do this.” So it's just all those little things where the creator of Ruby thought about the whole picture. It's not just that you can get something done. All programming languages can do the same things. There's nothing you can do in Ruby that you couldn't do in some other programming language. What makes Ruby special is how you say it.
Compared to natural languages, I think there's also just something to the tone and they rhythm of it. I'm Danish. I speak Danish, and I admit that Danish is not a very pretty language. Thankfully, it's not as ugly as German, which I think is probably one of the ugliest languages of all time. But if you compare something like German to something like French, you don't have to speak either language to hear that French is obviously the prettier language.
I think if somebody who doesn't even know code, they can look at a piece of Ruby code, and they can appreciate that Ruby is French and Java is German. That's sort of really the appeal to it. Because you have to work with this stuff all the time. Programmers often work for many, many, many hours a day, and this is your main mode of expression. It has to be good. If it's not good, if you're speaking in an ugly language every day for eight or ten hours a day... well, I won't say that it turns you into an ugly person, but I like to just surround myself with beautiful things. Ruby is beautiful; lots of other programming languages are much less so.
Question: Do programmers need to like the languages in which they code?
David Heinemeier Hansson: I think in the past, programming languages and environments have been determined by everything but the beauty of expression. It's been determined by “We have to make this really fast. We have to make this really efficient. We have to make this really logical. There has to be only one way of doing things.” All of these other concerns that you would think about when you would think about somebody approaching it in a very sort of binary approach. That's sort of the best way I can express it.
Ruby comes from a much different angle. In fact, the creator of Ruby said that his main goal of creating Ruby was to make programmers happy. Now, you're introducing something that in many ways seems like a foreign concept. You're talking about code. What does happiness have to do with anything? How does happiness play into this stuff? It absolutely does because programmers—surprisingly enough, I'm sure to a lot of people—are humans, too. And humans just respond to emotional things. They respond to beauty, they respond to a general sense of well being and liking your tools. It's not enough that your tools can get the job done. It's how they get them done. It's whether you like wielding those tools day out and day in.
And I've talked to a lot of Ruby programmers who came to sort of the edge of their career thinking they've been working in Java, or C-Sharp, or some other language that was just driving them miserable. And they were thinking, “You know what? I know how to do this stuff, but it's probably not for me. I'm not happy working with these languages or environments every day. I'm going to quit.” And then some of them found Ruby. And it almost sounds cheesy as sort of a religious experience that they find this program language that all of a sudden makes it interesting for them again to be programmers. But it's absolutely true. I felt exactly the same way. I was absolutely not convinced that I was going to be a programmer when I was working with PHP and Java.
To me, at that point programming was just something I had to do to get programs. It was sort of just a functional thing I unfortunately had to go through in order to realize the ideas that I had for programs. For me, Ruby just changed that such that the act itself was pleasurable. And I think that's just a magic moment. When you change over from not just being able to do the job to actually enjoying the job. That's just a huge difference. And I think that the product in the end also reflects that. The programs I write now are much better than the programs I wrote when I didn't like my tools.
Question: Ruby on Rails lowers the technical expertise necessary to create a web application; is expertise becoming less critical?
David Heinemeier Hansson: I think Ruby on Rails absolutely lowers the bar in terms of what it takes to get a web application going. Some people see that as a negative thing. Like, “Oh, the barbarians are at the gate” or “We've got all of these unwashed masses flowing into our beautiful, pristine programming communities.” I've heard things a lot of times before. Visual Basic before that was chastised for bringing in sort of "unpure" programmers. I think it's bullshit. There is no such thing as the "pure" programmer, and I think that what's magic about the Ruby in Rails community is exactly that it attracts people from all different camps, that it attracts people who are not primarily programmers. I find that often the best ideas come from people who are not programmers, people who bring just an entirely different perspective on things.
In fact, being a newbie is such an important stage because that's where you question everything. When I first came to Ruby, I questioned everything. I was like, “Why doesn't this thing exist? Why is this hard? That's stupid. We should change that.” You have this sort of initial naïve approach to things that makes it impossible for you just to see what should be impossible. You just do.
If I had known in the beginning how much work it would have been to actually create Rails, I probably would never have started. I started because I just found one little thing that to my naive newbie sense seemed easy to do. I think it's really important that we keep this flow of new people, new blood, fresh blood coming into the community, and I also think it's wonderful that we're creating a larger group of people who can create applications. Trying to have protectionism is never a good idea. Trying to sort of set up, like there should only be these carefully trained programmers who are able to make programs... Bah. That's not how it should be. We should absolutely have programmers of all kinds. Some of these programmers will be new, and they won't know everything, and they'll create shitty programs. But you know what? Most of the time, a shitty program solves the problem. You don't need perfect programs all the time. There are so many problems in the world that the tiny group of pristine, white knight programmers just can't solve. They can't solve all of them; there's just not enough of them. So we need programmers of all levels to solve the programming problems of the world.
Question: How simple can things get in terms of programming?
David Heinemeier Hansson: So, for me it's really there's two angles to this. There is we can absolutely make things simpler. I think I made a lot of web development a lot simpler with Rails. But there is a natural physical limit where at the end programming is just choices. How should the program work? What should happen when you click this button? Those choices are ultimately what's the key to programming, and you can't get out of that, which is also why I think that sometimes it's a little bit of a pipe dream to think that there's going to be these magical new environments where somebody who knows nothing about programming will just be able to drag and drop a few things into a box, and then, voila!, you will have the most amazing program in the world. No. It's really not gonna happen like that because to have the most amazing program in the world, you need to care about a thousand decisions, and recording those thousand decisions takes a programming language.
So, there is a lower limit to how simple it can get, and that lower limit is, “Do you care about these decisions?” Once you... All the decisions you care about have to be codified somehow, and I don't know of any more effective way of doing that than with a great program language. So I'm not a big believer that at some point we're all going to create these wonderful applications. There will be a class of applications where you design a niche and say: okay, if I have to just slightly tailor some accounting software—yeah, there can be something simple for that. But if you want the freedom of expression to create any type of web applications today, you need a tool that's expressive enough to enable that, and that is a programming language. It doesn't get any simpler than that.
Question: Last year, you merged the Rails and Merb teams. What has that process been like?
David Heinemeier Hansson: So, I think the merge of the Rails and Merb teams have gone exceedingly well considering what led up to that. What lead up to that was a fair amount of petty and fighting, to be honest. Potshots at crossbow from one camp to another, and it was just bad. And it was useless. What we're here for is moving, sort of, in some ways, the state of the art forward. Why waste time on these petty concerns?
So, I think after the merge we realized that most of those petty squabbles were really just that; they weren't deep philosophical differences. We actually wanted the same things. We were perhaps speaking slightly different languages to each other, and misunderstandings and all the other stuff that goes on when you have sort of two camps working against roughly the same goal... But what we realized was that once it got down to the code, once it got down to the decisions that were really concrete about “How should this work?”—we were in agreement. There was no big philosophical battles back and forth. Once it got down to code we just all magically agreed.
I think that that has worked really well, and I'm incredibly proud of the product that's coming out of that, which is Rails 3, which we're just on the verge of releasing. It's been sort of a long walk to get there, but that's fine. Rails 2, as it is today, works great. There is no immediate rush to get to Rails 3, and now that we're almost here it seems... yeah, it was worth the wait.
Question: When will Rails 3 come out?
David Heinemeier Hansson: Sure. So, we're incredibly close to releasing the final version of Rails 3. Actually, right now we have sort of an internal target that's this week for the release candidate, and then however long it takes after that to get the final version out. But there's already plenty of people who are using Rails 3 in production. At 37signals we have at least a handful of applications that are already running the development version of Rails 3, so we're essentially there. We're dotting the i's and crossing the t's and just making sure that everything is really nice exactly because there is not that... there's not an external push or rush on us. There's no trade show that we have to make, there's no big revenue coming in when we actually release it. It's just mostly for pleasing ourselves, so it just has to be good, and we'll wait until it is, but it looks like we're finally there.
Question: What’s your take on Microsoft’s web platform versus Rails?
David Heinemeier Hansson: So, it's actually been a very long time since I've played around with Microsoft's web offerings myself. I did some ASP back in the late 90's, and then I've been sort of paying attention to C-Sharp and what my fellow Danish countrymen, Annis, Heims, and Burke, have been doing over at Microsoft, and there's definitely some good stuff from their perspective. From that perspective of developing a programming language, and a framework, and the tooling, it's pretty good. It just happens to be that I don't share that perspective.
I don't believe that programming languages need to rely on heavy tooling in the sense that Microsoft does with Visual Studio. I believe that program languages and frameworks should be incredibly pleasurable to write if you have nothing but a text editor. To me it's sort of a crutch when you have to rely on tooling on top. It reveals to me that the underlying language and platform is not succinct enough, it's not expressive enough. So there's just a difference of philosophy there. There's pros and cons, though. There's absolutely pros to the heavy IDE, Visual Studio, assistance, and completion, and all that stuff. It's not that either is completely bad, and the other is completely good. It's just that I enjoy much more that simple, closer to the metal so to speak, approach that we've been taking with Ruby in Raills.
So, it's also funny, though, to see them take inspiration. They've launched an NBC framework for their platform that is heavily inspired—let's say that—from a lot of the ideas that we've had fun with in the Rails camp, and that's great to see. It's great that we can all share ideas. We're all standing on the shoulders of giants, and ideas should move around. I don't think it's anywhere close, still don't. I mean, they've borrowed some good ideas, and that's great, but we still have an incredibly different approach to things. So, if you like the Rails approach to things, I don't think you're gonna be satisfied with the Microsoft expression of that, but that's fine. We don't all have to be the same. Not all programming languages have to be constructed the same. In fact, it would be boring if they were. So the world is a pretty big place. There's plenty of room for many approaches.
Question: What is Microsoft doing to compete with popular open source frameworks like Rails?
David Hansson: So I think the economic motive for Microsoft for doing all this is very clear. They want to sell Windows and they want to sell SQL Server and they want to sell that entire stack of stuff. And that entire stack of stuff doesn't have a very good track record of working well with the other side of things, the open source side of things. So if that's not true, then you pretty much have to do everything yourself. I find that most Microsoft shops are exactly that, they're Microsoft shops. They use Microsoft from top to bottom, everything is Microsoft. It's Microsoft version control, it's Microsoft database server, it's Microsoft web servers, it's Microsoft development languages, it's Microsoft everything. And they get some benefits of sort of the virtual integration from that, but it also makes the community very insular, in my mind. I've met a fair number of Microsoft people who just know a lot about Microsoft stuff. And I mean, that's fair. It's just not the same kind of people that we really associate otherwise.
Versus on the open source side of things, like I talk to plenty of people who work in Python or other languages or frameworks, there's much more, I think, sharing of ideas between the different camps on, that are the line. Like, it's sort of pretty much open source or not open source. If you're in the open source world, you talk to other open source developers and look at other open source solutions. If you're on the sort of proprietary closed, whatever you want to call it, Microsoft-side of things, you just stay in your own camp.
So it makes perfect business sense to me for them to devote all this time to it. I don't know if it makes business sense for a lot of shops to choose that. Most of the time, it doesn't seem to pan out, like I would never want to start my business using stuff that would add up to heavy, heavy license fees. Once you get into the open source mentality and mindset, there's just something almost offensive about that. Just saying, like, "I don't want to be locked in to somebody else's platform that I can't actually change." It comes down to sort of a fundamental sense of freedom. Do I have the freedom to change and switch out and substitute the tools that I'm using with? Or am I bound to some master? And I picked what I find to be freedom in that sort of dichotomy, even if it's a little contrived.
Question: Will Microsoft continue to be dominant in 10 years?
David Hansson: I think that Microsoft is still a huge and profitable company and will be for a very long time. I think that they're dying by 1,000 cuts, but those 1,000 cuts might take 1,000 years to inflict a mortal wound. What I enjoy most, though, is unlike the '90s, where you had to care, and almost fear, Microsoft, that they were the big bully and they could control everything, today, for me, they're irrelevant. I don't care. They have no bearing on what I do. I don't have to use any Microsoft technology, I don't have to use Windows for this or any of their tools for that, and in fact, I don't, and haven't for a very long time. I sort of still have to care about Internet Explorer and making the web apps I create work on their stuff, but even that is becoming less of a concern. Gone are the days of Internet Explorer having 95% market share, long, long gone. Now, it's just sort of a nuisance. "Oh, crap, we have to deal with IE6, oh, all right." But, there's a big difference between fearing the 800-pound gorilla and then just waving at flies. Oh, these are annoying flies, get out of my face.
So, to me, I don't know. I've talked in the past about, it kind of feels sad. Like there was something interesting about having that evil empire there. There was something, a rallying cry, actually, for the open source movement, or we're against the evil Microsoft people. And now, they're not there any more. The evil genius has left the building and now you just have a sales organization that pushes stuff out to grey boxes and corporations that I really don't have to deal with that much. So, it's more just, for me, sad that they've been relegated to irrelevance, from my perspective. I'm sure they're still relevant for a lot of people that have to use it or even, heck, enjoy using it. Weird that might sound from my perspective, but again, big world, lots of room, no longer do you have to fear the gorilla, so that's good. We can just go on with our business and not worry about them coming in and stomping on stuff.
Question: Do you think any company can dominate the Web the way Microsoft dominated computers circa 1992?
David Hansson: I think the wonderful thing about the web is just that it's a level playing field. There is no one company that controls it, in no important way, like it used to be in the past, with the Windows monopoly, or it is today in some senses, with some of the iPhone, iPad, or Android platforms. On the Web, you work for nobody else. On the Web, you work for yourself. And you can pick the tools that you please for it. That's why Ruby and Rails happened for me. If I had had to build OS10 applications, or Windows applications, I would have had to use the tooling that those masters provided me with because that's usually how it goes. Yeah, you can develop with something else, but if you want that native, good experience, you damn well better use their tool and go in and be a sharecropper in their field.
On the Web, there's no such thing. It's an open standard. As long as you can generate HTML, which is something that everybody has sort of agreed upon how it should be read, you can use whatever you damn please. So that's really special. And I think that we sometimes take that for granted. It's easy to forget that it didn't used to be like this. It didn't used to be so open and so free where you could just anything you wanted and the user wouldn't care in the end. You can make the best web application in the world with any program language in the world, which is just incredible freedom and incredible freedom for innovation. New upstarts, new frameworks, new languages, they can all play on the same field. And there's nothing that sort of holds them back or makes them second-rate citizens.
Question: The trend now is towards client-side applications, but Rails deals primarily with server code. Does Rails need to evolve to keep up?
David Hansson: So Rails have actually been interested in the client side for a long time. When AJAX sort of first got its initial push, when it got its acronym, back in, I think, 2006, Rails was one of the first server-side frameworks that said, "This is going to be huge and we're going to do something about that." So we put a Java script library straight in the Rails distribution prototype and we built a bunch of helpers around that to make it easier to create AJAX applications with Rails. And today it's almost inconceivable that you'll build a new, modern web application that doesn't have some aspect of AJAX in it.
Now, some people go a lot further than just having some aspects of AJAX in it. Some people have their entire application in Java script and just use the back end as a data store for that. I don't find that development experience that pleasurable. I have come to tolerate Java script now that there are great libraries and frameworks like Prototype around it to sort of make it a little more pleasurable, but it's still no Ruby. Ruby is still my first love in terms of programming languages. And however much you paint up Java script, it's not going to beat that. Which is fine.
So, from the development side of things, I don't enjoy Java script programming nearly as much or in the same league as I enjoy Ruby programming. Okay, fine. On the client side of things, like is this better for the user? I think there's something special and appealing to me about the mix, the mix of how the web is discreet pages and you use hyperlinks to jump from place to place and AJAX is sort of sprinkled across to make certain common operations a little faster. I tend not to like very heavy, single-screen-based web applications. They can be fine for some things, but I think the Web has this unique category of applications that fit into that sort of middle ground between one screen, or mainly one-screen applications and static web pages. And that's an awesome sweet spot and I think it works incredibly well for a wide array of applications. And I wouldn't want them to be any different. There are certainly some people developing for the web who long for the days of the desktop application and finally see that now AJAX is bringing that back. Well, we've heard that story a lot of times. First it was Java that was going to do this, applets were going to bring back the desktop experience and we could get rid of this nasty HTML. Then it was Flash that would bring this forward. And now AJAX or anything else like that. There's been so many attempts to bring the desktop to the web, and none of them have succeeded in becoming the dominant approach to building web applications, and I think there's a good reason for that, because that's not what users want. Like that sweet spot in the middle is great and it's actually desirable on its own terms.
Question: Will cloud computing take over completely?
David Hansson: Google is certainly trying to bring about the day where you can just have a dumb computer and everything happens in the cloud. I don't know if that's even desirable yet. I don't know why it has to be either/or. There are certain types of applications, especially information-based or network based applications that are just great on the web. Like editing your, say, movies or pictures? Why does that have to be online? Why does the act of doing that itself have to be online? If there's not a big benefit to that, then I don't see any particular reasoning to forcing it to be there. It's fine to have local applications, too. And we don't need the either/or's. We can take the best of the web and the best of the collaboration that that enables and enjoy that, for all those applications where that's a good fit. And then we can use the awesome local, graphical power and computing power of a modern computer to do those other heavy things. I think that that split, that duality is just fine.
Question: What do you make of Apple’s mandate that all apps for iOS devices be written in specific languages?
David Hansson: Apple really let me down, personally. I take personal offense when they started mandating that there are only certain languages and certain platforms that you can use to develop iPhone and iPad apps. It just seemed like such a—and I am overstating this and I know that that's sort of not helpful for the debate, but I can't help it—fascist move. It seemed entirely unnecessary to exert that level of control. To force people into that. Because the fact is, they're winning on their merits. Control and heavy-handed operations like that is something you do when you're desperate. That's something somebody backed into a corner would do. That's something, we used to think that was the stuff that Microsoft pulled and everybody was up in arms about that. We already love Apple! We love Apple on their merits, because they produce superior hardware and software. Why can't they just be confident that we'll continue to do that and if their tools are so wonderful and so magical, of course, people will use them. I find it just absolutely offensive that they would want to dictate, to enter the Magic Apple Kingdom, you can only speak German, no Frenchmen allowed here. Like that just seems—why?
I mean, I read the supposed reasons for why this would happen, oh, if we allowed cross-platformed tools then only shitty applications will be made, blah, blah, blah, blah, blah. Have you so little faith in the marketplace? Have you so little faith in the great native applications winning? Why can't you just see what happens, so if people create cross-platform applications and put them out and they're shitty, nobody will use them, nobody will buy them. It just seems like such an insecure move. And I also think it's incredibly ironic when you look at what Apple does themselves. When they released iTunes for Windows, did they follow all the Microsoft standards, did they use Microsoft development tools? No they didn't. They brought over their cross-platform stuff and they made iTunes work on Windows because of that. And sometimes that's what you do. Apple probably wouldn't have done iTunes, or I don't know, maybe they wouldn't have done it as fast if they had to build it from scratch, even though that from scratch would've been better because iTunes on Windows is supposedly sort of a shitty experience.
And there are plenty of other examples of applications that are great cross-platform applications. Firefox, for example, the majority of the code basis is cross-platform and it's a wonderful application. LightRoom from Adobe is a great application, it works great on multiple platforms. So if great applications can be created, then why would you shut those out just because it's also possible to create shitty stuff?
And now, sort of, I don't know, third or the fourth point against this, the app store is already full of shitty software. There are 200 or 300,000 applications in there. Do you think that they are all creampuffs? That they're all wonderful pieces of unique, beautiful software? No, they're not. Tons of them are just shitty crap. So the argument that Apple is doing this to increase the quality of the app store just falls flat when you look at all the junk that's already in the app store. This is not a carefully selected gallery, this is just a warehouse of shit. So don't give me that.
I think what happens here is power corrupts and absolute power corrupts absolutely. And just as well, market share corrupts, and absolute market share corrupts absolutely. Apple enjoys incredible market share of smart phones with the iPhone. So they can do stupid shit without it costing them everything and they can perceive that because we can, because we're able to force people to work this way, that's a good thing. That's a very short-sighted approach to things. Remember, that's how Apple came into be. The Apple camp is full of Microsoft refugees, people who were tired of being haunted by Microsoft, tired of being forced and controlled into certain ways of working.
It might work in the short term, but it doesn't seem like a long-term play to me. And again, it seems like such an unnecessary thing to do! When you already have the greatest stuff in the world, you don't need to do this stuff. So it was just a massive let down from a company I otherwise love. Which is why it stings double. If it was just somebody I didn't care about, didn't give a shit about, then who cares? This is Apple. This is the same Apple where I frequently cherish their products so much. Like, I really love so much of the stuff that they're putting out that it hurts double bad when they're doing stupid things like this.
Question: Do you see this and the iPhone 4 antenna fiasco as chinks in Apple’s armor?
David Hansson: I think that Apple currently is so good at what it does, so good at the hardware design, so good at the vertical integration of making everything just work, that they will survive this. Unfortunately, because I think that that's sort of the, it's the pros and the cons of this. Like on the one hand, they create so much wonderful stuff, that when they screw up in these minor ways, it doesn't hurt them enough for them to take the true lessons away from this. I don't think that Apple really thinks any differently of mandating these tools to people, say, you have to develop iPhone and iPad applications in these ways. This sting that came from the uproar of developers saying, "This is bullshit, we are walking out," is just not big enough, which is a damn shame.
Which is also way, sort of related to that, the whole iPhone 4 antenna-gate thing, was very interesting to watch. For a long time, they just didn’t give a damn. Bloggers would claim, like shout about it, or other publications would shout about it, nah, nah, nah, it's all isolated case, and then boom! Something hit them really hard, that Consumer Reports thing. And then all of a sudden, oh, wait, maybe it did matter, maybe we should address this. And it didn't even matter for the marriage, because for the marriage, I think there's not a big issue. The iPhone 4 antenna is just fine and I'll take the trade off of sort of better reception and then I can't hold it in a certain way. In some ways, that's exactly what I love about Apple. I love that Apple is willing to make controversial trade offs, because they're willing to say, "All right, fine, we'll increase the reception of this phone, if you just don't hold it in this one way." I actually find that's awesome! I just would've found it slightly more awesome if they would've owned up to it and just said, "Damn, that's how it is, because that's how it works."
Just like with the, I remember with the Macbook error when that came out. No internal CD drive? How is this possible? How can I use a computer that doesn't have that? Well, it's a trade-off. If you want a computer that's so slim that it almost looks like a piece of paper, then you have to give up stuff. I love that. I love those controversial trade-offs. I just don't, I don't love how they went about the iPhone thing, just seemed very PR-driven in the negative sense of that word, and I certainly don't like the way they went about the iPhone developer kit. But none of these things are going to kill Apple. If they continue to rock as they are now, nothing is going to catch them any time soon. And I think that's a shame, I would wish that Apple had better competition. Even the Android stuff now, which is getting pretty good on a lot of levels, is still nasty in so many levels. It's still so poorly designed as a coherent experience. They have these peaks of glory, but the whole package is just, I wouldn't want that phone. And I'm kind of sad about that. I wish Apple had more credible competition that would prevent them from doing the stupid shit that they're doing.
Question: How do you balance developing open source software and the need to grow your own business?
David Hansson: So, the way I divide my time between open source development and growing my own business is to combine those two things. So when I work on open source development, it's usually for myself. I work on features that I need for my business. I work on buck fixes that I need for my business. And I think the wonderful thing about open source is that if we all do that, if we all just work on our own problems and our own design features and then share them with each other, we'll get something amazing. That's exactly what Rails is. In fact, I think things start to go wrong once that's no longer true. Once you start working on features for other people and designing for other people and imagining what they might need and imagining how they might use it, that's hard. It's really hard to design for other people like that. It's so much easier to design for yourself. And when you design for yourself, you know exactly when it's right. You know when the grip is just perfect. You know when the sharpness of the blade is just right, not too sharp, not too dull, just there. You can't get to that point of excellence by approximation. It's very, very hard to just try to envision what the good thing is if you can't feel it on your own body.
So, for me, there's no conflict. I work on open source stuff when I need it. And when I need it, it makes perfect business sense to do it and it's sort of a byproduct of that, that I didn't get to share it. I'm going to be no poorer because I shared this open source software that I developed anyway. I needed it already. So if I give it away after it's already done, what am I losing? Exactly nothing. I'm gaining a ton of stuff though. I'm gaining that I'm putting this into a wonderful, beautiful commons and everybody else is doing the same thing and all the actors walk away from that richer.
Question: Where should a developer draw the line between what should be open source and what should be proprietary?
David Hansson: I'm no open source zealot. I don't need everything in the world to be open source. I don't need all software products to be open source, in fact, I prefer that there are not. I prefer to pay for things. What I do find is that there's a lot of stuff, a lot of infrastructure code in particular, about our applications, that are not part of making our applications special. The Basecamp, the Highrise, the Campfire, the Backpack, all of the applications we have, they could built on something else than Ruby on Rails, to be honest. That means that Ruby on Rails is probably not the secret sauce. It is not what defines these applications, thus if I give it away, I'm not giving something up.
Now, if we open sourced Basecamp and said, hey, "You can just download it, run it on your machine, contribute something back to us," what are we selling? If you're giving it away for free, they're not also going to pay for it, at least not very many are.
Recorded on July 22, 2010
Interviewed by Peter Hopkins
A conversation with the programmer and creator of Ruby on Rails.
The way that you think about stress can actually transform the effect that it has on you – and others.
- Stress is contagious, and the higher up in an organization you are the more your stress will be noticed and felt by others.
- Kelly McGonigal teaches "Reset your mindset to reduce stress" for Big Think Edge.
- Subscribe to Big Think Edge before we launch on March 30 to get 20% off monthly and annual memberships.
Tracking project establishes northern Argentina is wintering ground of Swainson's hawks
- Watch these six dots move across the map and be moved yourself: this is a story about coming of age, discovery, hardship, death and survival.
- Each dot is a tag attached to the talon of a Swainson's Hawk. We follow them on their very first migration, from northern California all the way down to Argentina.
- After one year, only one is still alive.
These quick bursts of inspiration will brighten your day in 10 minutes or less.
SMARTER FASTER trademarks owned by The Big Think, Inc. All rights reserved.