El blog de José Rafael

Después de un largo período de enfrentamiento, los equipos de Ruby on Rails y su rival Merb han decidido trabajar juntos. El resultado es un Rails más escalable y fuerte.

Aunque creados sobre la misma base, Rails y Merb se diferencian lo suficiente como para atraer a los desarrolladores más ávidos que a menudo no se llevan bien. Sin embargo, el deseo de crear una solución más potente ha reunido a las dos partes, en un movimiento como caído del cielo para los desarrolladores de la aplicación Ruby, que buscan un Rails más escalable y fuerte.

Las que fueran antaño comunidades enfrentadas, Ruby on Rails y Merb, han decidido dejar a un lado sus diferencias y trabajar juntas para integrar lo mejor de Merb en el próximo lanzamiento de Ruby on Rails, también conocido como RoR o, sencillamente, Rails.

Continuación:

Como otras iniciativas de código abierto con tecnología parecida –Jboss y Spring, por poner sólo dos ejemplos-, los equipos de desarrollo suelen tender a no confiar los unos en los otros, o en el peor de los casos, ni siquiera gustarse entre ellos. No es ningún secreto que ha habido enfrentamientos acalorados entre las comunidades Rails y Merb. Merb se identifica a menudo como el RoR de la empresa. El equipo de Merb solía señalar que su objetivo era hacer que RoR fuera más escalable, y una de las críticas hacia Ruby on Rails ha sido que no escala bien. De hecho, cuando el pasado verano se rumoreaba que Twitter estaba pensando en dejar Rails, la primera razón que se dio fue que los problemas de escalabilidad de RoR estaban siendo un problema para Twitter. Sin embargo, estos rumores terminaron por no ser ciertos.

En diciembre de 2008, los equipos de Ruby y de Merb decidieron enterrar el hacha de guerra y poner en común algunas de sus mejores ideas provenientes de Merb para crear lo que será Rails 3.

“Nos dimos cuenta de que queríamos básicamente las mismas cosas para el desarrollo de Ruby en la Web”, explicó David Heinemeier Hansson, creador de Rails, en una entrevista para eWEEK. “Resulta que nos interesan cosas que son en parte diferentes, pero que se complementan entre sí. Así que en vez de continuar duplicando todas esas cosas que todo el mundo quería tener al mismo tiempo, decidimos unir fuerzas y poner nuestra energía en sólo aquellos aspectos complementarios de nuestro trabajo”.

Según Hansson, “los chicos de Merb están compartiendo con nosotros sus mejores ideas de Merb para Rails 3…Yehuda Katz, que fue el principal desarrollador de Merb, se ha unido al equipo central de Rails”.

En un post escrito el 23 de diciembre, Hansson escribió: “Es Navidad, y tenemos un regalo para ti. Hemos puesto fin al enfrentamiento entre Merb y Rails con la siguiente noticia:¡Merb se une a Rails 3! Todos nosotros nos hemos dado cuenta de que juntos podemos ser mucho más fructíferos que trabajando por separado y haciendo las cosas dos veces. Merb y Rails comparten tanto en términos de diseño y sensibilidad que la unión de nuestras fuerzas parecía el paso más inteligente. Todo lo que necesitábamos era sentarnos a charlar y solucionar nuestras discrepancias, y eso fue lo que hicimos”.
El antes mencionado Katz llamó a este día, “un día glorioso” para la historia de Ruby. Pero a pesar de que Merb haya decidido poner sus ideas al servicio de Rails, el equipo de Merb dice que seguirá trabajando en el proyecto Merb.

“Merb empezó con Ezra (Zygmuntowicz, cofundador de Merb) para solucionar un conocido y fastidioso problema de Rails hace dos años: su imposibilidad de aceptar cargas de archivos”, explicó Tom Mornini, consejero delegado y cofundador de Engine Yard, una compañía de alojamiento de aplicación Ruby que emplea a algunos de los primeros desarrolladores de Merb.

“Siempre vimos Merb como complemento de la pila de Rails, a pesar de que algunos en la comunidad de Rails nos vieron como competidores –apuntó Mornini-. Así que empezamos a hablar hace un año con DHH y la verdad es que no dio mucho resultado. Después reabrimos la conversación hace unas cuatro o cinco semanas y dijimos que queríamos dejar atrás nuestras diferencias; existen valores muy importantes en Merb que deberían estar en Rails, y DHH accedió”.

De hecho, como explicó Mornini: “Merb se convirtió en un banco de pruebas para las cosas que los chicos de Rails no aceptaron al principio, pero que querían hacer…Es muy interesante ver cómo las perspectivas cambian con el tiempo. Siempre hemos querido apoyar a Rails y sentíamos que estábamos haciéndolo. Pero cuando nos dimos cuenta de que la gente se veía amenazada por lo que estábamos haciendo supimos que teníamos que actuar rápidamente para contrarrestar esa percepción y tratar de asociarnos”.

“Queríamos dejar atrás el concepto de que no se puede escalar Rails, por la comunidad en general y por nuestro propio bien”, añadió Mornini.

Entonces, ¿cuáles serán los primeros frutos de esta unión entre Rails y Merb? Hansson señaló que el flujo de ideas de Merb transferidas a Rails 3 está en marcha, sobre todo el plan particular de desplegar Merb en Rails 3.

Katz dijo a eWEEK: “El equipo está trabajando duro para lanzar una preview de Rails 3 en la RailsConf 2009, que tendrá lugar en mayo en Las Vegas…En vista de los progresos conseguidos hasta la fecha, es muy posible que tengamos algo que muy bien podría representar lo que será Rails 3. No será una versión alfa, sino más bien una beta…tampoco será una RC”.

En dos post diferentes, Hansson y Katz hablan de cómo Merb está presente en Rails y de qué manera. No voy a profundizar más en esto ahora, sólo diré que los dos equipos descubrieron que tenían más cosas en común que en contra.

Y, como escribe Hansson: “En cuanto nos dimos cuenta de esto, nos pareció bastante tonto seguir con la pantomima. Aunque parece haber en el ser humano una necesidad irrefrenable de buscar los conflictos, existen objetivos más grandes y de mayor valor para unirse y dejarse de discrepancias. Sí, estoy hablando de vosotros: J2EE, .NET y PHP”.