W3C elimina WordPress de la consideración para el rediseño, restringe la lista restringida de CMS a Statamic y Craft

El World Wide Web Consortium ( W3C ), la organización internacional de estándares para la web, está rediseñando su sitio web y pronto seleccionará un nuevo CMS. Aunque WordPress ya se usa para administrar el blog del W3C y las secciones de noticias del sitio web, la organización está abierta a adoptar un nuevo CMS para cumplir con su lista de preferencias y requisitos.

Studio 24, la agencia digital seleccionada para el proyecto de rediseño, limitó su consideración a tres candidatos de CMS:

1. estático
2. CMS artesanal
3. WordPress

Studio 24 tenía como objetivo finalizar sus recomendaciones en julio, pero descubrió que ninguna de ellas cumplía con las pautas de accesibilidad de la herramienta de creación del W3C. Los CMS que cumplieron mejor con las pautas no se adaptaron tan bien a los otros requisitos del proyecto.

En la actualización de proyecto más reciente publicada en el sitio, Studio 24 informó que preseleccionaron dos plataformas CMS. Coralie Mercier, directora de marketing y comunicaciones del W3C, confirmó que estos incluyen Statamic y Craft CMS.

WordPress no se sometió al mismo proceso de revisión, ya que el equipo de Studio 24 afirma tener una amplia experiencia trabajando con él. En el resumen de sus preocupaciones, Studio 24 citó a Gutenberg, problemas de accesibilidad y el hecho de que el complemento Classic Editor dejará de mantenerse oficialmente el 31 de diciembre de 2021:

En primer lugar, nos preocupa la longevidad de WordPress a medida que lo usamos . WordPress lanzó una nueva versión de su editor en 2018: Gutenberg. Ya hemos rechazado el uso de Gutenberg en el contexto de este proyecto debido a problemas de accesibilidad.

Si elegimos acabar con Gutenberg ahora, no podemos volver a él en una fecha posterior. Esto equivaldría a comenzar desde cero con toda la configuración y la temática del CMS.

Gutenberg es el futuro de WordPress. El equipo de desarrollo del núcleo de WordPress sigue impulsándolo y quiere implementarlo en todas las áreas del sistema de gestión de contenido (navegación, barra lateral, opciones, etc.) en lugar de limitar su uso al editor de contenido principal, como ocurre actualmente.

Esto significa que si queremos usar WordPress a largo plazo, tendremos que eludir a Gutenberg y seguir eludiéndolo durante mucho tiempo y en más áreas del CMS a medida que pasa el tiempo.

Otro factor importante en la decisión de eliminar WordPress de la consideración fue que no encontraron "una solución elegante para la localización y traducción de contenido".

Studio 24 también expresó su preocupación de que herramientas como ACF, Fewbricks y otros complementos no se mantengan para la experiencia del Editor clásico "en el contexto de una adopción generalizada de Gutenberg por parte de usuarios y desarrolladores".

"En términos más generales, creemos que este impulso para expandir Gutenberg es una indicación de que WordPress se enfoca en los requisitos de su base de usuarios no técnicos en lugar de su audiencia de desarrolladores web que crean soluciones personalizadas para sus clientes".

Parece que la agencia digital W3C seleccionada para el proyecto es menos optimista sobre el futuro de Gutenberg y es posible que no haya revisado las mejoras recientes en la experiencia de edición general desde 2018, incluidas las relacionadas con la accesibilidad.

El consultor de accesibilidad y colaborador de WordPress Joe Dolson recientemente dio una actualización sobre la auditoría de accesibilidad de Gutenberg en WPCampus 2020 Online. Informó que, si bien aún quedan desafíos pendientes, muchos problemas planteados en la auditoría se han abordado en toda la interfaz y se han resuelto 2/3 de ellos. “La accesibilidad general de Gutenberg ha mejorado enormemente hoy en día con respecto a lo que era en el lanzamiento”, dijo Dolson.

Desafortunadamente, Studio 24 no sometió a WordPress a las mismas pruebas de accesibilidad y creación de contenido que usó para Statamic y Craft CMS. Esto puede deberse a que ya habían planeado usar una implementación del Editor clásico y no vieron la necesidad de poner a prueba a Gutenberg.

Estas pruebas involucraron la creación de páginas con "componentes flexibles" a los que se refirieron como "bloques de diseño", para cosas como títulos, entrada de texto WYSIWYG y videos. También implicó crear una plantilla para noticias donde se mostraría todo el contenido ingresado por el usuario (sin formatear).

Gutenberg se prestaría bien para estos casos de uso, pero no se probó formalmente con los otros candidatos, debido a que el equipo citó su "amplia experiencia" con WordPress. Me gustaría ver al equipo del W3C volver a visitar Gutenberg para una justa sacudida contra los CMS propietarios.

W3C está priorizando la accesibilidad sobre sus preferencias de licencias de código abierto

El documento que describe los requisitos de CMS para el proyecto establece que "W3C tiene una fuerte preferencia por una licencia de código abierto para la plataforma CMS", así como "un CMS que sea duradero y fácil de mantener". Esta preferencia puede deberse a los beneficios económicos de usar un CMS estable y ampliamente adoptado, o puede estar inspirada por la innegable simbiosis entre el código abierto y los estándares abiertos.

“La industria ha aprendido por experiencia que los únicos estándares relacionados con el software que logran plenamente [sus] objetivos son aquellos que no solo permiten sino que fomentan las implementaciones de código abierto. Las implementaciones de código abierto son un control de calidad y honestidad para cualquier estándar abierto que pueda implementarse en el software…”

Iniciativa de código abierto

WordPress es el único de los tres candidatos originales que se distribuirá bajo una licencia compatible con OSD. (El código CMS disponible en GitHub no es el mismo).

Usar software propietario para publicar los estándares abiertos que sustentan la web no es una buena idea. Si bien los fabricantes de software propietario son ciertamente capaces de implementar estándares abiertos, independientemente de la licencia, existen innumerables beneficios para los estándares abiertos en el contexto del uso de código abierto:

“La comunidad de participantes que trabajan con OSS puede promover un debate abierto que resulte en un mayor reconocimiento de los beneficios de varias soluciones y dicho debate puede acelerar la adopción de soluciones que son populares entre los participantes de OSS. Estas características de la evolución de soporte de OSS de soluciones robustas son a menudo un impulso significativo para la adopción de estándares abiertos en el mercado, además de los incentivos impulsados ​​por el cliente para la interoperabilidad y los estándares abiertos”.

Revista internacional de ingeniería y aplicaciones de software

Aunque tanto Craft CMS como Statamic tienen sus bases de código disponibles en GitHub, comparten modelos de licencia igualmente restrictivos. El documento de contribución de Craft CMS establece:

Craft no es FOSS
Dejemos una cosa clara: Craft CMS es un software propietario . Todo en este repositorio, incluido el código aportado por la comunidad, es propiedad de Pixel & Tonic.

Eso viene con algunas limitaciones sobre lo que puede hacer con el código:

– No puede cambiar nada relacionado con la concesión de licencias, la compra, la selección de edición/características o cualquier otra cosa que pueda alterar nuestro presupuesto de bebidas alcohólicas.
– No puedes mantener públicamente una bifurcación a largo plazo de Craft. Solo hay Un Arte Verdadero.

Los documentos contribuyentes de Statamic tienen restricciones similares:

Statamic no es un software gratuito de código abierto. es propietario Todo en este y nuestros otros repositorios en Github, incluido el código aportado por la comunidad, es propiedad de Wilderborn. Por esa razón, existen algunas limitaciones sobre cómo puede usar el código:

Los proyectos con este tipo de licencias restrictivas a menudo no atraen mucha contribución o adopción, porque las libertades no están claras.

En un problema de GitHub que solicita que Craft CMS sea de código abierto, el fundador y director ejecutivo de Craft, Brandon Kelly, dijo: "Craft no es un código cerrado: todo el código fuente está aquí en GitHub", y afirma que la licencia es relativamente ilimitada en lo que respecta al software propietario. va, que contribuir funciona de manera similar a los proyectos FOSS. Este razonamiento no es lo suficientemente convincente para algunos desarrolladores que comentan el hilo.

“Dudo un poco en recomendar Craft con una licencia de código abierto personalizada”, dijo Frank Anderson. “Incluso si se tratara de una licencia MIT+ que añadiera la licencia y el pago, como solía tener React. Dudo porque se han probado las licencias estándar de código abierto”.

Cuando se le preguntó acerca de las preocupaciones de licencia de Studio 24 al reducir sus candidatos a dos opciones de software propietario, Coralie Mercier me dijo: "estamos priorizando la accesibilidad". Una actualización reciente del proyecto también informa que ambos proveedores de CMS que W3C está revisando "se han comprometido positivamente con las necesidades de accesibilidad de la herramienta de creación y han progresado en esta área".

Incluso si tiene equipos cooperativos en CMS propietarios que están trabajando en mejoras de accesibilidad como resultado de este cliente de alto perfil, no se puede comparar con la comunidad masiva de colaboradores que permite la licencia compatible con OSD.

Es lamentable que el estado de la accesibilidad de CMS de código abierto haya obligado a la organización a reducir sus selecciones a opciones de software propietario para su primer rediseño en más de una década.

Los estándares abiertos van de la mano con el código abierto. Existe una conexión mutuamente beneficiosa entre los dos que ha hecho que la web prospere. No veo el uso de un CMS propietario como una extensión de los valores W3C, y no está claro cuánto más beneficio para la accesibilidad ofrecen las opciones propietarias en comparación. El W3C puede ser neutral en los debates sobre licencias, pero en aras de la apertura, creo que la organización debería adoptar un CMS de código abierto, incluso si no es WordPress.