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.

Rails and Merb -- Better Together?

After my quick interview with Yehuda and Kevin the other day. I wanted to post a couple more points of view. David Heinemeier Hansson (@d2h) and Jeremy McAnally (@jeremymcanally) were good enough to weigh in as well.

---

What kinds of benefits do you think the Rails and Merb communities will see from this merger?

DHH We get to join the best ideas into Rails and make those ideas available to a much larger audience. We also get a bigger, better team for pushing Rails forward.

Jeremy I think this can only be good for the two communities. Bringing Merb's sensibilities to a large, mature codebase will not only open up a lot for the framework technically, but I honestly think we'll see a lot of innovation and, dare I say, *synergy* between the two cultures. There's been a lot of squawking about monoculture this or competition that, but honestly I think we'll see a lot more come out of working together rather than arguing with one another.

I have my own apprehensions about adding someone to the core team who isn't actually *using* Rails every day. One of the biggest wins for Rails was the fact that was and still largely is extracted from working code changes, additions, and extensions from working production code. Adding people to the team who aren't "practitioners" will create a slightly different dynamic I think, but I'm not sure if it'll end up being a good or a bad thing. I trust Yehuda is a very competent Ruby programmer, so I don't doubt that the code will be good, I just think the perspective may not be the same.

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?

Jeremy As for non-Rails web frameworks, I don't think it means much. Frameworks such as Sinatra, Ramaze, Mack, and so on all have something fundamentally different to offer technically, whereas Merb and Rails were very technically similar in their goals. This similarity is why it makes sense to merge Merb and Rails, but it's also why it won't affect the other frameworks.

DHH You should look as competition being much larger than just the Ruby sphere. There are a TON of choices in this world to do web-based software. Everything from .NET to J2EE to PHP. In that picture, Rails is still a comparably small fish.

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

Jeremy I'd like to see the ORM's become a little more singular. I'm hoping something like Active Relation or (a much simpler version of) Sequel or Ambition will create a Rack-like interface for ORM's to hook into so we can have different DSL's on top of a core that's super fast and tight.

I'd also like to see a merge in the realm of these extension libraries. There's Active Support, facets, extlib, this, that, etc. etc. that all do basically the same thing on one scale or another. Ideally we'd have some sort of core library that lazy loads/installs each piece or something so you don't have to have a gigantically huge library but still get the same functionality. Having a ton of hands working on these libraries will speed them up and make them more efficient.

You Got your Merb in my Rails

When the news about the Merb/Rails merger broke, I shot off an email to Yehuda Katz (@wycats on Twitter) to get his take on things. Here's what he had to say:

---

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

Yehuda The benefit is that Rails becomes a framework that can scale from a single-file, light app, all the way up to a full stack (perhaps even more full stack than Rails is today!). That means that people who were having to struggle to gain acceptance for Merb at their work will be able to leverage Rails' popularity, while also being able to hold onto the reasons they wanted to use Merb in the first place. A win-win.

The Rails community will get all the benefits of Merb in their favorite framework. Faster performance, a public API (which means plugins that break less), the ability to use other ORMs, and the list goes on and on.

As a whole, the community gets more smart people working with each other instead of against each other. This should help grow Ruby even more. I am absolutely convinced that this is the year we put away the myths of Ruby's so-called inadequacies by scientifically disproving them one by one.

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?

Yehuda The competition has yielded results! Merb has proven out a bunch of ideas that the Rails core team now wholeheartedly embraces. That's only a win-win for everyone. Now that Rails will become more like Merb, it'd be great if another framework, representing a different community with different interests did exactly the same thing. Forcing Rails to acknowledge the needs of a community of people by proving those ideas out in code worked here, and it will work again.

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

Yehuda The proliferation of rspec-like frameworks has gotten a little bit out of control. I'd love to see some combined efforts there. Dave Chelimsky, who runs rspec, has said over and over that he's in favor of cleaning up the core, which seems to be the big objection that people have that causes them to go make yet another speccing kit.

Hopefully future successes here will show people that it's possible to put aside differences and build something great!

---

I also asked Kevin Clark (@kevinclark on Twitter) for his take on the merger

Kevin I think the Rails/Merb merger has potential to be good and bad for the community. A single API for a unified set of tools and plugins is a good thing, clearly, and makes it more attractive to develop software in and (maybe more interestingly) for the Ruby web space. I feel Merb got a lot of things right when reconsidering how a web framework should be built, and Rails will benefit from that. Merb at the same time is going to be wrapped up into the Rails ecosystem that's churning out documentation and libraries at a sometimes dizzying pace. A bigger community will help smooth the edges that are still sometimes rough around Merb development.

The big thing that worries me is the competition aspect of the merger. Yes, sometimes the rivalry was silly and overly dramatic, but each group pushed the other to improve and pay attention to alternate lines of though and provide something better. I hope that discourse continues publicly. The worst thing to come of this would be that debates that formerly happened in the open, and produced new insights in the open, are hidden away in rails core.

One thing to consider is that this is exactly the sort of behavior Dave Thomas encouraged in his keynote at RubyConf. If we look at Merb as an experimental fork of rails (yes, this is horridly simplified) that gained popularity and was eventually folded back into the mainline, it exemplifies what Dave thinks we need to start doing with Ruby. So, I'd encourage more forking rather than merging. Even smaller libraries benefit. Just look at the Nokogiri/Hpricot arms race.

MWRC 2008 Roundup

This year’s MountainWest RubyConf was incredible. There were a bunch of great talks, and the hallway track (though too short) was awesome. It was especially great to go hang out at the hacking suite put on by Engine Yard

I’m not going to go into too much detail about any of the talks until the video is released on Confreaks MWRC 2008 page. So far only Evan’s Keynote and Ezra’s have made it up (Gile’s talk was up briefly, but seems to have been pulled due to some audio problems).

Evan’s talk was a great peek behind the curtain at Rubinius development. Of course, since the process is so dynamic, it was kind of like peeking behind one of those clear shower curtains. Nonetheless, having Evan there as a guide pointing out the interesting bits and the philosophy made it quite interesting. It was a great kickoff to the rest of the conference.

Ezra’s talk focused on Merb and was more of a nitty-gritty kind of talk than Evan’s was. One bombshell that dropped was that there’s a Merb book in the works from Manning—I wonder if my predictions of a Ruby web framework to challenge Rails are finally going to come true. It was also interesting to hear Ezra talk about the different use cases for mongrel vs. thin or evented-mongrel.

Finally, there were a couple of neat things that won’t make the videos. We were able to raise over a thousand dollars for the Ruby Mendicant project. We didn’t raise enough money to get Steve Baker to Scotland, but it was pretty cool to have some of our speakers come up and say that they wanted to donate their honorarium to him. We even made a great donation on the local front, giving our leftover boxed lunches on Saturday (about 60 of them) to a local food pantry.

We had some great sponsors who made the conference possible. Addison-Wesley , Apress, and O’Reilly all donated books for us to give away in our binary lottery. Because of our sponsors, speakers, and attendees we ended up with a great conference. Thanks everyone!