Variety is nice and having choices is nice, but when there's compatibility and man-hours to be spent in ensuring that compatibility/support across all the possible flavors of Linux distributions, I'm not sure we really want "competition".
It's APIs we are talking about here, standards. How would you feel if there were dozens of TCP/IP protocol standards (not just implementations, mind you) and if you wanted to develop any simple networked application you'd need to write a compatibility layer for each and every one of them?
Competition is definitely not what we need in this case, sorry.
But can we affirm that? Can we suppose that there is no way to make a better protocol? What if Mir in the end will become better or will work better or will be more adopted? What if the guys of wayland will fail in making something really good? What if they take some wrong decisions and we will have no alternative in which rely?
We need everywhere competition.
So everyone said "yes, true, valid, you speak honestly here" and they proceeded to develop Wayland and everyone was on board with transitioning to it when it was ready.
Mir has never produced any arguments for its adoption and has only spread false information claiming why it has merits over Wayland.
Free software will usually jump on any software that can clearly state "this replaces X, for reasons Y, because X is insufficient for purpose in these domains Z and can't be fixed". You get situations where projects like pulse and systemd come under fire over disagreements over what Z domains X is appropriate for, not because there are arguments against Y being lacking functionality.
On top of which, everyone is ignoring the Android graphics stack architecture, which is by far the most common Linux-based, open source basis for an interactive userland, with the most apps.
Source: Close friends work at Canonical. No proof, sorry - believe at your own risk.
:D
Seriously Canonical needs to market Ubuntu to device manufacturers to generate an income stream. I really hope they succeed although I think it is a shame that they have felt the need to fork the Graphics sub-system in this way.
Even if we ignore the obvious differences in philosophy and implementation between the two, we're better off that they both exist solely because they've acted as hedges for one another.
When KDE 4 was released, it wasn't exactly ready for widespread use. While things did rapidly improve, GNOME at least provided an option for those who wanted a more modern desktop environment than KDE 3.5 in the interim.
The opposite situation has happened more recently. GNOME 3 was a complete disaster at first, and in many ways still is. Many former GNOME 2 users switched to KDE 4, by that time a mature and very usable desktop environment. Since we have seen only minimal effort from the GNOME 3 community to address its severe problems, the existence of KDE has become more critical for more users.
(I am not an expert on anything.)
It is an implementation of the C, C++ etc standards, and it was also, for long, the canonical such implementation on Linux and Open Source OSes.
Clang has helped show some additional areas where GCC could perhaps be improved, but GCC was surely not "stagnant" at the time. It wasn't like during the EGCS situation in the 1990s.
You see, there's a compatibility issue. The display server has got to be 'supported' by everyone, from applications, toolkits, desktop shells, righ down to the GPU drivers.
That's why the wayland project took so long. Creating a display server is one thing, adopting it on the whole stack is totally different.
Free software, specially on the desktop side, simply lacks the manpower to maintain support for multiple display servers.
If Mir was a drop-in-replacement for Wayland, noone would've been mad. But this situation may cause a huge fork in desktop applications, shells, etc.
Ubuntu is on its and the whole community has adopted Wayland. Im sure sooner or later they will abandon Mir (just like Upstart), because Ubuntu is too small to patch everything just to support Mir.
ALSA is monstrous to configure, but capable.
JACK serves a very specific purpose for music production.
I'm still not sure what pulseaudio is for, but I don't think I'm the target audience for it.
Point is, they don't exist contrary to each other, but in parallel and often in concert.