Merb/Rails merge, or Why should merbists be happy?


December 23, 2008, was an important day for the Ruby community. People who used to argue and not get along, have decided to sit down, talk and evaluate their differences. The end result is a strong collaboration of two teams who share the exact same goal.

Overall, the news was very well received, just look at the tweets out there and the comments on Yehuda’s and Rails’ blogs.

Interestingly enough, the Rails community really embraced this decision and just got totally excited about the perspective of merging merb’s philosophy and expertise into Rails. If you re-read David’s blog post you can see that it’s a real homage to Merb.

The rest of the internet sounds pretty happy about the news, here are few posts:

Even Zed the entertainer thought it was a good thing:

“I honestly didn’t think that would ever happen. I just assumed that Merb
would eventually wipe out Rails by being the better framework, or they’d
wipe each other out soon.

So, congrats are in order. You guys are finally grown-ups and now have
the chance to make something better.”

Some merbists like Jade Meskill really understood what we are trying to do while some other ones got really mad at us.

I think a pattern emerged from the negative reactions:

  • Why merge when we are about to win?!
  • What does Merb win by being merged into Rails?
  • Why not merge Rails into Merb?
  • You are killing innovation by killing the competition
  • You screwed us over and now I have to go “back” to Rails
  • Rails 3.0 won’t even be as good as Merb 1.x
  • The Rails team won’t let you do what you have to do to merge Merb into Rails
  • DHH is a jerk

Let me quote Yehuda:  “Calm yourselves ;).

Why merge when we are about to win?!

This is probably the most rational argument. This is also something the Merb core team considered for a little bit.
Merb is gaining huge momentum and the target audience was very reactive to what we did.
People such as Yellow Pages, Wikipedia and even Adobe started using or looking seriously at Merb because of its focus on modularity and performance.
We started building an elite community and we were pretty proud of that.

But take a moment to think about it. Our goal has never been to hurt or compete with Rails. Our goals were to get modularity, performance and a strong API. If the Rails team really wants that, and will work on it, why should we work against each other?
It’s not about winning or losing. It’s all about the long term plan of your framework, about the people involved and the community behind it. We had to take ourselves out of the equation and consider what would be good for the Ruby community.

What does Merb win by being merged into Rails?

People seem to easily find things we might lose but have a hard time finding things we are gaining.
Looking at it on the very short term, this is probably correct. The merb team will have to learn how to work with the Rails team.
We need to understand the reasons behind every single aspect of the code and find ways of merging things nicely.
On top of that, we still need to work on merb as promised. (see Wycats’ post)

However, in the long term we get all the benefits of Rails:
- stability
- community
- traction
- experience
- don’t have to always justify why use Merb instead of Rails

But more importantly, we extend our team.

Most people using a framework might not realize what it is to work on a big Open Source project.
When you work on an OSS project, people come and go, and that’s why you usually have a core team of people you can rely on.
Merb has a lot of contributors but a small core team of 5 people (Yehuda, Carl, Daniel, Michael and myself).
Managing a project, such as merb, requires a tremendous amount of time and patience. Rails has the same problem with its core team of 6 people. People have lives, business, projects etc…

Joining two teams of experts in developing web frameworks in Ruby is like if in the next Soccer World Cup, the French and Italian teams would go on the fields at the same time to beat other teams. 22 players on 1 side, training and learning together. American readers, please imagine the Giants and the Colts facing the Green Bay Packers (I was told I don’t like the Packers).

Long term, you will get better quality and more frequent releases. We also have different world views and backgrounds which means we will learn a lot from each other, again that means better code for you guys :)

Why not merge Rails into Merb?

That’s actually a good question. We discussed maybe using merb-core as a base for Rails 3.0
The truth is that Merb 2.0 would probably be as big as Rails but more modular.
So we have the choice to keep on building on top of Merb 2.0 or deconstruct Rails.
As the Russians say: ‘ломать — не строить’, it’s always easier to take things apart ;)

Rails already has a test suite, it has already been tested on the wild for a while and its internals are known to many developers. Taking apart the code to make it faster, cleaner and more modular is arguably easier than reinventing the wheel. At the end of the day it doesn’t really matter from which end you start as long as you end up with the same result.

Some people even asked to come up with a new name for the merged project. Meails, Mr Ails, Reverb, Reab were suggested. While I thought it was a joke, some people were really serious. Can you imagine if during the recent bailout, banks changed names every time they were purchased by another bank? People would be super confused and would not even know where to send their mortgage payments.
On top of that, Rails has a huge user base compared to Merb and has an immense brand recognition in the world at large, it would be foolish to throw that away.

Let’s not be chauvinistic and see what’s best for all.

You are killing innovation by killing the competition

Again, a good point but my question to you is: Should we stay in the competition just for the sake of it?

Rails clearly told us: we want what you have and we would love you to work with us. So the options were:

  • tell them to go to hell and let them try to redo what we already did and know how to do.
  • accept to work with them and make Rails a better framework.

Option 1 would keep the competition alive, but now you have 2 groups of people trying to do the same thing and being better at different aspects. The community gets confused and communication breaks.

Option 2: we lose the Merb vs Rails competition, but we double the amount of people working on Rails and therefore increase the change to make it better faster.

We went for option 2 and we know there is already some competition out there and there will be more coming up soon. I don’t think it’s realistic to expect us not to merge because we want to keep the competition going.

You screwed us over and now I have to go “back” to Rails

Yehuda will blog about some more detailed examples as we are making progress, but you need to stop thinking that Merb will just be absorbed into Rails.
If Rails just wanted to add some “Merb flavor” to Rails, they would have just taken whatever they needed and would not be interested in a merge.
See Rails 3.0 as a new generation of Rails, whatever we promised you for merb 2.0 plus all the goodies from Rails. Rails users will still have their default stack and all choices will be made for them (like in the current Merb stack). The difference for standard Rails user will be better performance, a static API and an option to go off the “golden path”.
Merbists won’t lose the stuff they like in Merb, stacks, full support for DataMapper, Sequel and other ORMS, jQuery or other JS library, opt-in solution using just rails-core, better core isolation, built-in RSpec and webrat support, slices, merb-cache, merb-auth and all the other key plugins that will be ported over.

To be able to achieve all of that, we will have to make some infrastructure and code modifications.

Rails internals should end up:

* way less magical (even Merb uses some magic, but we’ll make sure to keep it to a minimum)
* returning shorter and cleaner stack traces
* cleaner (required for the new API)
* better isolated (required to increase the modularity)
* alias_method_chain won’t be available at the public API level (we probably still will need some chaining mechanism internally, but that’s a different story)

So, no, you don’t have to go “back” to Rails. In fact, imagine you could do exactly what Rails does but with the performance and modular architecture of Merb. That’s what you will get with Rails 3.0.

Rails 3.0 won’t even be as good as Merb 1.x

I think I mainly replied to this question in my previous answer.
There is no reason why Rails 3.0 won’t be better than Merb 1.x.  Actually, I believe our API will actually be even better. With the help of David, the existing Rails core team, and the Rails community, we will be able to define an awesome API that will change the way ruby web development will be done.
The merb API is great but we already know some of its limitations and we don’t have as many plugin developers to work with. Working with plugin developers is something I’m personally excited about. As a Rails developer I have been really frustrated when using 3rd party plugins and trying to develop my own.
Having a well tested, developed against, public API will make all the Rails 3.0 plugins so much better. And because Merb plugins already use an API, we will be able to port all the plugins over, so it will be at least as good as 1.x
Also, we are going to work on real app benchmark tests to make sure the performance gain is at least as good as what we have with Merb.

Migration will be easy and well documented. We are not giving up on the Merb book and it will be very useful to explain the Merb way to new comers wanting an idea of the new stuff in Rails 3.0. It will also be the best source of information to migrate your app to Rails 3.0.

Talking about migration, we promised to give you a sane migration path when it will be time to migrate.
Again, don’t freak out because we are changing the name, the spirit of Merb will keep on living.

The Rails team won’t let you do what you have to do to merge Merb into Rails

In all honestly, I was worried about that. I was wondering if all of that was not an evil scam planned by DHH to kill Merb as it was getting a good momentum. I like conspiracy theories and it sounded pretty good.
To my surprised, after a few private conversations with David, I realized that he was genuinely interested in making Rails better for people and fulfill the needs of people who need more flexibility.
Just re-read his blog post http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3. After what he said, how can he back up and just keep Rails the way it is? And why in the world would he want that to happen?
It’s a team effort and we have already spent hours and hours discussing some details. I can promise you that the Rails team is very excited about the new stuff that’s coming up. But don’t forget that it’s a merge and we are reconsidering some of the stuff we did in Merb to better re-implement them in Rails 3.0.
So far, I haven’t seen any of the Rails core team member tell us, no you can’t do that because that’s not the way it’s done in Rails or because we just don’t like it.

DHH is a jerk

Recently, in an interview I gave to rubylearning.com http://rubylearning.com/blog/2008/12/18/matt-aimonetti-why-on-earth-would-you-ignore-merb/ I mentioned that a big difference between Merb and Rails was the way we were dealing with the user base.
I quoted David from an Interview he gave to InfoQ http://www.infoq.com/interviews/David-Hansson back in 2006.

As part of the merging evaluation process we literally spent hours talking back and forth. I had a seriously hard time believing that Rails and David honestly wanted to change their world views. How can you go from saying what you said in 2006 to adopting what Merb is pushing for: letting the framework bend to make what each developer wants if he doesn’t want to follow the “golden path”?

Interestingly enough, David recently addressed this point on his blog. http://www.loudthinking.com/posts/36-work-on-what-you-use-and-share-the-rest

“I wanted to take a few minutes to address some concerns of the last 4%. The people who feel like this might not be such a good idea. And in particular, the people who feel like it might not be such a good idea because of various things that I’ve said or done over the years.”

First thing first, David addresses the minority of people worried about his image and what it means for them.
So, David actually cares about hard core merbists and he wants them to join the fun. I personally see this as something very encouraging!

A recurring theme we hear a lot is that Rails becomes whatever DHH/37signals needs/wants. If DHH needs something new, it will make it to Rails, if he doesn’t need it, it won’t.

David has a very simple and almost shocking response: DHH != Rails

David is really happy with Rails. Rails satisfies his needs but he knows that some people out there need/want something more/different.

“I personally use all of those default choices, so do many other Rails programmers. The vanilla ride is a great one and it’ll remain a great one. But that doesn’t mean it has to be the only one. There are lots of reasons why someone might want to use Data Mapper or Sequel instead of Active Record. I won’t think of them any less because they do. In fact, I believe Rails should have open arms to such alternatives.”

So, you can still think whatever you want about David. What’s important is that Rails is more than David. It’s an entire team of people with different needs and different views.

DHH isn’t a dictator and based on concrete examples such as the “respond_to vs provides” discussion, I can reassure you that David has been very receptive to arguments and never tried to force any decision because he thought it was better.


Similar Posts

, , ,

  1. #1 by Matt Aimonetti - December 25th, 2008 at 20:54

    If you have any questions and/or want to know what’s going on with the merge and Rails 3.0, follow me on Twitter: @merbist http://twitter.com/merbist

  2. #2 by Bradly Feeley - December 25th, 2008 at 21:33

    Thanks for addressing what merbists get out of the deal.

    I think what a lot of merbists are having a hard time with is why there wasn’t any community involvement in the decision. Either the majority of the Merb community would have been for the merge and there would be no problem, or the majority would be against it and maybe some other path should be taken. Full disclosure is always appreciated. I’m scared to think the reason the Merb community wasn’t involved is for fear the merge wouldn’t go over well.

    Couple other quick questions… Is the admin slice that was billed for Merb 2.0 going to make it into Rails 3? Also, in the MerbCamp keynote Yehuda talked about regular releases for Merb. Any idea on when Rails 3 will see the light of day? Thanks.

  3. #3 by TJ Stankus - December 25th, 2008 at 21:55

    Thanks for this writeup and addressing everyone’s concerns. I’m pretty psyched about this merge and trust that great things will come from the core team and the community.

  4. #4 by Dan Kubb - December 25th, 2008 at 22:07

    Now that the decision has been made to go forward with the merge, I think further discussion needs to happen in public mailing lists and public IRC channels. I’m not precisely sure where it’s happening now, if at all due to the holidays, but I hope it’s not behind closed doors. I realize it’s still really early, but I would hope the plan is to allow everyone access to the discussions and not have it filtered through a few “inner circle” member’s blogs.

  5. #5 by Luke Sutton - December 25th, 2008 at 22:09

    I think I might have been a little intemperate in the way I framed my objections, but in general I stand by what I’ve said. What’s most offensive is the secrecy.

    Since then I’ve had some time to calm down and think about things a little more clearly, but I’d be lying if I said I wasn’t still somewhat resentful.

    Also Matt, I’ve been told you tried to leave a comment on my post only to have it disappear into the aether. I must have accidentally left commenting off. My apologies.

  6. #6 by Matt Aimonetti - December 25th, 2008 at 22:20

    @bradly

    “Full disclosure is always appreciated. I’m scared to think the reason the Merb community wasn’t involved is for fear the merge wouldn’t go over well.”

    Good question, the answer is no. However, in all honestly even though we do everything we can to serve the community, it’s still up to the core team to decide what we want to work on and how we want to do it.
    We did expect that few people would not see things the same way we did. You guys did not spend hours talking with the Rails team and evaluate if our objective is reachable or not. I hope this answers makes sense and won’t offend you.

    “Couple other quick questions… Is the admin slice that was billed for Merb 2.0 going to make it into Rails 3?”

    That’s still the plan, we’ll see how it goes but there are no reasons why won’t have an admin-slice for Rails 3.0 (however, that’s obviously not one of our top priorities)

    “Also, in the MerbCamp keynote Yehuda talked about regular releases for Merb. Any idea on when Rails 3 will see the light of day? Thanks.”

    We will keep on releasing regular versions of Merb until Rails 3.0. Rails 3.0 Beta is scheduled for RailsConf 09. In the meantime, we didn’t discuss branch releases, we might do nightly releases like we were doing with Merb 1.0 however that was not discussed with the team.

  7. #7 by Matt Aimonetti - December 25th, 2008 at 22:34

    @Luke Yeah I tried to post a comment but I ended reusing some of the content in this blog post :) I understand your frustration and why you are mad, but you need to believe us, Rails 3.0 is just like Merb 2.0 and you will need to migrate your app the same way you would have to migrate it to 2.0

    I’m not sure if you are more upset about the fact that the next release will be called Rails or the fact that you don’t think we can deliver what we promised.

    @Dan Some of the low level discussion will still happen within the new team as we did before we merb, but we will try to be as open as possible. Yehuda and David are already planning on blogging about the new API changes we’ve been discussing. I’m also working on the plans for the new Evangelism team and part of the task will be to have a clean and open relationship with end users.

  8. #8 by jaigouk - December 25th, 2008 at 22:48

    Wow. You literally read “all” the articles! Thanks!

  9. #9 by teamon - December 26th, 2008 at 01:49

    I still can`t understand why not to take merb-core as base. Why not starting with something better already?

  10. #10 by Matt Aimonetti - December 26th, 2008 at 02:04

    @teamon, it’s not better, it’s lighter. We have much less things in our code. Anyways, we are going to use big chunks of our code like the router for instance. David is playing with the Merb router and seem to really like it. The entire team is working on optimizing the API and so far it looks really good. Backward compatibility should be covered since Carl did an awesome job decoupling merb router’s code generation from the DSL.

    The only thing I can tell you, is that you have trust us on this one :)

    - Matt

  11. #11 by Botanicus - December 26th, 2008 at 02:36

    Hey Matt,

    thank for your post. I hope everything will go OK and Rails 3 will be awesome. I’m quite calm because I believe in Merb core team. But it’s the only reason, must to say I don’t like rails code, its (for me) too huge community etc.

  12. #12 by neovintage - December 26th, 2008 at 07:25

    Matt –

    Thanks for taking the time to go through some of the points that you’ve heard in the community. You’ve quelled some of the doubts that I had, unfortunately, I’m still a little cautious about this. Technologically, I’m sure everything will work out because all of the core team members are sharp guys. The part that will take much more work to get right is actually meshing the different user bases and overcoming some of the bad misperceptions about the rails core team from years past. Your point ‘DHH is a jerk’ addresses some of that, but I think the core team will now need to spend way more time managing the community versus actually maintaining the code. Getting that part right will be extremely hard.

  13. #13 by jimhalberg - December 26th, 2008 at 08:24

    I just wonder what Rails 4 looks like. If we’ve already stopped referring to half the team as “the merb guys” and everyone is working together to push things in the right direction – it’ll be a huge win… hopefully that actually happens.

    … and whoever told you not to like the Packers is not to be trusted ;)

  14. #14 by Curtis Abbott - December 26th, 2008 at 10:25

    I haven’t seen much commentary yet on the way merb treats render and its form helpers. I strongly hope there will be a backwards compatible way in the merged world to stick with that design because it’s one of the aspects of merb that I’ve found most excellent compared to rails. Once you get outside the standard ORM object to view paradigm I found myself resorting to ugly hacks like render_to_string in rails. Merb’s approach might be less congenial to MVC purists but it’s a Good Thing when you’re trying to do complex user interactions.

    Other than that, there are obviously risks in merging development teams but it sounds like a good plan so I’m rooting for it to be a big success!

  15. #15 by Stephen Bannasch - December 26th, 2008 at 11:13

    Great news.

    Where is the merged code going to be? Trunk or branches in the rails repo?

    Once there is a branch to work on on think people will find it very exciting to work on the new code.

    I think it’s quite possible a working release from this merge will happen sooner than the next RailsConf.

  16. #16 by Matt Aimonetti - December 26th, 2008 at 11:41

    @Curtis the helpers are in the list of things to discuss, I can’t promise anything yet, but we will let people know as soon as we have an idea of what we are going to do. Thanks for your support

    @Stephen http://github.com/rails/rails/tree/3-0-unstable and http://github.com/wycats/rails/tree/master

    - Matt

  17. #17 by UiPoet - December 26th, 2008 at 18:22

    @Matt, I think Merb 1.0 is a solid, fully usable framework. I enjoy developing Merb applications and intentionally stopped developing in Rails.

    At Merb Camp, I never heard the Merb core team say they were merely striving to mimic the “goodies” of Rails. I believed that Merb 2.0 would have attained even higher levels of customization and performance.

    What critical capabilities does Rails have that Merb is missing? I have read no technological explanation, only cheerleading in praise of amassing more team members. In my experience, overgrowing a team by even only one can stall out a perfectly running machine.

    I planned to work a ton on my Merb Slices this holiday. Instead, I find myself obsessively rereading senseless blog posts and holding back from spewing venomous comments. I just don’t have to heart to work on projects that now seem a waste of time.

  18. #18 by sensei - December 26th, 2008 at 18:28

    Actually the helpers relates heavily to the public API. That’ll be pretty much the only contentious issue as far as I can see – the public API, the router and the helpers – they are all basically the same issue, and that is how the entire framework maps objects in and out of itself.

  19. #19 by solnic - December 27th, 2008 at 05:48

    Matt,

    We all appreciate your effort in trying to explain the decision; however, there are still a lot of angry people because they’ve spent a lot of their time working on merb-based applications and now continuing their work doesn’t make any sense because of the merge.

    We were waiting for the first stable release of Merb struggling with constant API changes and when things have finally settled down by releasing Merb 1.0 we’ve got highly unexpected news about the merge…

    Personally I think it would be much better if the community was aware of your merb-rails discussions about the merge. The shock could be smaller.

    You have completely ignored the community. Very DHHish ;)

    From a technical point of view, I have one important question. For new apps, should we choose Merb 1.x or Rails 2.x? What is going to be easier, a transition from Merb 2.0 to Rails 3.0 or from Rails 2.x to Rails 3.0?

    Thanks,

    solnic

  20. #20 by Claus Menninger - December 27th, 2008 at 07:11

    wonderful article. That explains a lot about the benefits of the merger.
    Will Rails 3.0 be based on Ruby 1.9 or also support 1.8?

  21. #21 by Robert - December 27th, 2008 at 08:08

    To add, I think the community is also a bit bewildered due to the fact that the merb core team talked so much about Merb as the alternative to Rails. There was so much promotion of pushing Merb as another choice and how great the future is of Merb – by itself. Then, in a matter of a week or less, with the same talking going on, the community is now told Merb is merging into Rails – removing Merb as the alternative.

    Many people in the community, including myself, have written patches and contributed to Merb. We’ve sold the idea as it was sold to us. Now the idea will fade away, as it is.

    Dismissing these feelings and emotions as being “emo” – as did some of the core team in #merb – shows a lack of caring for those who [the community] actually made Merb popular – the community got behind it.

    One day Merb Core is telling everyone that Merb is the alternative, with a differently philosophy and goals. The very next day – from the eyes of the community – the community is told that really Merb has the same goal and ideas as Rails and, in fact, they are merging.

    Now, from my point of view, something changed. Either what the Merb Core team told everyone was a lie and Merb was really intended to be Rails, the idea of being a Rails Core Team member was too attractive, money or fame was involved, or the Merb Core sold out. I doubt it was being on the rails core team or money/fame – that leaves me with two choices, from my point of view and I doubt I’m the only one that sees it that way.

    Either way, I feel the community was sold out by the Merb Core team. We bought your ideologies, we sold them, we helped build Merb and contribute to it, only to have, as Luke stated, the rug pulled out from under us.

    I’m sure Rails 3.0 will be great, and my post here isn’t really about how the “code” will be, but rather the politics that went on. Also, this isn’t anger, but rather disappointment. It doesn’t seem like the Merb Core team thought about the community [Merb Community] in this decision – we had no say in what we helped to build and sell. Merb was suppose to be about community, while Rails *was* about scratching DHH’s itch.

  22. #22 by Matt Aimonetti - December 29th, 2008 at 12:47

    @solnic

    “From a technical point of view, I have one important question. For new apps, should we choose Merb 1.x or Rails 2.x?”
    It depends on your needs. If you need the modularity and performance, the go with Merb, if you want a stable, full stack experience, go with rails.

    “What is going to be easier, a transition from Merb 2.0 to Rails 3.0 or from Rails 2.x to Rails 3.0?”
    It should be easy in both situation. Again, it depends on your needs.

    @claus

    Rails 3.0 will support Ruby 1.9 and at least 1.8.6/7

    @Robert

    “One day Merb Core is telling everyone that Merb is the alternative, with a differently philosophy and goals. The very next day – from the eyes of the community – the community is told that really Merb has the same goal and ideas as Rails and, in fact, they are merging.”

    Merb did not change its view philosophy and goals. I believe what happened was that the merb community as a whole convinced the rails team that we had a good point and there is a big chunk of the Ruby community interested in something different than a full stack. At the same time, we (the core team) have been focusing on making an opinionated full stack since 0.9.x.

    “Either way, I feel the community was sold out by the Merb Core team. We bought your ideologies, we sold them, we helped build Merb and contribute to it, only to have, as Luke stated, the rug pulled out from under us.”

    I can understand why you would think this way. However, I strongly believe that at the opposite, our ideologies that you help build is now going to be part of Rails itself. I think what bothers you more is that you don’t believe Rails can change and adopt the merb’s philosophy. There is nothing I can say that will convince you, we would just have to wait and see.

  23. #23 by David Burry - December 29th, 2008 at 23:46

    Matt, please don’t say “just trust us” as that sounds almost overbearing (though I know you personally so I know you don’t mean it that way)… Science and innovation goes forward not simply by trusting, but by asking the hard questions and not giving up until the difficult answers are found.

    Regarding people saying we need competition… well, that’s true, in a selfish culture and society where everyone is looking out for themselves only (which is most of the business world, and many political circles, and is core to human nature to some extent), then the friction of everyone pulling against each other makes them pull harder and do greater things. However, in a more altruistic culture (which includes some open source communities) cooperation can actually accomplish a lot more than competition ever could, because you’re not wasting energy pulling against someone else, but pulling with them, everyone together to reach common goals together. It’s a doubling of effort, instead of duplication. Of course that assumes the cooperation actually *works* and isn’t broken down by some sort of internal struggles (personality clashes, personal selfishness, egos, laziness, lack of ability, lack of vision, getting stuck in a rut and comfortable with tradition, insecure or misguided leadership, etc). If any of that happens then competition will be back soon enough to shake things up, I’m sure. I’ve also found that competition with myself (trying to out-do myself) can be just as good of a personal motivator as trying to out-do anyone else, if I approach it with the right mind set, and this can allow me to cooperate with other people too at the same time instead of compete against them. Perhaps I should be taking such philosophical debates elsewhere though… ;o)

    So we’ll see how it all turns out, so far it’s sounding pretty cool though.

  24. #24 by sliu - December 30th, 2008 at 08:31

    @Rails core team & Merb core team:
    You all did good work, and I appreciate much, and much.
    my concern is:
    * Don’t let politics or business pollute technical decisions.
    * You decided merge, then you chose the FUTURE, not the past. Considering future before decide will be wise.
    * Public static API should(and always) base on a good design and internal code.
    * Compliant and migration issues should be considered systemically as an outer and not-top-important slice.
    * Throw dirties away.
    * follow “Do things right & Do right things” rule.
    * interact tightly with community for everything: decision, plugin, docs…

    I am eager to see the awesome work, and hope you feel lucky and happy when rails3 release.
    finally, thank you for your work again.

  25. #25 by Robert - January 2nd, 2009 at 17:48

    “Merb did not change its view philosophy and goals. I believe what happened was that the merb community as a whole convinced the rails team that we had a good point and there is a big chunk of the Ruby community interested in something different than a full stack. At the same time, we (the core team) have been focusing on making an opinionated full stack since 0.9.x.”

    That kinda proves that competition was and is good for Rails. However, I’m not naive to think that just because the two groups are coming together that innovation will stop – it *might* not be as it would, if were merb to say on it’s own. We’ll just have to wait and see.

    “I can understand why you would think this way. However, I strongly believe that at the opposite, our ideologies that you help build is now going to be part of Rails itself. I think what bothers you more is that you don’t believe Rails can change and adopt the merb’s philosophy. There is nothing I can say that will convince you, we would just have to wait and see.”

    I really, really don’t like when people tell me what I think or feel. What I was saying didn’t have anything to do with Rails specifically. It was more about how the Merb Team decided, without the community, to merge with Rails. Merb has always been “the community” framework while Rails had been known to be DHH’s framework. Nothing is wrong with either, it’s just how it was and yes, I know Rails has become more than just a framework to scratch DHH’s itch.

    I’ve had a few opportunities to talk with David and my overall impression has always been that if you can convince him that something is better than he is all for it. It wasn’t something that just radically changed in the last few months nor is it anything different then how most of us are. So, as I said, it’s not that I don’t think DHH or Rails cannot be convinced that something might be better, it was just how Merb made such a sudden shift (less than a week) from talking about Merb’s future, 2.0, better/different than Rails (which it pride itself on) to signing kumbaja together. In that timeframe, the merb community, the ones who have been there since 0.3 or earlier, were left.

    Anyways, I’m over it. Good luck with the merge!

Comments are closed.