The Framework Nobody Asked For: How Ruby on Rails Went From a Side Project to a Revolution

Back in 1999 or 2000, Jason Fried had a web design company called 37signals and two partners. He also had a side project — an online book database called Single File. He didn’t know how to program, but he picked up a book on PHP and started building.

He got pretty far. Then he got stumped.

So he wrote a post online asking for help. This was long before Stack Overflow, long before there were answers anywhere. Just a general call into the void: here’s my problem, anyone know how to do this?

A guy wrote back from Denmark.

The Email That Started Everything

“Back then I was here in Copenhagen working in the web industry, and I was just a big fan of the company,” David Heinemeier Hansson recalls. “Right from the inception there was a web blog, Signal vs. Noise, that I followed religiously. It was just such a weird company — a design company that was focused more on writing than it was on pretty pictures or graphics.”

DHH had been following 37signals for a couple of years. Then in 2001, Fried posted a question about programming.

“I saw this question and I went, ‘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.”

So he wrote up an answer explaining how to solve the problem in PHP, in as much detail as he could. He wasn’t an expert programmer. But he knew the answer.

Fried remembers it differently — specifically, he remembers the quality of the response. “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.”

They started talking back and forth. Then the conversation went deeper. Fried asked to see the whole thing. DHH said sure, and showed him the code.

“This sucks. We should really start over. Let me do this for you.”

That’s how the partnership began — one man telling the other his work sucked, and the other replying: okay, let’s do something better then.

Three Failed Attempts Before It Clicked

DHH got his first computer at six years old, in 1985 — an Amstrad 464. His first exposure to programming was typing video games in from the back of a magazine. He wasn’t very good at it. Only a couple of them ever worked.

Around ten or twelve he tried again, with a programming environment called Easy AMOS. “It was not easy for me. It may have been Amos, but it wasn’t easy.” Variables, loops, conditionals — the basic constructs defeated him. He gave up again.

It wasn’t until he discovered the internet in 1995 and got involved with making HTML that he saw another opportunity to create something. In 1999 he started working on a gaming website with another programmer in PHP, at twenty years old. His third attempt at learning to program.

“That was really the first time things clicked. And that was really the prep I had before, a year later, I would write Jason that email.”

Meeting in Chicago

They worked together for quite a while before meeting in person — just Skype. Then Fried was waiting in the plaza at the John Hancock building in Chicago, looking around, wondering which stranger was his Danish collaborator.

“This guy shows up and he comes around the corner and he’s wearing all white. Rail thin. White T-shirt, really short sleeves, white capri pants, white shoes. I’m like, there’s Denmark right there. That’s David.”

He thinks there may have been rollerblades involved. He isn’t sure.

Basecamp, and the Need for Something Better

After the book project, they did a few more client projects — it was a web design firm, after all. Then they got busy enough that they needed a way to manage the work.

So they decided to build a project management tool for themselves.

DHH was still a student at business school in Copenhagen, so he didn’t have much time. Fried hired him to build the back end of Basecamp, and DHH asked to be paid in laptops and computer equipment rather than money, because modern Apple hardware was hard to get in Denmark. Every time he came to the US, he’d get a laptop. He worked about ten hours a week, because that was all the time he had.

In 2003 they started on Basecamp. Most of the organisation around their consulting work had been happening over email — an experience everyone recognises. So they thought: we know how to make web applications. Can’t we make an application that makes this easier, so we don’t have to deal with email threads and which version of the file is latest and what’s left to do before launch?

That’s what they did.

Discovering Ruby

Earlier that year, Fried had discovered Ruby through the writings of Martin Fowler and Dave Thomas, who were using it to illustrate programming concepts in 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.”

That was the appeal. When you explain a programming concept, you don’t write exact syntax — you write something that looks more like English. Ruby looked like that. And here were two titans of the industry clearly enamoured with it, expressing that they’d write systems in it if only they could get permission.

“I thought, 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.”

DHH’s reaction, from the other side of the Atlantic, was less romantic. “I’m like, what the f*** is Ruby? I’ve never heard of this. He’s like, it’s this thing out of Japan. I’m like, all right. I truly 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.”

Building the Tools He Needed

By 2003, DHH had developed a taste for what he liked in programming but hadn’t found anywhere to express it. Ruby clicked. What he loved was the combination of PHP’s immediacy — getting Hello World onto the web with minimal fuss — with the intellectual rigour of a well-thought-out object-oriented language.

“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.”

He gave himself a two-week window. Could he build just the basics of a web application? Could he get HTML on screen rendered from Ruby, talking to a database?

There weren’t many libraries. There weren’t many frameworks. Certainly nothing to help with database access or web development in general. So he built the tools himself.

That’s how Rails came about. Not as a grand design to release a web framework to the masses — there wasn’t even a thought of releasing it originally. He simply needed these things, so he made them.

Over the next six or seven months they built Basecamp, and during that process Rails was extracted from it. Between the summer of 2003 and Basecamp’s release in February 2004 was the main gestation period. But Rails wasn’t released until later in 2004, because DHH had a vision from the start that this could be something special — and the first version needed to be good. Not just in code, but in documentation.

He spent roughly six months polishing before putting it out.

The Slide That Said ‘F*** You’

When Rails started to take off, it was wild — and DHH was of two minds about it. It was great to see something he’d created generating that much excitement. But he was also highly protective of the integrity of the vision.

“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 — to be so enamoured and pleased with other people’s contributions that you put it all in and you have a hard time saying no.”

He said no to a lot of things. At an early Rails conference in Canada, he put up an infamous slide with just two words on it. The point was to express his frustration at people who showed up with unreasonable demands — followed by a threat: unless you put this thing into Rails, you will fail.

“F*** 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.”

That’s one of the reasons he loves open source. It isn’t a commercial relationship. Nobody gets to dictate direction. He’ll take input and feedback — and Rails is what it is today because thousands of people contributed really great work he had no hesitation saying yes to.

A Provocation With Substance

One early community member describes the first encounter with Rails as a jolt: a guy announcing on the Ruby mailing list, I’ve got a plan.

“It’s like, are you coming down from Mount Sinai with your tablets? Who gave you these commandments? So it was a provocation, and there was some spice to it. I was like: is this guy an a**hole, or is there something to it? And it was a little bit of both.”

There was a well-carried arrogance about having the right ideas and being willing to set them out for everybody to see. And the ideas were good. Some were old ideas reconfigured — the Active Record pattern says it right on the tin — but taking a pattern and making it a framework added a jolt of electricity to a community that was already generous and kind.

The Pied Piper With an Imaginary Piccolo

Another early adopter first heard about Rails at the 2004 International Ruby Conference — a small event, maybe thirty or forty people. He’d never heard of DHH.

“He got up and was talking about why he wrote Rails. He really was pushing a better experience for programmers. 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.”

He never showed a line of Ruby or Rails code in that whole presentation. It was all about why he wrote it and what he hoped to accomplish. Some people were disappointed — they’d come for technical detail. But the excitement was contagious.

The Core Team and the IRC Channel

For about the first year, DHH was the only one committing directly to the code. He took patches over email, and they even used a wiki — this was well before GitHub made everything easy.

After almost a year, he expanded access and instituted the Rails core team: the people who had sent the most patches, the best work. Among them was Jamis Buck, who ended up being the first programmer hired at 37signals as Basecamp took off. A good number of the early hires came out of the Rails core team.

“I had never really been part of a team like that,” one member recalls. “But there was something about all of us having this same vision and working at such an early stage on something that felt like it was going to change the world.”

They had an IRC channel specifically for it — that’s where the real conversations happened. What was Rails. What would Rails become. What would the next features be. It’s still active today.

“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.”

The Argument About Open Source

One of the most fascinating conversations of that era was about whether Rails should be open source at all.

The team was building real companies. They were demonstrably more effective with small teams than larger teams with lesser tools. So why give that away? Shouldn’t they charge money? Shouldn’t they keep it as a comparative advantage?

DHH’s answer was no. Open source was important. MIT license open source was important. And — in his words — we’re going to make Rails extraordinarily successful.

“I remember pushing back, saying, David, that’s not something you can just decide. You can’t just decide something is going to be successful — that’s an outcome that requires luck and all these components. And he said, no, we can decide this.”

DHH was twenty-four at the time.

“I’m still trying to figure out where you get that from at that age. It still seems remarkable. Now we’re in our forties and I still don’t run into a lot of people who have that kind of conviction and out-of-the-box understanding of market dynamics, attention, and business development. I think I got a business degree accidentally, playing out right in front of me while I was just trying to get work done.”

‘But Will It Scale?’

One of the loudest criticisms of Rails was that it couldn’t scale. It became a chant. A meme.

“We could point at Basecamp and say, this is non-trivial. We’re serving people’s needs. We’re providing value. Isn’t that the important thing? And we never reached a point where we said, well, I guess Rails can’t scale — we’ve reached a number we can’t go beyond.”

The question, in hindsight, was less about technology than about FUD — fear, uncertainty and doubt. It was something you could throw out before Rails had major applications behind it.

Today, Shopify runs a significant percentage of global e-commerce traffic on a very large Rails codebase — with the same folder structure as any application you’d generate on your laptop. “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 is the best tool for a lot of the problems being solved by thousands of engineers.”

And the harder thing to scale, as one engineer puts it, isn’t web performance. It’s finding foundational ideas that still feel good twenty years later.

Merb, and the Only Time Two Frameworks Merged

After Rails 2.3 in March 2009, the toolbox felt full. The question was: where do we go from here?

The answer arrived in the form of a competitor. Merb came on the scene as a young upstart Ruby framework that challenged Rails by being faster, lighter, slimmer, doing less. It lit a fire under the Rails team.

“We had a competitor that really showed us another path forward. And Yehuda and Carl from the Merb core team showed us the way.”

Rails put significant effort into re-engineering its internals to be configurable, recomposable, modular — so that a framework like Merb could be built from it. Then the two teams talked, and decided to merge.

“Has this ever happened? Have frameworks merged ever and become just better? That’s a singular story too.”

Why the Love and the Hate

“This Rails approach — for some people, not all, not most — it’s not better. But for some people it’s a hundred times better. It’s not a bit better. And this is why you see the bifurcation. This is why you see the love and the hate and very little indifference.”

Most technologies occupy a spectrum of indifference — not relevant to you, doesn’t matter. Rails provokes strong opinions because it comes from a different place.

“I think that’s precious, and exciting. It’s been honestly an honour to be part of. I know these terms are so weird — it’s so weird to talk about an honour to hang out in an IRC channel you got invited to. But man, it was.”

What It Was Actually For

Ruby on Rails is full of people who were not trained to be computer scientists. People from all walks of life who developed an interest in creating web applications and were able to learn because it was easy — because it didn’t require 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.”

The slope is deliberate: start low, learn very little, then go all the way to becoming the top programmer in your company, in your industry, even without the credentials.

“I love that part of Ruby on Rails. I love the diversity of the people who have been able to create a career in programming because of this framework that we’ve created.”

Things like Rails, like Basecamp, like 37signals — you can’t plan these things. They don’t happen because you set up a business plan in advance. They unfold, and like anything that unfolds, they need time.

As the website says: Rails lets you go from Hello World to IPO with a tiny team.

A single developer, a minuscule amount of time, and a framework that started because one man told another his code sucked — and the other said: okay, let’s do something better then.