WordPress es todo oídos

Esto es algo rarísimo: dos posts en el blog de desarrollo de WordPress durante una misma semana.

Hoy se anuncia la creación de dos nuevas secciones en el sitio oficial de WordPress, ambas están destinadas a escuchar a sus usuarios en una forma en que nunca antes lo habían hecho. Antes, para reportar un problema o solicitar alguna nueva característica, debías crear un nuevo ticket en el sitio de desarrollo de WordPress, un proceso no muy amigable para un usuario común; a partir de ahora, y gracias a Kvetch, cualquier usuario tiene un espacio para quejarse de cualquier cosa con la que puedas estar en desacuerdo en el mundo de WordPress, mientras que en Ideas podrás compartir tus más salvajes deseos sobre WordPress con el mundo, y también votar por las ideas de otras personas.

Solamente porque lo que hemos hecho ha funcionado en el pasado no significa que sea lo mejor para el futuro. Tenemos que tomar una “auto-mirada” crítica a las suposiciones que tenemos sobre nuestro proceso de desarrollo y sobre el mismo WP. El próximo lanzamiento, que ha tenido un larga espera, es el momento perfecto para enfocarnos en el ingrediente secreto de WP… Tú [Ustedes].

Si pudieras agregar cualquier cosa al mundo de WordPress, ¿qué sería? Si pudieras nombrar la cosa que más te frustra de WP, ¿qué sería?

¿Oportunidad o amenaza?

Cuidado. Creo que este anuncio puede transformarse en un arma de doble filo: si bien la idea de conectarse más con la base de usuarios me parece admirable, expresar que las ideas mejor evaluadas serán incluidas en una próxima versión podría llegar a atentar contra el proceso de desarrollo:

  1. En primer lugar, creando expectativas poco realistas sobre las nuevas características que se podrían incluir, lo que genera presión sobre un equipo formado al menos en parte por personas que no están dedicadas exclusivamente al desarrollo WordPress (algunos de los cuales incluso ya han reaccionado a propósito de la carga que supondría el ciclo de desarrollo propuesto por Mullenweg)
  2. En segundo lugar desviando la atención desde el desarrollo de un núcleo sólido y estable lo que podría aumentar la posibilidad de encontrarnos con bugs a poco tiempo del lanzamiento de nuevas versiones (como ocurrió con 2.0.6 y el “pequeño problema” con FeedBurner), errores de seguridad, etc.

Viendo las “ideas” propuestas es posible darnos cuenta de que la mayoría de los requerimientos están enfocados a integrar funciones que actualmente no son parte del núcleo sino que vienen agregadas mediante plugins: tags, instalación de un click para plugins y themes, “retos” para identificar comentarios humanos… o podrían ser manejadas por plugins o widgets (por ejemplo, un sistema de gestión de enlaces a páginas tipo menú que fácilmente podría ser parte de un widget de texto).

Creo que el equipo de WordPress deberá optar entre un sistema repleto de características (lo que me recuerda aquella pesadilla bloatware que es PHP-Nuke) o un desarrollo orientado a ofrecer una solución estable, segura, sólida.

Ochenta por ciento de los usuarios ocupa un veinte por ciento de las características de un software, ¿no? WordPress tiene una sólida arquitectura para plugins y una activa comunidad de personas que continuamente están creando agregados para los más diversos gustos. No se trata de sobrevalorar la simplicidad, sino de enfocarse en las “características críticas” y hacer de la robustez del software una característica importante, a la vez que manteniendo la opción de agregar cuanto haga falta a cada usuario en particular.

Mi opción está clara: prefiero un software sólido, y que los plugins hagan el resto.