Agnósticos con un favorito: cómo elegimos la plataforma de una web

Nos gusta presentarnos como agnósticos en tecnología. Con nuestros números, esa afirmación necesita una explicación. Llevamos más de quince años construyendo webs (el proyecto más antiguo que conservamos en el archivo es de finales de 2010) y en ese tiempo hemos trabajado con más de 350 organizaciones: hospitales y centros de investigación como Sant Joan de Déu o Vall d’Hebron, farmacéuticas como Bioibérica o Ferrer, universidades y escuelas como la UB, la UPC, la URL, la UdG, ESADE o los Jesuïtes, infraestructuras como el Port de Barcelona, industria como Ercros o Grupo Ehlis, e instituciones como el CERN, la CEOE o la Diputació de Barcelona. En nueve de cada diez casos, la plataforma fue Drupal.

Un agnóstico con esa distribución es, o alguien que se engaña, o alguien con una muestra sesgada. Aceptamos lo segundo y vamos a explicar el mecanismo, porque el mecanismo es lo útil. La preferencia, sola, no le sirve a nadie.

El favorito que perdió nuestro propio proyecto

Empecemos por la excepción más visible. Cuando tocó decidir sobre qué construir esta web, Drupal perdió. Aquí edita una persona, no hay flujos de aprobación, el contenido no tiene obligaciones legales especiales, y queríamos un laboratorio donde probar arquitectura desacoplada y una integración fuerte de IA tanto en el desarrollo como en la gestión de contenidos. Con ese perfil, montar Drupal habría sido el mismo sobredimensionamiento que le reprochamos a quien implanta un ERP para llevar tres facturas.

Esto no es una anécdota simpática: es la regla aplicada en casa antes de venderla fuera. Y es también la razón por la que el “nueve de cada diez” no nos convierte en fanáticos. La décima vez existe, y cuando aparece, la tomamos.

Elegir plataforma son dos decisiones disfrazadas de una

La primera decide en qué familia de herramientas juegas. La segunda decide qué herramienta, dentro de esa familia, aguanta tu caso sin romperse ni sobrar.

Primera decisión: qué estás dispuesto a alquilar

Una plataforma propietaria, sea una suite tipo Adobe Experience Manager o Sitecore o un SaaS tipo Contentful o HubSpot, te alquila las cuatro cosas a la vez: código, datos en su formato, arquitectura y proveedor. Puede ser una decisión perfectamente razonable si tienes el presupuesto y aceptas que la hoja de ruta la marque otro. El open source te entrega la propiedad, con un precio que conviene decir en voz alta: el gasto no desaparece, se traslada de la licencia al desarrollo y al talento. Lo que compras con la diferencia es portabilidad, ausencia de renta perpetua y la certeza de que nadie te puede retirar el producto.

Aquí conviene deshacer un malentendido habitual. La línea no pasa entre “open source” y “comercial” en el sentido de gratis frente a de pago. Typo3 es GPL de arriba abajo y tiene una fundación detrás; Liferay tiene una edición comunitaria libre y una edición comercial encima. La pregunta útil es otra: quién controla la licencia y qué puede pasar si cambia de idea.

Directus, el CMS de esta web, es un buen ejemplo de por qué esa pregunta importa. Nació con licencia MIT, en 2023 pasó a Business Source License 1.1 (uso libre por debajo de cinco millones de dólares de ingresos y prohibición de uso competitivo, una licencia que la Open Source Initiative no reconoce como open source) y en 2026 ha abierto consulta pública sobre una nueva revisión. Lo sabíamos al elegirlo y lo aceptamos: si Directus cambia las reglas, nosotros perdemos un fin de semana de migración. Si eso mismo le ocurre a una universidad con doscientos sitios y quince años de contenido, es una crisis institucional. Una misma decisión puede ser sensata en un caso y temeraria en el otro. Eso, exactamente, es lo que significa tener criterio en vez de tener favoritos.

Una misma decisión puede ser sensata en un caso y temeraria en el otro. Eso, exactamente, es lo que significa tener criterio en vez de tener favoritos.

Segunda decisión: cuánta complejidad hay que gobernar

Con la familia decidida, las preguntas se vuelven concretas. ¿Cuántas personas editan y con qué permisos? ¿Cuántos sitios comparten marca, componentes y usuarios? ¿Cuántos idiomas, y quién es responsable de cada traducción? ¿Qué contenido necesita aprobación antes de publicarse y quién la da? ¿Qué obligaciones legales aplican: accesibilidad exigible desde junio de 2025 por la EAA con el estándar WCAG 2.1 AA, protección de datos, trazabilidad de cambios? ¿Con qué se integra: CRM, DAM, SSO, ERP, comercio? ¿Cuánto tiempo va a vivir? ¿Quién lo va a mantener dentro de cinco años, y sabrá hacerlo?

Cuando la mayoría de esas respuestas son “uno”, “ninguno” o “no lo sé todavía”, la lista de plataformas razonables es larga y Drupal casi nunca es la mejor. Hemos construido proyectos en WordPress y en otras plataformas más ligeras con resultados de los que no nos avergonzamos, y seguiremos recomendándolas cuando el perfil sea ese: un equipo editorial pequeño, un modelo de contenido simple, poca gobernanza.

Cuando las respuestas empiezan a acumularse, la lista se acorta deprisa. Y ahí es donde aparece Drupal, no porque sea mejor en abstracto, sino porque lo que otras plataformas resuelven con plugins de terceros (contenido estructurado con tipos y campos propios, permisos hasta el nivel de campo, revisiones y flujos de aprobación, multisite, multiidioma) en Drupal forma parte del núcleo, mantenido por el mismo equipo de seguridad que publica los avisos del proyecto. Menos piezas de terceros significa menos superficie que auditar y menos dependencias que se rompen en cada actualización.

Los datos de mercado cuentan la misma historia si se miran bien. Según W3Techs, Drupal está en torno al 0,7% de todos los sitios web del mundo. Según HTTP Archive, entre el 6% y el 7% de los diez mil sitios de mayor tráfico. Diez veces más presencia donde la web se complica que donde la web es una web.

Qué es Drupal cuando deja de ser un CMS

Esa misma arquitectura es la razón por la que Drupal aparece en proyectos que no encajan en la etiqueta de “gestor de contenidos”. Sobre el mismo núcleo se construyen tiendas (Drupal Commerce), plataformas de formación (Opigno) y comunidades (Open Social), y en los tres casos el modelo de contenido, los permisos y los flujos son los mismos que gobiernan la web pública. Un hospital puede tener web, intranet y portal de pacientes con un solo modelo de usuarios; una universidad, cien sitios de facultades con marca común y autonomía editorial.

Y se puede servir acoplado, con Drupal renderizando las páginas, o desacoplado, con Drupal como fuente de contenido para un frontend en el framework que el equipo prefiera. Las dos opciones conviven en el mismo proyecto, y la decisión se toma por equipo y por caso de uso, no por moda.

Cuándo recomendamos otra cosa

Además de nuestra propia web, hay tres situaciones en las que Drupal sale de la conversación. La primera, ya dicha: proyecto editorial sencillo, un editor, vida corta. La segunda: el cliente tiene un requisito de plataforma que no vamos a discutir, porque forma parte de su estrategia de sistemas y no de nuestra opinión. La tercera es la más instructiva: sitios desarrollados a medida por terceros en los que hemos tenido que intervenir. Ahí aprendimos el argumento inverso a la propiedad. Poseer el código no sirve de nada si la única persona que lo entendía ya no trabaja allí. Un desarrollo propio es propiedad sin comunidad, y la comunidad (decenas de miles de contribuidores, documentación, avisos de seguridad, talento contratable) es lo que hace que la propiedad sea mantenible.

Los próximos editores de tu web no serán personas

Hay un motivo más para tomarse en serio la segunda decisión, y apunta al futuro inmediato. Los siguientes en editar contenido en tu web no van a ser solo personas: van a ser agentes de IA que generan, actualizan y publican. Nuestro propio laboratorio ya habla con ellos: Directus incorporó soporte nativo de Model Context Protocol a finales de 2025, y Drupal también lo soporta. La cuestión que se abre es qué sistema decide lo que un agente puede tocar, con qué identidad y quién lo revisa. Adelantamos la respuesta: la arquitectura que gobierna bien a las personas es la que va a gobernar a los agentes. Lo desarrollaremos en las próximas piezas de esta serie.

Antes de la próxima reunión con un proveedor

Este es el cuestionario que aplicamos antes de recomendar una plataforma. Úsalo con cualquier proveedor, nosotros incluidos.

1. Si mañana el dueño de la licencia cambia las condiciones, ¿qué pierdo y en cuánto tiempo?
2. ¿Puedo exportar todo el contenido en un formato que otro sistema entienda?
3. ¿Cuántas personas van a editar, con qué permisos, y quién aprueba qué?
4. ¿Cuántos sitios e idiomas comparten esta plataforma en tres años?
5. ¿Qué obligaciones legales aplican (accesibilidad, datos, trazabilidad) y quién responde?
6. ¿Con qué sistemas se integra hoy, y cuáles vendrán?
7. ¿Qué parte de lo que necesito está en el núcleo y qué parte depende de terceros?
8. ¿Quién mantendrá esto dentro de cinco años, y cuánto talento hay disponible para hacerlo?
9. ¿Qué va a poder hacer un agente de IA en esta plataforma, y quién decide sus límites?
10. ¿La plataforma que me proponen resuelve mi problema, o resuelve el del proveedor?

Si al terminar la respuesta sigue siendo Drupal, sabrás por qué. Y si no lo es, nosotros también.

Fuentes

• W3Techs, Cuota de mercado de sistemas de gestión de contenidos, 2026 — Drupal en torno al 0,7% del total de sitios web.
• HTTP Archive, Presencia de Drupal en el top 10.000 de sitios por tráfico — entre el 6% y el 7%.
• Directus, Why We’re Relicensing Directus (abril 2023) y Changing Our License: One Year Later (2024) — cambio a BSL 1.1 y reconocimiento de que la BSL no es una licencia aprobada por la OSI.
• Directiva (UE) 2019/882 (EAA), aplicable desde el 28 de junio de 2025 — estándar armonizado EN 301 549 v3.2.1 (WCAG 2.1 AA).