Rails and Merb -- Why Merge At All?

In my third round of mini-interviews about the Rails and Merb merger, I've turned to James Britt (@jamesbritt). James is a long time Ruby hacker and a fan of non-Rails web frameworks. If you think the merger is a panacea for the Ruby world, James' answers may give you some food for thought from a different perspective.

---

In a way, this reminds me of the gcc/egcs merger back in the day. What kinds of benefits do you think the Ruby, Rails, and Merb communities will see from this merger?

JamesWhat kinds of benefits? Very little for Ruby overall, some for the Rails communities. I don't understand the value to Merb.

Major disclaimer: I do some Rails work, but prefer Ramaze (and before that, Nitro). I did Rails for money, and Nitro for fun. For about a year now I've been free to use whatever framework I think best for a task, and that's been Ramaze, and limited time means I've lately not been keeping up on the all the goings on in the various Rails communities.

I did try to get a feel for Merb recently, and found it to be much nicer than what I know of Rails. If I couldn't use Ramaze, Merb looked to be an acceptable alternative. But whether or not I used it, the ideas explored in Merb (as with IOWA, Sinatra, Waves, Camping, and any of the other two-dozen or so Ruby Web frameworks) were of value because everyone could learn from each other and steal the best parts.

Because Merb was essentially (as best I could tell) a variant of Rails (with ideas from Nitro, Ramaze and other frameworks), it seemed easer for ideas to trickle back and forth between Merb and Rails. Rubyists had more options, and both Merb and Rails could feed off of each other. It seemed a win all around to have them independent.

The consolidation removes this useful competition. This is maybe a plus for folks who prefer Rails, and a gain for people who want to do things the Merb way but can now say they are using Rails. Less useful to people who want to see more distinct options.

The competition for the top spot in the Ruby Web Framework space has been good for everyone. What's going to happen now that the two big fish represent one, even bigger, fish?

James The idea that there is a "top spot" in the Ruby Web framework space has not been good for Ruby. There are real benefits to having a large, thriving community behind any tool or framework, but it's also critical to avoid a monoculture. It's better to have many thriving communities and an exchange of ideas.

There is a surprising mood among some Rubyists to want to see a "winner", for there to be just *one* of certain things. There's a cult of personality applied not just to people, but to projects as well.

The fuss over Merb v. Rails was a bit odd because it seemed (to this outsider) that the fight was over Pepsi v. Coke Cherry Zero, when in the back of the Ruby fridge we had mineral water, moonshine, champagne, and iced tea. There are lots of great things going on in Rubyville, things that aren't getting the attention they deserve.

Ruby appealed to me because it seemed to be about choice. One could craft a language on top of the language that suited the task at hand. You were not locked into the The One True Way.

If this merging helps people interested in Merb and Rails, great for them. But if it means less attention to the many other valuable Ruby Web tools, if it means fewer exchanges of ideas, then it's a loss for Rubyists at large.

Where else in Rubyspace do you think this kind of merger would be possible and helpful?

James What would be useful is more thought given to reasonable modularity rather than to more merging. For example, I'd like to be able to pick among Ruby tools for managing project tasks. Rake is the current leader there, though sometimes I want something a bit different.

But I'd also like to be able to reuse individual task definitions from my Rakefiles, even if I'm not using Rake.

Given that Ruby is so flexible, I should be able to move around in tool-space and still have a fair amount of re-use. I should be able to use templates and parsers and task runners and HTTP request routers and ORMS and never feel locked-in to one or another Big Framework. (Rack is a good example of providing mid-level granularity.)

I'd rather see less consolidation, less coupling, less emphasis on "winners" and "leaders", and more focus on solid, pluggable code, crafted and assembled by each of us.