In response to Wayland Breaks Your Bad Software
I say that the technical merits are irrelevant because I don’t believe that they’re a major factor any more in most people moving or not moving to Wayland.
With only a slight amount of generalization, none of these people will be moved by Wayland’s technical merits. The energetic people who could be persuaded by technical merits to go through switching desktop environments or in some cases replacing hardware (or accepting limited features) have mostly moved to Wayland already. The people who remain on X are there either because they don’t want to rebuild their desktop environment, they don’t want to do without features and performance they currently have, or their Linux distribution doesn’t think their desktop should switch to Wayland yet.
But even that’s a relatively high bar. Wl-roots is self-described as “60000 lines of code you don’t have to write yourself”, and any arbitrary compositor may not use it or may not be up-to-date with it. In X11, you don’t need 60,000 lines of code to be functional. Hell, the example Window Manager that was printed as a couple of chapters in the old X11R5 reference books works well enough especially considering its size.
I feel like I missed the historic genesis of this particular quagmire. Knowing that a composer was essential, you’d expect developers would want to make very robust core functionality-- a super-rich libweston or something like wl-roots, so that “real” compositors would just be paper-thin extensions that answered the opinionated parts. Did early Wayland design get bogged down on embedded-style use cases where such features were seen as too expensive (compare: no built-in printf in C), or was it a deliberate territory grab by early compositor developers, trying to turn it into a place they could to gain competitive advantage?