Incompatible components
Moving on, the next item on Icaza's list is the lack of coordination between the various Linux distros:
"The second dimension to the problem is that no two Linux distributions agreed on which core components the system should use. Either they did not agree, the schedule of the transitions were out of sync, or there were competing implementations for the same functionality."
He illustrates this by again bringing up the kernel. "The efforts to standardise on a kernel and a set of core libraries were undermined by the distro of the day that held the position of power. If you are the top dog, you did not want to make any concessions that would help other distributions catch up with you. Being incompatible became a way of gaining market share. A strategy that continues to be employed by the 800 pound gorillas in the Linux world."
Although there is merit in Icaza's argument, the kernel developers couldn't help but note the irony here. Alan Cox, one of the most respected Linux developers, replies:
"That made me laugh. There was KDE, and Miguel then came along and created the very confusion he's ranting about."
Broken Gnome
Cox goes further and blames Gnome for breaking compatibility on the desktop, saying Icaza is "dead right about the way the Gnome people keep breaking their compatibility every time, not just with the apps but with the UI, with the config (which is still worse now than in Gnome 1.x !) and so on. However, it's not an open source disease, it's certain projects, like Gnome, disease."
Cox and another kernel developer, Ingo Molnar, then point to the kernel's excellent backward compatibility. Molnar writes that "the Linux kernel project was always very strict about keeping its external ABIs, intended ABIs and even accidental ABIs. This is how it's possible that Alan Cox's 20-years-old Rogue game binary, built in 1992, is still compatible with and working on today's latest Linux kernel unmodified - and will still work 50 years in the future."
An ABI (Application Binary Interface) is the interface between a computer program and the operating system and defines, among other things, how an application should make system calls to the operating system. Although both his claims were challenged and overruled by respected and knowledgeable members of the open source fraternity, Icaza, in his original post, concludes that together they created an ecosystem that didn't appear to be very welcoming to third-party desktop app developers.
"You would try once, do your best effort to support the 'top' distro, or if you were feeling generous 'the top three' distros. Only to find out that your software no longer worked six months later."
Again, he blames the developer-focused approach, which he acknowledges helped pioneer things such as package management. But in the process, they missed "the bigger picture" and alienated third-party developers.
In an update to his post, Icaza clarifies his position and praises the desktop distros, saying that "the various Linux on the desktops are the best they have ever been. Ubuntu and Unity, Fedora and GnomeShell, RHEL and Gnome 2, Debian and Xfce, plus the KDE distros," but adds that this still leaves us with "four major desktop APIs, and about half-a-dozen popular and slightly incompatible versions of Linux on the desktop: each with its own curated OS subsystems, with different packaging systems, with different dependencies and slightly different versions of the core libraries."
On the Google+ thread, he adds: "supporting Linux desktop for proprietary software developers is just too expensive and the market is both small and deeply fragmented."
Icaza's views were endorsed by Christian Hammond, a VMware developer who works on the Workstation and Player apps for Linux. Responding to Icaza's post, Hammond, on Twitter, writes that at VMware they spent a considerable amount of time handling the "compatibility crap".
