Cuando el liderazgo pasa por encima de la comunidad: la crisis de gobernanza de WordPress 7.0 y el futuro del open source
Cuando el Líder se Impone a la Comunidad: La Crisis de Gobierno en WordPress 7.0 y su Impacto en el Open Source
Los proyectos open source crecen gracias a la transparencia, el acuerdo colectivo y la confianza de la comunidad. Por eso, cuando el fundador del CMS más usado del mundo tacha al proyecto de "mediocre basura" y revierte decisiones de los committers principales, hay que prestar atención. No se trata de chismes. Es una señal clara sobre la sostenibilidad y el gobierno en ecosistemas open source grandes.
El Caso Akismet: Más que un Pelea por un Plugin
En abril de 2026, Matt Mullenweg reapareció en las discusiones de desarrollo. Se topó con un debate viejo sobre la nueva pantalla "Connectors" en WordPress 7.0. La duda: ¿debería Akismet salir como opción por defecto?
A simple vista, parece un detalle menor. En realidad, es un caso clásico de fallo en la gobernanza.
Esto es lo que pasó:
- Un colaborador patrocinado por Automattic metió Akismet en la pantalla durante la fase de release candidate.
- Committers de otras empresas, como John Blackbourn de Human Made, alertaron que se saltaron los procesos de revisión estándar.
- Todo ocurrió con poca discusión pública, algo raro en decisiones clave del producto.
- Mullenweg al principio rechazó meter Akismet a la fuerza en core.
- Tras leer el chat de Slack, cambió de idea y ordenó que lo incluyeran igual.
- Le recordaron su postura anterior y respondió: "Sí lo dije, pero cambié de opinión y lo hacemos".
El lío no fue un debate técnico que Mullenweg ganó por lógica. Fue una decisión que ignoró el proceso que el modelo de gobernanza de WordPress debe respetar.
Por Qué Importa el Proceso (Aunque Tengan Razón)
No hace falta seguir la política de WordPress para ver el problema. No se trata de si Akismet entra o no. Es cómo se decidió.
Los proyectos open source viven de la confianza. La gente da su tiempo gratis porque cree que su voz cuenta y que hay reglas fijas. Si un fundador pasa por encima—even con buenas intenciones—envía un mensaje claro:
Tu opinión solo vale si el líder está de acuerdo.
Esto genera un problema serio: empuja a los colaboradores a hacer lobby en vez de buscar consenso técnico. Las decisiones parecen caprichosas. Y siembra rencor entre quienes mantienen el código sin gloria.
En WordPress, complica más porque Automattic (la empresa de Mullenweg) financia desarrollo y vende productos comerciales que se integran con WordPress. Si las decisiones de core benefician a Automattic, se confunde lo open source con intereses corporativos.
El Panorama General: ¿Pierde WordPress el Norte?
Mullenweg no se quedó en Akismet. Criticó que WordPress se alejó de lo que lo hizo grande:
- Se hinchó con features "mediocres" en vez de apostar por la excelencia.
- El modelo de gobernanza no atrae contribuciones de calidad.
- Empresas que prometen apoyo vía Five for the Future no aportan de verdad.
Son críticas válidas por separado. Muchos desarrolladores veteranos se quejan de lo mismo: bloat y baja calidad. Pero duele ver al fundador de un proyecto de 20 años atacando públicamente lo que su propio sistema creó.
Eso no pinta una comunidad sana.
Qué Significa para los Desarrolladores
Si usas WordPress para construir, esto te afecta directo:
Riesgo de dependencias: Un gobierno basado en personalidades es impredecible. Mañana priorizan otra cosa sin explicación.
Fragmentación comunitaria: Ojo a los committers clave que se vayan a forks o plataformas rivales. Los conflictos gordos suelen acabar en éxodo de talento.
Bloat de features: Si meten más cosas en core por presión (como sugiere lo de Akismet), espera más complejidad y riesgos de seguridad.
Viabilidad a largo plazo: Los proyectos open source resisten cambios de liderazgo si la gobernanza es sólida. El modelo de WordPress—donde uno solo puede anular committers—es frágil.
Lecciones para Cualquier Proyecto Open Source
Este episodio enseña a quien lidere software open source:
Documenta tu modelo de gobernanza y cúmplelo. Si los committers core tienen poder, que sea real. Sino, es puro teatro.
Liderazgo no es dictadura. Los fundadores influyen, pero no deben saltarse safeguards contra fallos únicos.
Haz visibles los incentivos empresariales. Si integras productos de Automattic en core, dilo claro. Deja que la comunidad debata, no lo descubran en Slack.
Confía en tus committers o cámbialos. Si Mullenweg no cree en su juicio, reestructura el equipo. No los ignores en decisiones grandes.
El Siguiente Paso de la Comunidad WordPress
WordPress mueve el 43% de los sitios web. Un logro brutal. Pero a esa escala, la gobernanza pesa más que nunca.
El proyecto tiene dos caminos: volver al proceso que da poder distribuido y propiedad comunitaria, o admitir que es un proyecto guiado por Mullenweg con committers como asesores.
Fingir lo primero mientras actúa como lo segundo es lo peor: colaboradores sin poder, usuarios sin rumbo predecible.
Para devs que eligen plataformas, ojo: mira más allá de features. Pregunta por la gobernanza. Cómo se toman decisiones. Si una persona sola anula a los committers. La mejor stack técnica se vuelve riesgo si no evoluciona con confianza.
¿Cuál es Tu Experiencia?
¿Has tocado core de WordPress? ¿Te has topado con roces en su gobernanza? ¿O replanteas tu plataforma por cómo se manejan?
En NameOcean, creemos que la infraestructura transparente—from domain management to DNS configuration to hosting architecture—debe llegar al software que usas. Sea WordPress o alternativas, te respaldamos con el stack que le funcione a tu equipo.
Cuéntanos en comentarios. Si pruebas plataformas nuevas o piensas en modelos de gobernanza open source propios, dinos qué te importa más.