Hacer negocio mal

Hace poco ha sido la Rails World. Como de costumbre, DHH me ha dado mucho que pensar.

7/9/25 | Álvaro Palma

DHH lo ha vuelto a hacer. Nos ha dado una chapa de una hora, entre vítores y diapositivas con un humor un poco basicón.

Si seguís a DHH de cerca, sabréis que hablando de software nos llevaríamos muy bien; pero a la hora de hablar de temas humanos y sociales seguramente llegaríamos a los puños. A veces tiene... opiniones. Por ejemplo sobre que a les niñes no hay que enseñarles sobre identidad sexual. Otra veces, directamente alaba al fascista de Jordan Peterson. No hablemos ya siquiera de su opinión sobre la cultura WOKE.

(Me siento sucio compartiendo todo esto).

Pero en lo referente al software y a las prácticas "empresariales" de los frameworks open source, me parece que tenemos muchísimo que aprender.

DHH creó Rails en 2004. Su principal objetivo fue empoderar el desarrollo individual para permitir que una persona pudiera hacer el trabajo de 10. Creo que viendo el éxito de GitHub, Shopify y (los desgraciados de) Airbnb, así como los miles de productos que se han constituido gracias a RoR, nos ha enseñado que iba muy bien encaminado. Cumplía su promesa. Creó algo espectacular e innovador para la época. Me atrevería a decir incluso que esos adjetivos siguen siendo aplicables al panorama del software actual.

DHH tiene una empresa. 37signals. Posiblemente sea la principal empresa que acelera el desarrollo de RoR; pero, por supuesto, RoR es open source. Tiene detrás una comunidad espectacular que hace que el framework avance. Aunque pensemos que RoR está muerto, nada más lejos de la realidad. Lo único que pasa es que "es aburrido". Aboga por la manera más tradicional de hacer web; y creo que en el mejor de los sentidos.

Por lo general, cuando juntamos los términos "empresa" y "open source", obtenemos un mejunje art attack que huele a rancio. Esto nos lleva pasando en el ecosistema de JavaScript desde que Vercel tomó los mandos de player one. NextJS, posiblemente el meta framework más famoso de JavaScript. Es open source, sí, pero dado que Vercel tiene una empresa de hosting, no es de extrañar que apliquen un vendor lock in que no entiendo cómo hay gente que sigue usando NextJS. Vercel gana dinero diciéndote: "Oye, hacer self-hosting es super complicado. Mejor utiliza nuestra plataforma. BTW usar nuestra plataforma es la única manera de hacer que NextJS no apeste".

Laravel meets capitalism

Me atrevería a decir que estamos viendo lo mismo con Laravel. Si echamos un ojo al histórico de su documentación, veremos cómo parece que esta ha ido "empeorando" en las áreas en las que los productos de pago de Laravel están metiendo cabeza. Ahora tenemos Laravel Herd, que te viene a decir "Oye, desarrollar Laravel en local es super complicado, mejor usa nuestra herramienta de pago". Qué risa que hayan quitado de su documentación la sección de Docker del apartado "Getting started". Recuerdo la primera vez que inicié un proyecto de Laravel en local. Fue literalmente lanzar dos comandos y tener la aplicación funcionando: con reverse proxy, base de datos, MinIO, Redis, PHP y la CLI de Laravel...

Nada complicado. La verdad es que buen trabajo por parte del equipo de Laravel. Se sentía que te estaban empoderando realmente. Luego simplemente era cuestión de cambiar cuatro variables de entorno y mover el docker-compose a un VPS con docker y listo, ya tenías tu app en producción con la misma facilidad que en local.

Ahora, Laravel tiene una plataforma de despliegues también. La documentación sobre cómo desplegar una aplicación de Laravel no ha cambiado mucho desde la versión 5.x; pero me pregunto cuánto tardarán en hacerle un downgrade igual que han hecho ya con el "Getting started" y Docker.

Una cosa que me llama mucho la atención y hace que se me levante la ceja es que han quitado su famoso bootcamp sobre Laravel. Según dicen es "porque están trabajando en un nuevo tutorial". Yo creo que es para que tiremos más hacia Laracasts (de pago).

Y, mientras tanto, Ruby on Rails...

... Aboga por todo lo contrario. Tener una aplicación de RoR corriendo en local y lista para el desarrollo es lanzar un comando. Está pensado en darte absolutamente todo lo que necesitas, de principio a fin, sin absolutamente nada de pago. Hasta desplegarlo en un VPS de cuatro (4) euros es literalmente un comando gracias a Kamal (que por cierto te sirve para cualquier app con un Dockerfile, no solo para RoR).

Rails abstrae las complejidades del día a día; y lo hace de forma totalmente gratuita. Por su parte, Laravel, Next y otros frameworks patrocinados por empresas de despliegues (te miro a ti, Symfony) lo hacen a expensas de tu bolsillo.

Predicando con el ejemplo

Mira, lo entiendo. Yo mismo también tengo proyectos open source que me encantaría que la gente usara; pero tengo un trabajo a tiempo completo que me roba tiempo y energía vital, de modo que no puedo garantizar una herramienta estable. Entiendo que necesites ganar dinero y que esto es bueno para la comunidad, porque te garantiza la supervivencia del framework y lo convierte en una opción más robusta y confiable.

Pero creo que hacer negocio con el framework, es hacer negocio mal. Por su parte, 37signals hace una cosa preciosa: predica con el ejemplo. Usan Rails para construir sus productos con los que realmente ganan dinero. Las funcionalidades que implementan en Rails responden a sus necesidades del día a día; y colateralmente resuelven las necesidades de producto de los equipos que también usan el framework. Así es como han llevado a Rails a lo que es hoy en día.

No ganan dinero diciéndote "esto es demasiado complejo, mejor usa mi producto o el producto de nuestro patrocinador". Al contrario, ante este panorama, han decidido "Así que Vercel te está diciendo que es muy complejo desplegar y mantener una app en produción, ¿no? Pues toma esta herramienta open source, gratuita y descapitalizada para que no sea tan complejo".

"Así que hacer frontend ahora es super complicado, ¿verdad? Pues toma todo este conjunto de herramientas para que puedas seguir teniendo tus aplicaciones monolíticas funcionando a la antigua usanza, pero con una experiencia de desarrollo frontend más moderna y sostenible; y que responde a las nuevas necesidades de UX".

"Así que hacer pipelines de CD/CI se ha vuelto una mierda... Pues te regalo toda una filosofía y un tooling que evita que tengas que comerte la cabeza".

Así es. Software a la antigua usanza, pero respondiendo a las necesidades de desarrollo modernas. No necesitan DevRels ni gastarse una pasta en publicidad. Demuestran cada día en sus propios productos la valía de su ecosistema.

Y nosotras nos tragamos el cuento

Empecé a programar en el 2020. Para aquel entonces, ya teníamos la dicotomía frontend y backend; pero también estábamos viendo la vuelta del Full Stack. Si llegaste de nuevas al mundo del desarrollo, seguro que te suena la historia. El famoso "MERN" stack. Lo que te cuentan en cualquier vídeo introductorio al desarrollo Full Stack. Empiezas por front porque es lo más fácil para que te contraten; y luego sigues con JavaScript para hacer el backend de tu aplicación. Si quieres renderizado en el servidor, usa NextJS, que además se basa en la E(xpress) de MERN, así que estarás como en casa.

Ignora temas de despliegues. No aprendas cómo funciona un servidor, no aprendas protocolos de transferencia, seguridad, ni nada por el estilo. De eso ya se encargará la gente especializada de la empresa en la que te contraten. Pero si quieres hacerte una applicación para portfolio o para que te dé dinero... Pues no te preocupes, despliégalo en Vercel.

Y así tenemos una nueva generación de desarrolladoras Full Stack que se quedan en lo básico y a quienes les suena a misterio cómo funciona un servidor. Yo mismo he tenido que salirme de la rueda por las malas, cansado de tanta complejidad, pero inspirado y apoyado por mis ganas de aprender y por Rails y DHH, quienes me enseñan que no estoy solo y que no es tan difícil. Solo tienes que aprender a usar las herramientas adecuadas. Las herramientas que te empoderan. Las herramientas que te ayudan a hacer del desarrollo algo más ameno y que nos recuerdan que, mucho tiempo atrás, desplegar una app era arrastrar un index.php a una carpeta en tu servidor.

Por una web más justa para todas, miremos hacia un ecosistema que nos empodere y que no nos trate como a panolis. Ya sea para meternos de lleno, o, como en mi caso, para simplemente aprender y trasladar el mensaje a ti que me estás leyendo.