I was reading the back-and-forth between Miguel de Icaza and Linus Torvalds (with special guest star Alan Cox) over the holiday weekend, and I was hardly surprised by the amount of finger-pointing going on.
In case you missed it, de Icaza got the ball rolling with a blog entry a week ago opining on What Killed the Linux Desktop. The fault, de Icaza stated, lay in the way that Linux developers would consistently deprecate APIs just to improve them, coupled with the myriad of configurations between each separate distro.
The combination of these two factors would create a moving target that most app developers would find insane to build a desktop application. Less apps equal less interest and less users.
de Icaza was not far off in his assessment; his problem lay in trying to lay the blame for this issues squarely on the feet of others. He blamed the Linux kernel development team and Linus Torvalds for the deprecation trend.
"Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers," de Icaza wrote.
This led to a pointed response from Torvalds, who flatly denied that any such attitude or even the situation existed.
"The gnome people claiming that I set the "attitude" that causes them problems is laughable," Torvalds wrote in a thread on Google Plus, "One of the core kernel rules has always been that we never ever break any external interfaces. That rule has been there since day one, although it's gotten much more explicit only in the last few years. The fact that we break internal interfaces that are not visible to userland is totally irrelevant, and a total red herring."
As for the argument about the distros fragmenting everything, Cox had his own curt reply.
"That made me laugh. There was KDE and Miguel then came along and created the very confusion he's ranting about. He was also core to ramming CORBA down peoples throats which then had to be extracted slowly back out of the resulting mess that blighted Gnome 2.x and occupied vast amounts of developer time," Cox wrote in the same thread.
Leaving de Icaza's reasons for these conditions aside for a moment, the fact remains that there are not a lot of popular applications ported to Linux. The classic reasoning has been either one of resources ("why code for a platform with no significant user base?") or technical (variations of the reasons de Icaza cited).
This first reason has always been diabolically circular. You can't get more users until you get more apps… and you can't get more apps until you get more users. Chicken. Egg.
The second set of obstacles is a bit easier to tackle, in that it's a straightforward solution: it should not be technically challenging to build an app for the Linux desktop.
And really, it's not. Developers code awesome apps for Linux all of the time. But (especially in the enterprise) developers tend to create apps that work on whatever distro they're targeting. On a commercial distro, this is a lot easier: the target isn't moving so fast. On community distros, that may not always be the case.
How do we solve this problem of building apps? It's easy to point at solutions like the Linux Standard Base, but that dog won't hunt, possibly because it's not in the commercial vendors' interests to create true cross-distro compatibility. United Linux or a similar consortium probably won't work, for the same reasons.
So, let's get to it. Pretend you have unlimited resources (human or otherwise) and could implement a solution for the Linux desktop. Let's try to be constructive, here: "buy Microsoft and blow up the evacuated Redmond campus" isn't really helping Linux. But "buy Dell and turn them into a Linux version of Apple" could be.
This is your chance to put your ideas out there. Big, small, out-there, or realistic: what's the missing piece in solving the problem of the Linux desktop?
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.