Together: The Merb Story

I'll never forget the day that I became a member of the Rails core team.

For all of 2008 (and the better part of 2007), I was working on a competitor to Ruby on Rails called Merb.

I loved Merb, and was excited to share it with anyone who'd listen, so when I attended RailsConf in 2008, I signed up to give a nighttime Birds of a Feather session about Merb. To be honest, I expected only a handful of people to show up, but I was too excited to let that stop me.

When the time for the session arrived, I nervously waited in the small room that the conference assigned us. Other members of the Merb community were there, and I nervously joked that maybe nobody would show up and we would just have a meeting of the core team.

That didn't last long. Minutes later, a handful of people wandered in. I haltingly tried to make some small talk as we waited, and soon realized that the people who had shown up were psyched about Merb. I was relieved. Small talk is not my strong suit, and the group's enthusiasm for Merb gave me an excuse to get lost in an animated conversation about Merb.

I looked up from  my conversation after a few minutes, and noticed that the room was filling up. A few dozen people were packed into the room. I was happy that people cared. But then I noticed that people were peeking in through the door, and I walked over to the door to greet them.

Holy shit.

I saw a line of dozens and dozens of people snaking through the hallway, trying to get in. My heart was pounding. Thinking quickly, I led the group to a larger room that had been used earlier that day for normal RailsConf sessions.

Flustered by the sudden attention, I opened up the codebase, threw it up onto the projector, and walked through the code, jumping from one interesting piece of the internals to another.

I fretted about being unprepared. About looking stupid in front of people who had invested time and energy into the project. But when I left the room that night, and finished high-fiving Merb contributors and fans who poured their hopes into this thing, I knew that our little project was resonating.

I had originally started working on Merb after a bad experience with Rails. Ruby on Rails is the reason that I became a successful programmer in the first place, but a few years later, I was running head first into limitations. Limitations that seemed pointless and unnecessary. Like the time I naively tried to use layouts and helpers in my emails, but learned that ActionMailer was a fork of a very early implementation of Rails controllers, and didn't support layouts or helpers.

I became the maintainer of Merb because I wanted to fix all that. At the time, I was still extremely grateful to Rails for bringing me in to programming. I knew that convention over configuration was a critical part of what allowed me to grow from a print designer into a web application developer. I will be eternally grateful to Rails for making me realize that I could be a programmer. But it felt like it was all starting to fall apart.

Back then, I didn't know what it would mean to use Ruby to build web applications without Ruby on Rails. But Ezra Zygmuntowicz, a co-founder of Engine Yard, did. He had a different bee in his bonnet: he wanted a Ruby web framework that was much faster than Ruby on Rails, which had a (deserved) reputation for being quite poky. Ezra had put together Merb, named after Mongrel + ERB, the components in the original Merb stack.

Even though I was interested in building a more modular web framework and Ezra was interested in building a faster web framework, Ezra invited my help enthusiastically. I remember walking into the Engine Yard offices on South Park, worried that I didn't have the first clue about how to build a web framework. I worried that I wasn't ready to help lead Merb's development. I worried that I was an imposter. I worried incessantly.

But a few minutes after walking into the Engine Yard offices on my first day, I was neck deep into brainstorming with Ezra. He never wasted a second thought on the question of whether I was ready. Getting right down to business with Ezra made me forget my self-doubts, at least for a moment.

I remember the next few weeks as if it was an 80s montage scene, full of whiteboards, printouts, and wild gesticulations. At the end of that, we had a plan for a web framework written in Ruby that would be fast, as Ezra wanted, and more extensible, like I wanted.

Throughout it all, I never forgot that convention over configuration is what enabled me to become a programmer. But I didn't see why convention over configuration meant that ActionMailer shouldn't support helpers. I didn't see why convention over configuration meant that you shouldn't use jQuery. And I didn't see why convention over configuration meant that rspec stopped working every time Rails released a new version.

I wasn't alone in feeling this way. A community full of people showed up, ready to build.

Carl Lerche, who wrote the router for Merb at a time when I had no idea how to write a router. Matt Aimonetti, who made a point of ensuring that Merb was actually understandable to Rubyists. Daniel Neighman, who built Merb's authentication system.

There was an outpouring of support. Over time, we showed that Merb was more than a reaction to Rails, it was a community of people with shared problems searching for shared solutions.

I was still new to open source, and I was just so mad at the Rails core team. I was sure that the Rails core team didn't care about my needs. I was ready to brawl at a moment's notice.

So I got into a lot of fights.

I wrote a series of blog posts needling Rails.

I went to RailsConf and scheduled a Birds of a Feather session to talk about why people should use Merb instead of Rails. When a crowd of people showed up, I became even more righteously indignant.

I approached important Ruby community members at every Ruby conference I attended, working hard to convince them that Merb was the way forward for the Ruby community.

To be honest, I felt pretty good about it at the time too. I was flying high.

But not everyone felt so good about it. I worked for Engine Yard, and we had made our mark selling Ruby on Rails deployment to large customers like Groupon, Kongregate and Github. I got hired at Engine Yard in part because the company's founders were worried that Rails wouldn't make it long-term. They wanted to hedge against this possibility.

Unfortunately for me, waging an all-out war against Ruby on Rails from inside of a company that makes its money selling Ruby on Rails deployment is a pretty bad life strategy.

I don't know everything that went on behind the scenes, but Engine Yard's management eventually asked me to consider merging with Rails. If I'm being honest, they pushed me to consider merging with Rails.

My initial reaction wasn't positive. I spent days on the phone with members of the Merb core team, feeling angry and aggrieved. I cared about Merb, the Merb community, and what we were building together. We had all joined the Merb project because we had serious problems with the trajectory of Rails. How could we just fold up shop and act like none of that even mattered?

"Merb and Rails disagreed about everything!" I kept thinking. What could we possibly gain by talking to the Rails core team?

I was willing to quit my job over it. Nobody was going to force me to do something I didn't want to do. Tom Mornini, the CTO of Engine Yard, knew that. He also knew that there really was something interesting about the idea of the Rails and Merb teams working together.

I remember boiling with frustration when Tom pulled me into a stairwell to try to talk me into working together with Rails. He didn't try to argue with my feelings, or tell me that my frustration was wrong.

Instead, he convinced me, slowly and patiently, that the conflict between Rails and Merb wasn't fundamental. He convinced me that the Ruby community might be better off if we joined forces. And most importantly, he convinced me that there was nothing wrong with giving a conversation a try. Haltingly, I said I would meet with the Rails core team once. But then I was quitting. I was going to start my own company dedicated to the Merb project, on my own terms.

I can't remember the details, but I must have been fairly combative the first time I talked with the Rails core team. I was sure that all of the little details of Merb were very very important. I was sure that the Rails core team hated our ideas.

Instead, as I talked with the core team in Campfire, DHH, Jeremy and Koz helped me realize that I was getting it wrong. Rails had far fewer substantive contributors than I had imagined. They didn't hate the idea of making helpers work in ActionMailer, it was just that nobody contributing to Rails had a burning need to solve the problem. The problems that were keeping me up at night—the problems that were animating my work on Merb—weren't even on their collective radar.

This was my first brush in the open source world with positive-sum thinking.

After a few hours of conversation, I realized that most of the picture that I had built up in my head about the Rails core team was just wrong. The conflict was almost entirely a matter of resources, not a disagreement about values. DHH and the Rails core team had no problem with the things I cared about, they just didn't want to prioritize them personally.

Author's note: I read this paragraph over and over while writing this post. I wrote and rewrote it. Finally, I realized that this description ("they just didn't want to prioritize them") sounds like a value conflict even though it's not. It's so easy for our brains to turn disagreements about priorities into value conflicts. It takes a lot of effort to see past that mistake.

Disagreements about prioritization is a very different thing than disagreements about how to allocate fundamentally scarce resources. This is at the core of positive-sum thinking. When resources are scarce, small differences in personal prioritization turn into hard conflicts. And hard conflicts turn into tribal disagreements that are incredibly hard to dig out of.

But open source software doesn't need to work this way. By joining the Rails team, we increased the number of available contributors. Disagreements about priorities only turn tribal if you assume contributor resources can't change. But in open source, you can work on what you need and share the rest.  DHH and the Rails philosophy was right. Very few of us are special snowflakes.

As a person who became a programmer through Rails, and who infused convention over configuration into Merb, I already knew that. I was just so blinded by tribalism that I never even bothered to check how fundamental the disagreements really were.

After that meeting, it didn't take very long for us to realize that we agreed far more than we disagreed. Just in time for Christmas, 2008, we announced the merge.

In a post talking about the merge, DHH said: "kumbaja mother fuckers".

In my post announcing the merge, I wrote: "Given this philosophical convergence, it just didn’t seem like there was much to gain by continuing to duplicate effort and spend time and energy fighting each other."

It turned out that we didn't need to agree on personal style, priorities, or even agreement on what the default Rails stack would look like. As long as we shared a basic vision, a worldview, we could work together productively.

When we merged Merb with Rails, I became a member of the Rails core team. I remember lying in bed, full of worries. There had been so much fighting. Was this going to work out? Was I going to regret this?

But pretty soon, DHH was treating me like a normal collaborator, working together to build the next version of Rails. I don't remember what we worked on first, but I do remember feeling like I belonged. Almost as soon as we got to work, my anxiety evaporated, replaced with the buzzing feeling of getting things done. Together.

In my next post, I'll talk about how my experience with Merb and Rails affected the way we structured the Ember project.

When Melanie Sumner was interviewed for the Ember documentary, she described Ember this way: "We're the Together Framework". In the next post, I'll explain what that means.