Acaban de salir las nuevas versiones 1.7 de Wayland y de Weston. Lo interesante de estas versiones no son los cambios que traen, sino que los desarrolladores han decidido abordar uno de los mitos que últimamente llevan circulando en los foros cada vez se habla de Wayland: ¿cuando va a estar terminado? Y la respuesta es: el protocolo Wayland ya está terminado. El core del protocolo ya no va a cambiar (es dudoso que a estas alturas se vaya a encontrar un fallo lo suficientemente importante como para tener que hacer modificaciones en el diseño), las APIs ya son estables y lo único que queda es utilizarlas.

Por otro lado, Wayland está construido de tal forma que es muy fácil añadir extensiones, y de hecho hay una extensión que lleva esperándose desde hace tiempo: xdg-shell, la extensión que define operaciones de escritorio de "alto nivel" (como minimizar ventanas). Esta extensión requiere de la conformidad de los distintos entornos de escritorio (KDE, GNOME, etc) a los que va dirigida. Pero éstos todavía están trabajando en sus respectivas implementaciones de Wayland, con lo que la definición de la extensión no está lo suficientemente madura como para incluirla oficialmente. Pero es cuestión de tiempo que llegue, y a partir de ahí el único trabajo en perspectiva para el proyecto será el de mantenimiento y corrección de errores.

De hecho, es lo que ya ha sucedido en esta versión 1.7, donde los cambios son fundamentalmente cosméticos: mejorar la documentación, algunos bugfixes y poco más. Y es lo que seguramente pasará en la ya planificada versión 1.8 que aparecerá dentro de 3 meses, salvo que xdg-shell esté lista para entonces.

Otra historia diferente es Weston, el proyecto compañero de Wayland. Hasta ahora Weston se había descrito como el "compositor de referencia", pero la idea detrás de este compositor (de este servidor Wayland para entendernos) era tener un software de pruebas y experimentación dónde poder evolucionar el protocolo, no la de escribir un servidor real listo para producción. El problema es que hay una percepción errónea generalizada que confunde Wayland con Weston, por lo que los fallos y las carencias de Weston terminan achacándose a Wayland. O dicho de otra forma, se piensa que Wayland todavía no estaba terminado porque Weston no funciona todo lo bien que se espera de un software en producción (cosa que no es).

Es por esto que, ahora que el desarrollo de Wayland se acaba, en el seno de los desarrolladores del proyecto surgió la cuestión sobre qué hacer con Weston: "¿Hacia dónde debería ir Weston?" ¿Debería seguir como hasta ahora, o debería dedicarse a otro propósito? ¿Había que convertirlo en un auténtico compositor listo para producción? En palabras de Bryce Harrington (desarrollador y actual release manager):

I've noticed over the years, that I can say until I'm blue in the face that "Wayland is just a protocol, Weston is just a reference implementation, and you need to look at desktop environments to provide Wayland compositors;" but people still keep asking me, "Okay, but when can I ditch X and just use Wayland as my desktop?"

Or the corollary: "If the Wayland protocol was finished some years ago, and weston is 'just' a reference implementation, why is there still development effort on it?" The implication being that it's being called a reference implementation much the way X.org is "just" a reference implementation of X11.

There is a public [misperception? expectation? belief?] that Wayland is a software product that will one day arrive and revolutionize their desktop/smartphone/helicopter/dishwasher experience. Or at least fix some <mumble> problems that exist with X's architecture.

So I figure there's two options. One would be to chase this public sentiment and start handling Weston as a regular desktop server product development effort. Weston's focus would need to be restrained, as per the other requirements, so the desktop use case would be limited to the audience for "minimal/lightweight" (nvidia-free?) DEs. If this is successful, the law of the slippery slope will inevitably lead us to implementing more and more features until it fulfills Zawinski's law.

The other option is to get weston's head and heart aligned, and strengthen our focus on being "just" a test bed for improving the Wayland protocol. Give our community's primary attention not to Weston's users but Wayland's users - Enlightenment, GNOME, KDE, and other DEs. Survey and study their requirements and look for things they need across the board. And make it easier for them to bring us their problems/ideas/needs. Make it convenient for people to do prototyping and experimentation in Weston first, and then port to production compositors, rather than vice versa. Instead of unit testing weston, improve the validation testing of wayland, such that the same testsuite would run against the weston compositor, enlightenment compositor, et al to verify that the DEs have properly implemented the protocol requirements. Instead of delivering a monolithic Weston package, turn the best bits of it into specialized libraries that DEs can use too (if they wish). Define a clear process for 3rd parties to contribute extensions, libraries, and driver support changes. Finally, work to change public perception to stop the expectations on producing Weston-the-desktop, by vocally championing DEs that are already giving solid Wayland-based desktops.

La decisión tomada ha sido (como habéis podido leer en el anuncio de Weston 1.7) que no tiene sentido que Weston compita con los que deben ser los verdaderos compositors Wayland (KWin, GNOME Mutter, el de Enlightenment E19, el de Hawaii, etc):

We reached concensus that Weston should certainly not aim to become a end-user usable desktop environment. That rather, Weston's ultimate goal is to help the Enlightenments, GNOMEs, KDEs, and others to provide faster, glitch-free desktop environments to users, with a universal core protocol.

Sin embargo, Weston puede cubrir dos interesantes roles: uno, el de una biblioteca donde obtener componentes ya hechos y probados de partes necesarias en cualquier compositor Wayland (como puede ser libinput para manejar los dispositivos de entrada). El otro, convertirse en un auténtico banco de pruebas del protocolo que los desarrolladores de compositors pueden usar para mejorar sus propias implementaciones:

With this comes recognition that we can do more than merely be a test bed but provide a rich test environment and set of testing tools.

Es evidente (o debería serlo) que una test suite no es el software adecuado para probar un protocolo, excepto que seas un desarrollador y lo que busques es verificar el funcionamiento de ciertos detalles del mismo. Los usuarios que quieran probar un protocolo lo que necesitan es una implementación robusta, estable y lista para producción, y eso Weston no lo es. El problema es cómo transmitirlo, cómo hacer llegar al común de los mortales linuxeros que Weston no es la piedra de toque que deben usar para evaluar Wayland. A estas alturas va a ser un trabajo arduo cambiar esa percepción.

Por suerte, las últimas versiones de Mutter, el compositor Wayland de GNOME, parecen haber alcanzado la calidad requerida para poder evaluar el potencial de Wayland. Así que ahora al menos sí que hay una opción real a la que apuntar cuando alguien diga que quiere ver "eso de Wayland" en acción, mientras esperamos a que vayan llegando el resto de los compositors y entornos de escritorio prometidos.

:wq