What are some of the specific things that you like about Ruby in contrast to languages like PHP or Python?
It's hard to explain the appeal of Ruby in terms of a few short bullets. Why is the iPod so much more pleasurable to use than the Creative equivalents? It's hard to point to a few features and say that's why. It's about aesthetics, feel, and enjoyment.

But if pressed, sure there are a number of Ruby features that lead to these aesthetics. Most important are the blocks; anonymous methods declared inline with its use. It makes working with collections, dealing with transactions, and exposing resources like open files so much cleaner. It allows us to create domain-specific languages that rely on nesting to be clear and succinct. Blocks are probably my favourite Ruby feature and you don't get it in PHP, Python or Java.

Additionally, the ease of which you can execute code during the definition of a class makes for beautiful code. We've defined domain-specific languages on top of this feature for a large number of aspects in Rails, like associations (has_many, belongs_to), validations (validates_presence_of, validates_length_of), filters (before_filter, after_filter), and more.

So between the inspirations from Perl, the features mentioned above, and the complete object-oriented approach - even numbers and strings are objects in Ruby, unlike, say, Java - gives Ruby an incredibly clean and pleasing look. You get to build expansive domain models without all the boiler-plating and extraneous busy-work that plagues Java and its ilk of static languages.

Ruby attacks the productivity problem by making the core elements as expressive as possible, so the programmer doesn't have to rely on IDEs and other tools on top of the language to get stuff done. Few programmers today would even consider doing Java without Eclipse/IDEA or C# without Visual Studio, but lots of programmers happily write Ruby code in good text editors that aren't born with specialisation for one particular language, like TextMate for OS X, which is the big hit in Ruby/Rails circles.

Could go into some details about how you went about developing Rails?
The most helpful approach to developing Ruby was the notion that frameworks are extractions. They're the generic, useful pieces that you find in existing applications. Not predictions or fortune tellings about what some programmer might like to have for some application in the future.

So I didn't set out to create Rails. I set out to create Basecamp, a real application that we were building at 37signals. That application drove the design of the framework as I would implement a new feature in Basecamp, then look at the code, abstract, extract, and carry on.

To this day, that's still our main source of innovation for new features in Rails: stuff we implement for real applications first, then extract. Rails is a collection of solutions to real problems met by the contributors.

You have said before that you favour development in small teams. To what degree is Rails still developed that way, given its popularity? How did you go about keeping development focussed in a small group as the project grew?

For the longest time, I controlled the evolution of Rails by being the only one that could apply patches to the code repository. Everything went through me. That secured one vision and established one culture. These days we're a group of about 12 people with commit rights and out of those, perhaps half exercise those rights regularly. So the bulk of Rails is still developed, or at least examined, by a very small team.

But we've definitely had an explosion in contributions from dedicated programmers who've stretched Rails from all the angles. We're getting new patches and tickets about edge-case problems at a staggering pace — so fast that we can't keep up, but that's okay. I'd rather accidentally miss one good patch than let in three bad ones.