El quejarse de la calidad de los plugins, creo que acaba degenerando en la pescadilla que se muerde la cola, es como la clásica discusión de si el problema es de Windows o de muchos drivers que son malos con ganas.

:D

Creo que algo interesante sería invitar a los desarrolladores de los plugins más usados (y mejor construidos) a colaborar en la inclusión fija (y posterior actualización) en el paquete de WordPress.

Interesante idea… habría que ver si esa inclusión es como plugins o como parte integral. Se me ocurre también que podría ser interesante posibilitar la creación de “meta-paquetes” (a la Ubuntu/Debian) de plugins (p.ej, un paquete SEO o para la inclusión y gestión de archivos multimedia)

Yo entiendo que se intente que WordPress sea lo más estable posible, pero tampoco hay que perder de vista que un software es un ente vivo, si no lo actualizas y mejoras constantemente, sus días están contados. Siguiendo ese razonamiento, tarde o temprano WordPress debe dar un par de pasos en busqueda de una modernización que valla más allá de usar 4 pijadas (mi opinión) en AJAX.

Si se duermen en los laureles, aparecerá (o reaparecerá, la sombra de MT no desaparece…), otro gestor de contenidos que sea más sencillo de instalar, traiga muchas más funciones y sea igual o más estable, con el peligro de una migración masiva.

Conozco Drupal, es un mastodonte si, pero por ejemplo su concepto de módulos (y trae muchos), que además puedes personalizar y colocar donde tu quieres sin tener la más minima idea de CSS o HTML o PHP, me parece genial. WordPress tendrá muchos themes, pero si quieres cambiar aunque sea solo un poco uno, o sabes CSS, o estás muerto.

El quejarse de la calidad de los plugins, creo que acaba degenerando en la pescadilla que se muerde la cola, es como la clásica discusión de si el problema es de Windows o de muchos drivers que son malos con ganas.

Creo que algo interesante sería invitar a los desarrolladores de los plugins más usados (y mejor construidos) a colaborar en la inclusión fija (y posterior actualización) en el paquete de WordPress.

Un saludo.

Cuando recordaba la “regla de 80/20″ tenía en mente la diferencia que mencionas: el 20% de cada usuario es distinto, y precisamente es por ello que es importante mantener una arquitectura abierta a plugins.

Sobre el otro punto que mencionas, concuerdo en que “software sólido + plugins no-sólidos = inestabilidad”, pero en ese caso ya es problema de los desarrolladores de plugins, no de WordPress. Me parece mejor idea crear estándares de calidad o un sistema de certificación de plugins.

Mira el caso de Drupal: un núcleo compacto y la posibilidad de añadir funcionalidades a través de módulos.

El problema de la calidad de los plugins, reitero, es problema de cada plugin. Si no funciona o tiene problemas, lo desactivas. Si la base falla, TODAS las instalaciones son vulnerables, y pierdes seguridad en el paquete completo, comprometiendo todas sus funcionalidades (claro, estoy exagerando para hacer un punto).

Todos los plugins tienen distintas fechas de lanzamiento/actualización: eso se podría solucionar utilizando la especificación propuesta por Matt Read, hacerla parte de la API.

¿Incompatibilidades de plugins con nuevas versiones? Las puedes evitar si te apegas a la API tanto como sea posible

“…prefiero un software sólido, y que los plugins hagan el resto.”
Tampoco estoy de acuerdo, un software sólido con plugins que no son sólidos, convierte a tu software en inestable. Eso sin mencionar las ya de sobra conocidas incompatibilidades de plugins cuando sale una nueva versión, la necesidad de actualizar cada plugin manualmente, todos con unas fechas de lanzamiento completamente distintas y que en muchos casos no han sido probados debidamente…

Cuestión de opiniones y puntos de vista…

La estructura de un nucleo solido y alrededor plugins/widgets es lo que más me atrae de WordPress poder añadir a la base algunos añadidos para mejorarlo y cuando ya no interesan quitarlos.