I interviewed David Heinemeier Hansson, the creator of Ruby on Rails, at the first European Open Source Convention in Amsterdam, October 18th. The theme was how the emergence of the Rails community had affected him and the small business he is partnering in. This is the whole transcript of the interview, only slightly edited.

When you created Rails, was it clear from the beginning that the framework would be released with an open source license?

No, no. When we started work on Basecamp, the project Rails sprung out of, we just wanted something for ourselves. I wanted something for myself, and I just wasn’t happy with what was already out there. Originally the attention was to just do something for me, but about halfway through the production of Basecamp I realized that Ruby on Rails was making me happier as a programmer and there was a good chance that it could make other people happy too. I’ve been a user of open source for a long time but I haven’t actually released any open source software before Rails. So it was not a natural outset for me that I wanted to produce open source software.

But I was getting deeper into the ruby community. I was using a lot of the open source libraries in there and by the time I’d extracted enough out of Basecamp to have something that could be called a framework I definitely did start thinking about releasing it. Those thoughts then grew more serious around the time of release of Basecamp in February 2004. I thought to myself, “Ok, I’m going to release it, I’m going to polish it up and package it nicely and put it out there”.

I then spent February through July polishing all the stuff I’d used to produce Basecamp in a nice package. As a user of open source I’d continuously been annoyed by the quality of documentation, packaging, examples and all that stuff that are sometimes lacking in open source software, and I wanted to make sure that Rails didn’t suffer from that. So Rails came to be because I found the stuff useful and thought that other people could find it useful, too.

Did you have any presumed benefits or fears about making Rails open source and how did they relate to the reality?

I was already won over. I believed in the open source benefits by the time I open-sourced it. Actually I did it in a somewhat under-hand way as I didn’t really propose it as a question to my business partners as “Should we do this or not?” It was in my mind largely a technical decision: this is going to improve my productivity as a programmer, which in turn is going to improve our business situation. I would actually have thought that I was doing a bad job as an employee of 37signals if I didn’t open-source it. I felt that it was my duty as a conscious programmer to get the most mileage out of the work that we produced.

So I was actually fairly positive and optimistic about the notion of open source beforehand, but I’ve certainly been overwhelmed by the benefits that we’ve been able to receive, both on the technical and other levels. There’s so much code in rails that I use every day but that I didn’t write. If nobody else would have written that, I would have had to do it. Which just means that I would have less time to spend on our proprietary business logic which just doesn’t make sense. There’s nothing in Basecamp, Backpack or any other of the 37signals products that really relates to Rails in the sense that there’s something we’d be losing up by sharing Rails. Rails is all about common infrastructure, so it just makes perfect sense for companies the size of 37signals to share the load of developing infrastructure software with other small companies and even big companies. The whole notion of creating a commons that everybody contributes to and everybody benefits from has served us incredibly strong.

So there’s been all the technical benefits of getting a whole lot of work done that we didn’t have to do: getting bugs fixed before we encountered them in our production software, all the traditional open source benefits. But it’s also been a huge PR benefit, in the sense that 37signals is mentioned pretty much every time Ruby on Rails is mentioned just because it’s the poster child and it’s where Rails originated from. All these things lead to a lot of goodwill against 37signals both from the press and from the programmers. I think that that alone has an extreme value for small companies. We don’t have a large marketing budget, we don’t buy advertising, we don’t do a lot of those things big companies do to create awareness of the products. So we really have to leverage anything that can get the word of mouth going, and having a successful open source project is one of the best ways of making your mark as a company.

And then, third, open source is also a perfect way to find great employees. So far all of the programmers (three at the moment) that were hired to 37signals since I joined, have been cherry-picked of the very best of the Ruby on Rails developers. It provides an excellent filter to find the very best people in the business just because you get to work with people for a long time before you even have to consider whether you can hire them or not. At the point of hire you already know these people, you know what they’re capable of, you have worked with them and you know that the culture is a good fit. I think that’s incredibly important for small companies like 37signals. You cannot afford to hire a dork. You cannot afford to have somebody in your team who’s not pulling in the same direction as others. If you just put up a “We’re hiring” sign on the door, the risk for getting exactly that is very high. There’s only so much you can do in vetting out candidates if you’re going through the normal process of accepting resumes and having a one-hour chat. So for us leveraging the open source has been a very powerful tool in attracting the top talent.

The community has played an important role in the success of Rails. Where would you think Rails would be now without it?

There wouldn’t be any Rails. There wouldn’t be Rails in the sense of a large open source project. There would still be Rails in the sense that I’d probably use it but I would have gained so much less without a community. Community is really critical in many senses. Having a load of users is a great way to find errors in your software, to get great ideas for new features and just to have an ecosystem where other people can benefit from your work, build a business on it and then have the resources to contribute back. You can also find employees that way and just get the whole awareness thing going.

If there was not a community of passionate Rails users there would not be any buzz, and if there’s no buzz, 37signals would not be getting the marketing value out of it. So the community is Rails in a large sense.

So you at least to some degree agree with Alan Cooper, when he says that in a sense the source code has become not an asset but a liability and that the value of an open source project is in its community.

I think that’s true at least in some sense, and I definitely subscribe to the whole notion of `less software’: that the more software you have, the higher liability it is, the harder it is to change, and so on. But at the same time it’s also true that software over time just gets experienced. A product like Ruby on Rails has a lot of experience embedded in it just because it’s been used by a large number of people on a wide set of different applications for a long time. It means that we fixed a lot of those bugs that less experienced software just hasn’t fixed. And I think that’s at least some of the value of having a codebase with experience. So I wouldn’t say that the code as a total is a liability, because I also think that open source projects that announce themselves and try to drum up a community without any code have a really hard time, just because the reason the community exists is to revolve around the code. So there has to be something real about the community and lines of code — executable, valuable software — is that reason to form a community.

Do you feel the form of community — you and the core team — has been the right structural form of an open source community? Would you do something different if you’d start all over?

I was actually very reserved in getting something as the core team together, even using a bug tracking system. I tried to keep as little community infrastructure in place as possible, just to lower the barrier for a new member to enter the community.

But there just comes the time when you have 300 people in an irc channel and it’s not going to be anymore about how do we push Rails forward. It’s going to be a whole lot about the usage of the software, which is great, but it also means that the people who do the work, the people who really push the framework forward, need some place else to discuss their ideas and share an experience about pushing the framework forward.

So at some point the community invariably gets split up. There is the part of the community that mainly uses it, maybe contributes bug reports and helps spread the message and the excitement. Then you’ll have something like the core team forming which is just the people who dig deep enough into the code to continuously submit patches and so on. I think that’s actually a healthy split because if you don’t do that split you risk losing some of these core members just to the noise because they drown out in the three hundred people in the irc channel.

So having a secluded, private place to discuss these matters is actually very beneficial. But it’s somewhat of a balance because you don’t want to create too wide of a split between the core group and the rest of the community. You want to make the whole thing feel as one. And you just got to walk that fine line and not set these things up to be adversarial. It has to be about cooperation and make everybody realize that we’re just here to create a better Rails and this is how we find it useful to do it: to have a core group of people who supply a lot of patches, and that they have a back room just for themselves.

As an entrepreneur and a founder of a new open source project and community, is there something you would like to have known 1.5 years ago when you started the whole thing?

I’ve certainly learned a lot of things but at the same time I’m glad that the learning happened while I was doing something. I think Rails in some parts happened because I didn’t know it all. If I had known how much work it actually is and how big a thing it actually is to create a full-stack framework like rails is, I would likely have been pretty intimidated by that, so I might not have done it.

If I’d known more about Ruby I would perhaps not have been annoyed enough. I was bringing experiences over from another languages and feeling: Oh, PHP used to do this, why can’t Ruby do it? So I had enough friction at that time with my own experiences and coming to a new language and a new culture in some sense was what sparked the development of Rails.

I think that when you’re new somewhere, you have a real opportunity to inflect change. Because the longer you spend in a community the more experienced you get and the less likely it comes for you to see all the flaws. You just grow accustomed to them. So I think that we need newbies to tell us what’s wrong and give us the outside perspective. I think that was what I did with Rails: I gave the outside, web, perspective on Ruby, and that became Rails.

Anyway, I would likely have instituted some of the community changes a little bit sooner: we would have had a place to post the patches from the start, not just the wiki. We also would’ve had the mailing list from the start. So some of the things that I held back on I would probably have introduced sooner.

You in 37signals have been great proponents of `big things with small teams’. How close do you think the notion of open source communities and projects are to this way of thinking?

I think it’s pretty close. I think that one of the reasons why Rails is such a success now is because I didn’t open source it from day one. I developed with a very small team, me, until it had enough of the vision that taking on new people would more likely change them to the vision that was already in the software than change the vision of the software.

I think one of the mistakes a lot of open source projects do is that they release too early. They release the software in a state where it’s very easy for somebody else to come in and say: “I wanna take it into this other direction.” And you don’t get the sense of unity and support around the core vision if you do that. You really need to have that structure of software in place before you can scale it up.

I think that’s the same notion I have about developing software in general: you need to develop it in small teams. Developing by committee or developing by huge teams is not a way to get succinct, effective, valuable, simple software. It’s just a way to get something big and imploded because you have to please everybody, because everybody is on a level playing field.

That’s why having at least a sense of hierarchy in an open source project is not necessarily a bad thing. It doesn’t mean that somebody coming in from day one can’t say whatever they want. It just means that we have some method of ensuring that the vision isn’t bent out of shape too early, and I think vision for software is incredibly important. Vision is what gives it that edge, that focused use, which makes the users of the software happy.

How do you see the risks arising from legal matters, especially intellectual property rights, affecting different players in open source ecosystems?

I actually see it just as a temporary distraction that’s affecting some parts of the open source software. And I really think it’s a temporary thing. It’ll blow over and in three years we’ll look back and say: “Huh! It wasn’t that curious.”

One of the stances we have taken with Ruby on Rails is to release the whole thing under MIT license, which basically just says: “You can do whatever you want, just don’t sue us.” I like that sort of license. I’m not a big GPL proponent. It probably works fine for something but I’ve found that people are even more willing to contribute something back when you’re not holding a gun to their heads saying: “You have to!”, and I found at least in my usage that I keep more freedom that way.

I think that also reduces the risk of having these legal encounters, just because if you can do whatever you want, then who cares. So I don’t see it as a whole as a threat, I see it partly as a figment of media imagination. In some way or another, fears and threats filled up just because you’ve been hyping open source for all these years. Now we need to tear it down somehow, tear down the innocent image of it. And it’s just a meaningless distraction, not something I spend a whole lot of brain cycles on.

So it’s just a part of life for a younger field?

It’s just a part of the process of going through this paradigm shift where most if not all infrastructure programming is going open source just because it makes sense. Naturally there’s some players that used to make money on infrastructure software that don’t like that shift. But as dinosaurs go, they will be extinct, and it will be a good thing, once we just realize this base level for cooperation around these things: that open source is just a very good model in developing great infrastructure software. Then we’ll figure out how to add value on top instead of trying to compete on the low-level components.