Wow this has been a hectic, emotional week. The Rails and Merb core teams have been silently working together towards this monumental announcement. The announcement is that Merb is Rails and Rails is Merb.

Merb and Rails are joining forces and merging the two code bases for Rails-3.0. We’re targeting RailsConf for the first cut of this magic.

When I first started merb way back in the day it was just a fun little project to hack on. But it became more serious as I explored the options. I always considered merb-core a clean room rewrite of ActionPack and I think this tended to upset some people who were very attached to rails.

Fast forward to current day and Merb-1.0 has been out for a while and there is a whole brouhaha of Rails VS Merb memes on the twitters and blogs. This has to stop as it is tearing apart the community and is very non productive.

So our two teams started talking to see if we could put our differences aside and come together for the common good. We’ve laid out a roadmap of what and how to integrate merb’s best features into rails-3.0. I think we have a great plan that will make Rails the best framework in existence. It will be a blend of the best things we have discovered while working on merb, while keeping the Rails aesthetic people have grown to love.

You can expect to get a kick ass, fast, memory efficient version of rails(merb) this spring!

Merb folks will not be left out in the cold. We will continue to support bug and security fixes for the merb 1.0.x line. And we will provide a clear upgrade path to Rails 3.0 for merb apps. We still have quite a few merb apps running internally at ey and will want an upgrade path for our own apps as well.

This is going to be a lot of work for everyone involved but in the end I think this may just be the most inspiring open source story in history.

I’m so impressed with everyone involved. All the core team members from both sides have been able to put away the weapons and egos and really come together, committed to making this transition work seamlessly.

2009 is going to be a seriously strong year for the ruby community. With everyone working together, we have such a kick ass team of smart people that this whole framework thing is going to be a solved issue.

Merb is dead, long live Merb(Rails-3.0)!

• http://rubyonrails.org/merb
• http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3
• http://yehudakatz.com/2008/12/23/rails-and-merb-merge/

Today is a fairly momentous day in the history of Ruby web frameworks. You will probably find the news I’m about to share with you fairly shocking, but I will attempt to explain the situation.

Before talking tech, and even going into the details of the announcement, I want to assure everyone that the incredible members of the thriving Merb community are top priority, and that this could not have been possible without every one of them.

Merb is an open, ever-changing project, and some of its best ideas have come from not-core regular-Joe community members. It’s gotten where it has because of the community, and the community will get us even further in the future. Your ideas, feedback and even complaints will be 100% welcome in the future, just as they have been in the past. I believe in the tremendous value an open community and just generally open attitude bring to the table, and am counting on those things to continue ushering in the future of Ruby.

On to the news: beginning today, the Merb team will be working with the Rails core team on a joint project. The plan is to merge in the things that made Merb different. This will make it possible to use Rails 3 for the same sorts of use-cases that were compelling for Merb users. Effectively, Merb 2 is Rails 3.

What does that mean exactly?

• Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. We will focus on reducing coupling across Rails, and making it possible to replace parts of Rails without disturbing other parts. This is exactly what Merb means when it touts “modularity”.
• We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins. This project will also include the creation of one or more benchmarking applications, so we can more clearly see what optimizations have real-world impact.
• As of Rails 3, Rails will have a defined public API with a test suite for that API. This was one of the major differentiators of Merb. This will allow users and plugin developers to have a clearer, more stable API to build against. It should also significantly reduce plugin breakage from release to release.
• Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Of course, Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
• Rails will be modified to more easily support DataMapper or Sequel as first-class ORMs. While ActiveRecord will ship as the default ORM, the plan is to make it drop-dead easy to drop in other ORMs without feature degradation (to the extent possible, of course).
• Rails will continue their recent embrace of Rack, which is a really exciting development in the Ruby community that Merb got in on early and which we believe will improve the state of modular, sharable logic between applications.
• In general, we will take a look at features in Merb that are not in Rails (the most obvious example is the more robust router) and find a way to bring them into Rails.

How will we do this?

The plan is to start working on Rails immediately, and to continue fixing bugs and resolving other major issues in Merb in the interim. We will also release versions of Merb specifically designed to help ease the transition to Rails 3.

In particular, we will do Merb releases with deprecation notices and other transitional mechanisms to assist developers in tracking down the changes that will come between Merb 1.x and Rails 3. Expect a number of interim releases that get incrementally closer to Rails 3, and expect parts of Merb (most notably the helpers) to be ported to run on Rails 3 in order to further reduce friction.

To be perfectly clear: we are not abandoning the Merb project. There are many production applications running on Merb that are relying on both timely bug fixes and a clear path to the future. If you’re using Merb today, continue using Merb. If you’re considering using Merb for a project because it works better for your needs, use Merb. You will not be left in the cold and we’re going to do everything to make sure that your applications don’t get stuck in the past.

If you’ve already learned Merb, we will be working hard to make sure that you can parlay that knowledge into Rails 3. At Engine Yard, we fully intend to continue using Merb for our internal apps until Rails 3 is out, but we will be using those (non-trivial) applications to be sure the experience is smooth for everyone. There will be no huge jumps and you will not need to rewrite your application from scratch.

Why!?

As you have probably gathered from the above, there aren’t any clear points that the Merb and Rails team disagree on anymore. Merb has been around for roughly two years now, and we’ve proven out our ideas by use in real-world applications (like Yellow Pages, SproutCore, Powerset, Defensio, etc.). 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.

I think it’s important to acknowledge the Merb community for building something super-awesome. I really hope that we’ll all stay in this together, help each other in the coming months and in the transition to Rails 3.

Rails will be putting together a new evangelism team, which will include Matt Aimonetti (Merb core team member and evangelist) and a few other people doing Rails evangelism work. This group will be responsible for, among other things, helping the community get where we’re going. Their job will be to listen to you.

This seems crazy! Has this ever happened before?

Interestingly, yes. A very similar situation confronted the Struts developers several years back. They had built a very popular framework in Struts, but a very active group of developers were really advancing the same ideas in interesting ways in a framework called Webwork. The Webwork developers saw their project as “Struts done right”, just as we believe we’ve improved on the implementation of Rails.

Eventually, the Struts guys and the Webwork guys came to the conclusion that they would be stronger together then apart, and merged the projects. What became Struts 2 was effectively also Webwork 2, but the two communities got together to build something better.

I believe that this merger will get the ideas that gave Merb momentum into the hands of many more people, and that really serves us all. I’m looking forward to the future.

Postscript

• One of the most personally gratifying parts of working on Merb has been working with alternative Ruby implementations to make Merb run well on them. Fairly early, Merb was running faster on JRuby than MRI, and I’m looking forward to bringing a lot of that insight to Rails, and helping to make Rails to be solidly competitive on the performance front with frameworks in “faster” languages.

• The Merb Training is very much still on! We’ve spoken with the majority of the attendees, as well as with our partners at Integrum Technologies and they’re all really excited about the merger. That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game. There are still a few seats open, so sign up now if you’d like to join us!

The announcement that the Merb and Rails team are joining forces has just been made (in case you have been living under a rock, you can see Yehuda’s post here and DHH’s post here). This is truly a historic event for the ruby community. I’m sure that this news has brought up a number of concerns and emotions, as it has for me. I thought that I would recount these past few days as they lead up to the decision to join forces and hopefully alleviate some doubts that you guys must be having.

I first heard about everything this past Thursday. There had been some communication between DHH and Yehuda. The short version is that DHH had nothing but praise for Merb and insisted that he would actually like Ruby on Rails to take a similar direction as Merb, and there was talk of Merb and Rails working together. Now, to say that I took this idea poorly would be an understatement. I’ve had an idea of Rails painted in my head for the longest time. In my mind, it was a software package that enjoyed locking you into it’s way of doing things, laughed at the concept of modularity, and probably killed a few babies along the way… for good measure. How could we all work together?

Well, I thought that it would be best to hear them out, if only to know what they were planning. So, we all spent a bunch of time talking. DHH and the rails core team only had good things to mention about Merb and its philosophies. Not just general philosophies were discussed either, but specificities about implementation. The more we talked, the more it started to dawn on me that they were actually serious about making this happen. A list of a few of the points have been mentioned in the announcement. Let’s be honest, that basically is Merb.

Anyway, I’m sure you all don’t want to hear all the gory details of how I went all :emo:. It did feel for a bit like I was losing my baby. In the end though, I did reach acceptance. The truth is, Merb has won. We have proven to the ruby community that not only do our ideas work, but they are the better way to approach things. Rails is going to be adopting the Merb philosophy no matter what. I was faced with the decision of either helping them get there or fight a completely pointless battle.

So, in the end, I am proud to say that I made the choice that benefited the entire ruby community. I really believe that, together, and with a lot of hard work, we can end up with a solution that will stand true to Merb’s core tenets while at the same time keep the appeal that originally drew so many of us to ruby web development. Really, this proposition has me quite excited.

Pretty much all of the reasons I could think of to not try this ended up being moot. Such as, competition between frameworks is a good thing. Yes, it is, but we already made the bulk of our points with Merb… successfully. Hence the plan to make all of those points part of Rails 3.0. Another reason might be that personalities could clash. Granted, there is no way to know for sure until the project is actually successful, but I have not really picked up on anything that would indicate this while talking with the rails team. Really, there are a million reasons why this couldn’t work. I think that if both sides are in this 100%, we can only succeed.

I know that there are still many issues to address, such as migrating existing Merb applications from 1.x to 2.0 (aka Rails 3.0). Don’t worry, I’m in the same boat. I still have a myriad of Merb 1.0 applications to deal with, but there will be plenty of effort put into smoothing it all out. For one, once rails-core (or whatever it will be named) is done, merb-more will be ported to run on top of it. Intermediate releases of Merb which will start converging towards the common point as well as provide plenty of deprecation notices of things that change. More details of this will become available shortly on my blog, on the mailing list, and on IRC.

So, that’s that. This really is huge news and will most likely feel like a blow to merbists everywhere, but really, it shouldn’t. The people who made merb great are still going to be doing that. The community that made merb great is still going to be there. This should feel like our coming home. We’re going to be making Rails everything we dreamed of and more. We’re going to take over the world!

I’m incredibly happy to lend my support for the announcements (1,2,3) that the Rails and Merb core teams have chosen to combine their efforts on Rails 3.0!

Merb was created by as a workaround for a very early and specific performance issue in Rails: uploading photos efficiently. Since then, it’s become a full framework that had many wondering why Engine Yard was supporting a Rails competitor. We always felt that Merb was complimentary to Rails: an extra tool in your Rails toolkit. Regardless, it has become increasing clear that Rails and Merb were on a collision course that was leading to a schism in the once unified community of Ruby developers. We’re delighted that the teams are working together to avoid such a schism, and as such we fully support the merger of the teams and code bases.

Engine Yard was founded as a Ruby on Rails deployment company. Nearly every one of our 400+ customers uses Ruby on Rails! Perhaps the thing that makes me happiest about this announcement is that we will now directly support the Ruby on Rails framework by placing existing Merb resources into directly improving Ruby on Rails. We find it very fitting that we’ll now directly support the framework that has supported Engine Yard’s very existence!

Enormous kudos must be bestowed upon the Ruby on Rails and Merb core teams for agreeing to work together for the betterment of the community. Now, rather than discuss the relative advantages of Rails vs Merb, we can get back to the real business of changing the world, one developer at a time, by freeing them from the shackles of less efficient development environments.