Drupal va camino de ser el COBOL de la web

Hay posts que se escriben por curiosidad técnica y otros que se escriben porque no te queda otra. Este es de los segundos. Después de 16 años trabajando con Drupal de forma ininterrumpida —y de comerme un despido por el camino—, la pregunta dejó de ser “¿qué módulo uso?” y pasó a ser “¿tiene sentido seguir apostando por esto?”.

La respuesta corta: Drupal no va a desaparecer, pero su rol cambió. La respuesta larga es este artículo.

16 años de Drupal y un mercado que se enfría

El primer síntoma no fue técnico. Fue ver LinkedIn todos los días después del despido. La cantidad de ofertas de Drupal cayó drásticamente, y lo que queda tiene un patrón muy reconocible:

• Mantenimiento correctivo y evolutivo de plataformas heredadas.
• Migraciones de versiones ya existentes (Drupal 7 → 9 → 10).
• Muy pocas veces, proyectos nuevos construidos desde cero.

Ese último punto es el que importa. Un ecosistema que solo se dedica a sostener lo que ya existe está, por definición, en fase de declive: no hay cantera de proyectos que justifiquen contratar gente nueva.

Y no es una percepción aislada. Acquia, una de las empresas insignia del ecosistema, viene ejecutando despidos colectivos de forma recurrente desde finales de 2022. A eso se suma un envejecimiento paulatino de la comunidad: cuesta ver relevo generacional. Nadie que está empezando elige Drupal cuando tiene Symfony, Laravel o Next.js al lado. La pregunta incómoda es si eso es una mala racha o un cambio estructural.

Drupal fue diseñado para equipos humanos, no para LLMs

Acá está la parte interesante, y es donde el artículo se vuelve técnico.

Drupal apareció para resolver un problema real: que equipos humanos pudieran trabajar en paralelo sin pisarse. La solución fue desacoplar todo mediante capas de abstracción — sistemas de plugins, servicios, hooks, y una cantidad generosa de archivos YAML. Para una persona con años de experiencia, esa arquitectura es predecible y extensible.

Para un modelo de lenguaje, esa misma arquitectura es un impuesto.

Para que una IA entienda cómo se modela, digamos, una entidad de datos en Drupal, tiene que reconstruir un rompecabezas: esquemas dispersos, definiciones de entidades base, config exportada en YAML, clases de plugin repartidas en varios módulos. El contexto que necesita es enorme y el resultado es frágil.

Comparémoslo con un framework estándar. En Symfony, un modelo de datos vive en una clase con atributos claros:

#[ORM\Entity]
class Invoice
{
    #[ORM\Id, ORM\GeneratedValue, ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 180)]
    private string $number;

    #[ORM\ManyToOne(targetEntity: Client::class)]
    private Client $client;
}

Todo lo que hay que saber está en una pantalla. En Drupal, ese mismo concepto se despliega en varios YAML, una anotación o atributo de entidad, y probablemente un módulo custom que altera algo a mitad de camino. Una IA comprende, procesa y genera código para Symfony en una fracción del tiempo y del contexto que necesita para hacer lo mismo con la maquinaria interna de Drupal.

No es que Drupal esté mal diseñado. Es que fue optimizado para un cuello de botella —la coordinación entre personas— que la IA está dejando de ser.

Una tarde de Symfony contra meses de equipo

Para no quedarme en la teoría, hice la prueba. Repliqué la arquitectura central de un proyecto B2B que en su momento había llevado meses de desarrollo a un equipo entero de Drupal. La versión con Symfony, asistida por IA, salió en una sola tarde.

No pretendo que ese experimento sea ciencia. Una arquitectura central no es un producto terminado, y la IA no reemplaza la parte difícil: entender el negocio, decidir qué se construye y validar que el resultado aguante producción. Pero el orden de magnitud del cambio ya es difícil de ignorar.

La consecuencia incómoda es para las consultoras. Cobrar tarifas altas por hora para configurar Drupal se vuelve complicado de justificar cuando al lado hay alternativas personalizadas, desarrolladas rápido por un solo dev con IA sobre un framework estándar. Cuando la propuesta de valor de un negocio consiste en la fricción de una herramienta, la herramienta deja de ser solo un problema técnico y pasa a ser un problema de modelo de negocio.

Drupal no muere: se convierte en COBOL

Conviene separar “morir” de “dejar de importar”, porque no son lo mismo. COBOL no desapareció. TYPO3 tampoco. Y Drupal no va a apagarse de un día para otro: hay demasiadas horas-hombre invertidas en él.

Donde va a seguir vivo durante muchos años:

• Administraciones públicas y entidades gubernamentales, donde los ciclos de licitación y la inercia administrativa son más fuertes que cualquier novedad tecnológica.
• Universidades e instituciones académicas, con sitios enormes, multiidioma y presupuestos que se renuevan por contrato.
• Grandes corporaciones con sistemas ya implementados cuyo coste de migración es sencillamente más alto que el de sostenerlos.

En ese escenario, el rol de Drupal queda bastante claro: el COBOL de la web. Tecnología de nicho, centrada en dar soporte a sistemas legados, con tarifas potencialmente muy bien remuneradas para quienes se queden —poca oferta de gente, mantenimiento crítico— pero con nulo dinamismo para productos nuevos. Se gana bien. Ya nadie elige empezar ahí.

Mi decisión: girar hacia Power Platform

Después de más de década y media viviendo de Drupal, decidí reorientar mi carrera hacia el entorno empresarial de Microsoft Power Platform. No es un cambio por moda: es el reconocimiento de que el mercado donde aportaba valor está en contracción, y de que prefiero ser un generalista útil en una plataforma viva que un especialista raro en una plataforma en mantenimiento.

Lo que me llevo de estos 16 años no es el conocimiento de hook_entity_presave(). Es haber entendido por qué se diseñan las cosas como se diseñan, y saber cuándo una arquitectura que resolvía un problema de ayer se convierte en el problema de mañana. Eso no caduca con el framework.

Si estás en una situación parecida —tecnología en declive, ofertas que se secan, IA apretando el precio de tu trabajo—, mi consejo es que no esperes al último despido para hacerte la pregunta. La pregunta es gratis. La respuesta tardía, no.