1. The developer culture
In de Icaza's view, the problem with Linux on the Desktop is rooted in the developer culture that was created around it.
The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees.
And we did.
We deprecated APIs, because there was a better way. We removed functionality because "that approach is broken," for degrees of broken from "it is a security hole" all the way to "it does not conform to the new style we are using."In essence, de Icaza argues that the Desktop became a moving target. Developers created new ways to do things, and deprecated the now-outmoded methods. While this happens in proprietary software, as well, the cycle is often much shorter in open source software.
2. Incompatibilities between distributions
Fragmentation and differences between similar Linux on the Desktop implementations was also a major factor, according to de Icaza. "Either they did not agree, the schedule of the transitions were out of sync or there were competing implementations for the same functionality."
In de Icaza's view, having to support different desktop environments that were all "Linux" killed the ecosystem for third party developers trying to target Linux on the Desktop. You would try once, do your best effort to support the "top" distro (such as Fedora or Ubuntu) only to find out that your software no longer worked six months later.
de Icaza argues that few developers are interested in stabilizing and supporting a standard API. "Backwards compatibility, and compatibility across Linux distributions is not a sexy problem. It is not even remotely an interesting problem to solve. Nobody wants to do that work, everyone wants to innovate, and be responsible for the next big feature in Linux."
In short, de Icaza says Linux on the Desktop lost the race for a consumer operating system to the likes of Windows and Mac OSX, both of which have stable APIs that programs can rely on for many years. "Meanwhile, you can still run the 2001 Photoshop that came when XP was launched on Windows 8. And you can still run your old OSX apps on Mountain Lion."
While 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) yet we still have four major desktop APIs, each popular and slightly incompatible versions of Linux on the Desktop. Different OS subsystems, different packaging systems, different dependencies and slightly different versions of the core libraries. This model works great for pure open source, where an open source distribution can simply recompile programs to run on the new platform, but does not work well for proprietary code that need certain operating assumptions to remain true. Shipping and maintaining applications for these rapidly evolving platforms is a big challenge.