A principios de enero, alguien en neosmart publicaba un artículo llamado Cómo WordPress malcría a los desarrolladores, en el que planteaban una posición que probablemente muchas personas ya habían pensado pero que quizás nunca se había expresado con tanta vehemencia. Traduzco un párrafo del artículo:

El impacto más obvio que WordPress ha tenido —sobre todos— es que realmente no hay mucho espacio para otra plataforma para bloguear. No importa qué tan bueno sea el producto competidor que alguien cree, es casi imposible para cualquier cosa superar a WordPress como la herramienta elegida para el trabajo —sin importar cuál sea éste. WordPress no es perfecto, y somos los primeros en admitirlo. Ciertamente no es la plataforma para blogs más liviana ni el CMS definitivo, pero definitivamente esto no le ha impedido conquistar el mercado.

Contundente, pero con una contradicción evidente: afirma que no existen alternativas reales a WordPress, a la vez que reconoce que si éste está en el primer lugar de las preferencias no es necesariamente porque sea la mejor opción.

Durante Enero tuvimos varias noticias sobre WordPress que, en mi opinión, han venido alterando un poco este panorama, y que quizás podrían llegar a hacer tambalear la seguridad del predominio. Vamos por partes…

El pasado reciente de WordPress

Enero del 2007 probablemente ha sido el mes con más movimiento en el blog de desarrollo de WordPress, con cuatro importantes posts:

1. WordPress 2.0.6 fue anunciado el día 5, un release orientado principalmente a arreglar fallas de seguridad, pero que sin embargo produjo nuevos problemas como el llamado “FeedBurner bug” que impedía a este servicio acceder correctamente a la información de tu feed.
2. El 9 se publicó Ideas and Kvetch!, una iniciativa para enfocarse en el ingrediente secreto de WordPress… tú, creando espacios para enviar quejas e ideas al equipo de desarrollo de WordPress… [¿alguien dijo bloatware?->WordPress es todo oídos]
3. Justo a mitad de mes se lanzó WordPress 2.0.7… ¿por qué una nueva versión menor tan pronto? En buena medida, para arreglar los errores con los que la anterior había sido publicada.
4. Finalmente, el 22 se hizo pública WordPress 2.1 Ella, la increíblemente atrasada y esperada nueva versión mayor de WordPress, sobre la que —como era de esperar— [un montón de gente expuso su opinión->Y tenemos WordPress 2.1]: algunos la alabaron y otros (creo que muchos más que nunca antes) se quejaron, ya que a pesar de la considerable demora no hay muchas novedades visibles para los usuarios como para justificar la actualización, la que por otra parte no dejó de presentar sus dificultades en algunos casos

A esto, agregaría el anuncio de [un ciclo de desarrollo para WordPress->] que significaría plazos de actualización regulares y estructurados.

Esto bien podría ser solamente una impresión personal, pero creo que como nunca antes los usuarios de WordPress se han manifestado como “menos que contentos” con el rumbo que se está delineando. No son solamente los errores en los lanzamientos que supuestamente deberían arreglarlos, o que tras una espera demasiado prolongada la nueva versión no haya respondido a las expectativas, o que su “conexión” con la comunidad pueda resultar en un software lleno opciones poco útiles… es cada una de estas cosas y todas juntas a a vez, es en definitiva un clima algo enrarecido que huele un poco a descontento, y quizás (sólo quizás) también un poco a cambio.

… Y entonces, el 20 de enero surgió un competidor a WordPress

¿Habari?

Habari es el nuevo proyecto para crear un sistema de gestión de contenidos de código abierto que ha producido mucha bulla en la blogósfera (sobre todo la anglófona), por la simple razón de que algunos connotados desarrolladores de WordPress son quienes están detrás de él… habría que decir ex desarrolladores de WordPress ya que han pasado a trabajar exclusivamente en Habari. Seguramente conocen a algunos de ellos:

• Chris J. Davis, co-desarrollador de K2, uno de los themes de WordPress más populares.
• Michael Heilleman, creador de Kubrick (el tema predeterminado de WordPress) y co-desarrollador de K2.
• Khaled Abou Alfa, diseñador de aquella soñada remodelación de la administración de WordPress llamada Shuttle.
• A estos habría que sumar el que alguna vez fuera el octavo miembro de Automattic, Bryan Veloso, quien estaría encargado de diseñar el sitio web del proyecto.

Al ver esta lista de eminentes personajes notablemente ligados al desarrollo de WordPress ponerse al servicio de un nuevo proyecto que se presenta frontalmente como un competidor, creo que es inevitable preguntarse qué razones podrían existir para este alejamiento.

Las hay. Algunas han sido brutalmente exageradas por algunas de las personas que han seguido esta teleserie y escrito sobre ella, pero no creo equivocarme al afirmar que podríamos resumirlas en una: diferencias “filosóficas” con el rumbo del desarrollo de WordPress.

Bryan Veloso vs. Matt Mullenweg

Ok, este es un encabezado sensacionalista, debo decirlo. No existe nada así como una confrontación directa o guerra declarada entre ambos. Para ser claros, es necesario indicar que Bryan Veloso ni siquiera es uno de los “padres” de Habari, pero su historia parece ser bastante representativa de lo que ha pasado, además de ser uno de los que más se ha dedicado a escribir sobre el asunto. Jamás se ha referido en malos términos a Matt ni a la gente con que trabajó en Automattic, aunque ciertamente ha sido el más abierto a mostrar el lado personal de esta historia.

A mediados del 2006 (fines de julio), Bryan Veloso fue integrado al equipo de Automattic para trabajar en el equipo de diseño y desarrollo de WordPress, bbPress y sus otros productos. El trabajo de Bryan pudo verse en la nueva barra de administración de WordPress.com, pero poco más se supo del trabajo que habría desarrollado.

Bryan es un excelente diseñador, por lo que pensar que su trabajo se abocaría al necesario rediseño de la administración de WordPress era una apuesta que podía suponerse segura, ya fuera implementando Shuttle o su propia versión, Atlantis.

Sin embargo, pasó el tiempo y las noticias al respecto escaseaban. Un par de posts en los que pedía sugerencias fueron todo lo que pudimos ver, hasta un post publicado el 7 de diciembre, Pressing for Change, en el que anunciaba que dejaba Automattic.

Sí, algo ha muerto hoy. Si es que esa muerte me afecta, o más bien, la magnitud con que esa muerte me afecta aun está sujeto a interpretación. De todas maneras, a partir de hoy, Automattic y yo recorreremos caminos distintos. Al pensar sobre eso ahora, veo que la razón ha sido una más fundamental. La forma en que trabajo simplemente no encajó a sus expectativas. Podría hablar de cómo difieren las expectativas de diseñadores y programadores, o cómo es que usar Trac para medir la producción puede no ser la mejor forma de medir mi progreso. Honestamente, eso no haría nada por la situación. Fueron unos cuatro meses espectaculares trabajando con algunas de las mentes más inteligentes en el medio. Sé que llegarán lejos.

Veloso, fuera. Matt Thomas —quien ha hecho todo el trabajo de identidad para WordPress— adentro. Shuttle entraba en pausa, a pesar de que una de las últimas solicitudes de Veloso fue completar su trabajo en el proyecto.

Pasaría poco tiempo para agregar un nuevo capítulo (¿final?) a esta historia: el 19 de enero de este año, Bryan publicó esta serie de imágenes en un post titulado Atlantis: lo que podría haber sido.

Junto a ellas, sus últimas declaraciones al respecto.

No considero a éste mi mejor trabajo, creo que por eso es que Matt [Mullenweg] me envió éste cierto libro [“Diseñando lo obvio: un acercamiento desde el sentido común al diseño de aplicaciones web”] cerca de la hora de mi partida. Pero en mi defensa, no tuve muchas oportunidades de trabajar en él. O más bien, para refinarlo. […]

Algunas personas son muy apegadas a sus ideas, tanto como para impedir que cualquier otra persona se meta con ellas. Para ser honesto, me puedo identificar con eso, y toda esta experiencia abrió mis ojos a un montón de cosas.

Y hasta ahí llegó el idilio de Bryan con WordPress, el que alguna vez llamara el único software para bloguear que usaría jamás, pero que ahora tendría planeado reemplazar por Django (que en realidad es un framework para Python).

Bueno, ¿y? ¿Qué pasó con Habari?

Pasa que, al parecer, la gente tras Habari también se ha visto un poco frustrada en sus aportes a WordPress. Jim Whimpey ha caricaturizado algunas de estas quejas: Matt es un dictador malvado que maneja una compañía llega de sus igualmente malvados lacayos que trabajan juntos en una horrible monstruosidad llamada WordPress. Claro, esto es una exageración, pero ¿notaron las frases que destaqué en la última cita de Veloso? Los desarrolladores de Habari han aclarado que su partida no tiene que ver con resentimiento, sino a lo más con “diferencias” y el deseo de crear algo nuevo y sorprendente.

Para Michael Heilleman, se trata de llevar a cabo el diseño de la interfaz que fue postergada junto al proyecto Shuttle, pero junto a esto se muestra preocupado por el que para él es un movimiento innegable de WordPress hacia “aguas comerciales” (lo que sea que eso signifique), el que afirma no condenar pero que sin embargo le hacen añorar tiempos pasados.

Chris Davis, por su parte, confiesa haberse sentido algo irritado con la forma en que se maneja WordPress; invoca su experiencia en las conferencias de la [Fundación Apache->@wiki] como un punto de contraste en la forma de hacer las cosas, afirmando sentirse más cómodo con la forma en que funciona Apache.

Rich es quien, definitivamente, dibuja más claramente el panorama:

Sí, habían frustraciones de las que nos queríamos alejar. Y habían diferencias filosóficas sobre cómo debería ser gestionada una comunidad de Código Abierto. Pero no hay mala voluntad hacia WordPress, aun cuando hay diferencias de opinión sobre la Manera Correcta de hacer las cosas. En el Código Abierto, cuando las cosas se hacen bien, no es dañino tener dos proyectos saludables en el mismo espacio. Cuando las licencias son sensibles los proyectos pueden aprender el uno del otro, mejorar las ideas de cada uno, y tener una competencia sana, así como también esforzarse por ser compatibles. No veo un lado malo, si es que podemos seguir existiendo en una amistosa rivalidad.

En WordPress, los cambios más importantes al código deben ser revisados y aprobados por Matt, así como también las ideas para implementar nuevas características. Habari pretende tener un modelo más abierto de desarrollo, sin dejar de estar organizado aunque quizás sí menos centralizado. Proponen un sistema de [meritocracia->@wiki] para obtener acceso a modificar el código de la aplicación, ésta es la inspiración fundamental que han extraído de Apache (aunque aun no se ha plasmado en un modelo estructurado).

¿Y qué va a pasar con WordPress?

Probablemente no mucho muy distinto… o sea, las líneas de su desarrollo han sido en buena medida trazadas con lo que ha pasado durante enero, y creo que ahora podemos fijarnos nuevas expectativas de lo que podríamos esperar a futuro.

¿Rediseño de la administración? Difícil. ¿Muchas características nuevas? Quizás, y probablemente varias de ellas suplanten la función que hoy tienen distintos plugins. Está la posibilidad de que se convierta en un [bloatware->@wiki.en], y no me gusta… y no soy el único al que no le gusta.

La movida “hacia aguas comerciales” es bastante indefinida. Creo que, en primer lugar, podríamos esperar más énfasis en WordPress.com que en “.org”, Akismet y el soporte pagado para instalaciones comerciales de WordPress que se anunció hace tiempo en Automattic. Está bien, después de todo, esto se ha transformado en un gran negocio, sería estúpido no tratar de obtener beneficios de él o desperdiciar estas oportunidades. No creo que Automattic comience a publicar software que no sea de código cerrado, o que WordPress (.org) se vuelva de pago.

Y sobre Habari… habrá que ver. Actualmente, hay una versión que funciona que puede ser descargada, pero está a años luz de siquiera igualar a WordPress. En serio, la acabo de probar, y está bien, pero muy incompleto; de hecho, hay mucho más trabajo por hacer que el que ya está hecho. Por otra parte, el requerimiento de PHP 5 reduce la cantidad de personas que podrían ejecutarlo, ya que todavía hay muchos hosts que utilizan PHP 4. Finalmente, no es la primera vez que sus desarrolladores se han unido para crear algo que ha recibido mucha publicidad: hace tiempo, se anunció con bombos y platillos la creación de InkSmith, pero hasta el día de hoy página de inicio reza “coming soon”.

Al día de hoy, la mayor fortaleza de WordPress es su comunidad. ¿Logrará Habari un nivel de participación no solo de programadores sino también de usuarios suficiente para convertirse en una verdadera competencia?

Fuentes

• wordpress™ wank
• Habari Wank!
• Habari
• How WordPress Spoils Developers
• Atlantis: What May Have Been. Powered By Avalonstar.
• Pressing for Change. Powered By Avalonstar.
• Habari, primeras imagenes del posible asesino de WordPress | aNieto2K
• Time to Habari at Binary Bonsai
• Chris Davis: Why Move.
• DrBacchus’ Journal