Short term this might be a far slower and worse approach. It's not clear that's the case long term though, making things easier to try out different ideas and then finding a winning compositor project could be better than being stuck with one.
We are way past the short term with Wayland!
Wayland is 17 year old.
It does not matter if the devs alone worked on it in isolation but at what point there was public use. The earliest you could argue it was being used by user on a distro would be 2016 in fedora. Actual mainstream use in ubuntu around 2021 but optional and default literally only just this year.
If development for X is ceasing now, there isn't time to experiment on finding the true successor.
Bazaar-style development seems to work for command-line tools, but I don't think it works well for a coherent desktop experience. We've had so much fragmentation, from KDE/Qt vs GNOME/GTK, to now X11 vs Wayland. Even X11 itself didn't come from the bazaar, but rather from MIT, DEC, and IBM (https://en.wikipedia.org/wiki/X_Window_System).
Perhaps...
> Open source development should take some lessons if they want to be successful
A lot of people who write the gui stuff for Linux do it because they want to. Success is not necessarily the same metric as a company making a product.
There are companies working within the space and I doubt the licensing really makes much difference to the outcome (i.e. your Google example)
> If development for X is ceasing now, there isn't time to experiment on finding the true successor.
Why? Again, the people working on it because they want to don't need to do anything, they can experiment. Someone can still fix up issues in X. Some companies will fund the development of things that are important to them. You make it sound like the oss community should be acting like one entity to achieve something, but there is no overarching goal nor a reason for there to be one. People will continue pulling in different directions.
Think about how many people might want to write for it if it had a compelling ui stack, tho
Phones are a different market from computers, even though they're technically the same thing. A large segment of people own "phones" but not a computer. Linux runs a large chunk of the internet. I think it's used quite well at scale.
Certainly not in a high-productivity environment. Google has to swap out most of the runtime components with distributed alternatives to make it compelling in a corporate (distributed) environment.
But even if there's only one cook, it could be worse (if that cook is the gnome team). At least with multiple cooks we can pick kde instead of gnome.
I can't say i've ever wanted a second compositor to choose from. Ideally it would just be part of the window server.
Why not just make a display server (which handles everything rendering related, compositing included), and then add a window manager as a plugin/extension on top? Window managers are not that complicated.
But I may be wrong here
This is the industry standard, putting the compositor and window manager in separate processes.
Android separates SurfaceFlinger and WindowManagerService.
iOS separates quartz compositor and springboard.
Windows separates dwm and explore.
MacOS separates WindowServer and Dock.
If you are talking about the shell or task switcher, then yeah your point stand with Gnome but KDE has kwin and plasmashell processes.
macOS is the same way, except Carbon (a light modification to the procedural Toolbox API) and Cocoa (the Mac's first OOP toolkit) were "toll-free bridged" to each other rather than, say, writing Cocoa in terms of Carbon.
In contrast, X11 is a protocol anyone can implement and speak. There is no blessed library that you must use. No, Xlib doesn't count. Servers have to take their clients as they come. And Wayland, while very much deliberately stripped down from X, still retains this property of "the demarc point is a protocol" while every proprietary OS (and Android) went with "the demarc point is a library".
Apple/Microsoft can do whatever they want, just break compatibility at any point and everyone else wanting to have their programs supported on their platform will adapt.
Meanwhile for Linux network effect has a much bigger role to play, you can't tell anyone else what to do, but protocols can only emerge from working together.
Also, I wouldn't bring up Microsoft's display stack as a positive example at all.
Those two are worlds apart when it comes to backward compatibility.
> Also, I wouldn't bring up Microsoft's display stack as a positive example at all.
Why not? It's doing exactly what it's supposed to do, and has been since the late 90s. There's tons of fundamental improvements since then, but they're all under the hood without affecting user-facing features. I'd say the Windows display stack modernization is an excellent example of how it should be done.
>This is not a technical difference at all.
Which is why I said it was a problem with leadership than with the technical merrits.
Just compare this to Windows and how they made this rearchitecture of making their compositor more modern without splitting into 10s of compositors and breaking a ton of apps.