Sunday, September 07, 2008

For as long as anyone can remember, one of the big problems with Linux has been the lack of commercial applications. Independent software vendors (ISVs) are generally sticking to Windows or OS X, resulting in very little commercial software being available for Linux. Free software ideologies aside, there are many commercial applications that Linux would benefit from being able to run.

As a cross-platform software developer, there are many challenging issues that are unique to developing on Linux. First and foremost, there is the issue of binary compatibility.

In order to build a x86 Linux binary that runs on as many desktop Linux distributions as possible, the most widely documented procedure is to simply build your application on the oldest distribution you can find. Most Linux libraries are backwards-compatible, meaning an application compiled against older version will run with newer versions of the library. In theory, this seems like a reasonable way to make a universal Linux binary. In practice, things are very different - Do you statically link or dynamically link and bundle the libraries? How exactly does one do all of this? Is it practical to roll this procedure into your build system? Furthermore, where is the official documentation for this procedure? What are the best practices for producing a universal x86 Linux binary?

Another issue is software distribution. As a commerical software developer, how do you distribute your software to as many customers as possible? You'd need to create DEB and RPM packages, and probably have some generic graphical installer package as well. On Windows, a single installer .EXE will install on 2000, XP, Vista, etc. On Linux, you either need to create tons of packages, or you have to limit your customer base by creating packages for only the most popular distros. Already you've multiplied the amount of effort required to develop for Linux manyfold.

Additionally, you're fighting an uphill battle against open source software. If Adobe made a version of Photoshop for Linux (and allowed you to buy DEBs from their site), most people would still just install GIMP through Synaptic or Ubuntu's Add/Remove Applications dialog. Even worse (for Adobe), GIMP is installed on every Ubuntu system by default. The best Adobe can hope for is to offer DEBs via their site, and hope that people have a priori knowledge of their product, and go to their website to buy it. There is no "App Store" for Ubuntu, and perhaps there should be because distributions certainly don't make it easy to sell your software for Linux.

Many of these issues that are hindering independent software vendors from developing applications for Linux could be alleviated by much better organization by the Linux Foundation. When I originally heard about the Linux Standard Base (LSB), I was excited at the prospect of finally having universal x86 binaries for Linux, and perhaps it would finally open the door for more commercial Linux applications, I thought. However, to date, I can count the number of LSB certified applications on one hand. Mass adoption of Linux by ISVs did not happen, and I can't say that I blame them. If I were a developer coming from Windows, I wouldn't know where to start. The Linux Foundation's getting started guide includes an article on porting your application to the LSB, but that's for existing Linux applications, not for applications that already run on another platform.

If I were a developer looking to write a new application on Linux, I would not know where to begin. Do I use GTK or QT? wxWidgets? What are the standard system libraries on Linux? Where is everything documented? There is no central documentation repository that guides Linux developers and provides answers to this question. Windows developers have MSDN, OS X developers have Apple's Developer Connection, Linux developers have nothing but a bunch of scattered webpages, each trying to convince you that their library is the best one to use. This is not a productive approach, and an organization like the Linux Foundation should make a serious effort to give developers the information they need to develop their applications quickly. You can't expect developers coming from Windows to know what libraries to use by googling for answers - There needs to be some centralized site that provides developers with the answers they need. To me, this highlights the lack of leadership in the Linux desktop community.

In the kernel, it's very clear who is in charge. There is a clear structure of command, and this allows the kernel developers to work as an effective organization. Within the userspace (ie. libraries and software applications), we do not see the same command structure. We have Freedesktop.org creating "standards" and backend software for the Linux platform, but of the software hosted on it, it claims:

None of this is "endorsed" by anyone or implied to be standard software, remember that freedesktop.org is a collaboration forum, so anyone is encouraged to host stuff here if it's on-topic.

What desktop Linux appears to have is a plethora of organizations acting independently (creating libraries, etc.), with no clear cross-organization leadership. Freedesktop.org has been successful in getting many of these organizations to cooperate and has undoubtably resulted in an improved desktop Linux (see HAL and DBus), but it doesn't seem to be preaching a clear vision to those organizations, nor providing any guidance for new developers wishing to take advantage of the new technologies it has fostered.

Many of my views presented here have been shaped by my experience writing proprietary software on an embedded Linux platform. I've worked with engineers who've never written software for Linux, and they have a hard time answering the questions they have because Linux doesn't have something like MSDN. It's very easy to make bad decisions about what libraries to use on Linux due to the lack of centralized documentation.

The nightmare of binary compatibility, lack of support from Linux distributions, and the absence of centralized documentation and guidance for Linux software developers make it a difficult and expensive platform to develop on. It's a great platform to slap together little applications on, but when you have to deal seriously with the issues that independent software vendors have to deal with when developing desktop applications, Linux as a platform simply isn't worth the effort.

CyberLink is just experimenting with this, they don't expect to make a lot of money from it. They make their money from distribution deals like getting bundled with DVD-ROMs, or more recently, getting bundled with Linux-based Netbooks/MIDs, not from selling their software in stores. I suspect this is also an experiment on Canonical's part, as they gauge the response of Ubuntu users and find the optimal way to integrate this into Ubuntu (hopefully in Add/Remove Applications one day).

4 comments:

Anonymous
said...

Trying not to show any distro / commercial bias with this statement but things like freedesktop.org and even the open suse build service (generates packages for different distros DEB/RPM/etc) are two initiatives started by SuSe/Novell. Ubuntu may be driving mass user adoption but I agree with your points about the Linux foundation in that if no one steps in to try and unify as much that can be unified then it is a waste. For the record I use SuSe at work and Ubuntu at home...

You are right that it is hard to build a commercial, closed-source software on the Linux. But I don't think that it will be a big problem in 2-3 years. Services distributed trough the internet (SAAS) is a new paradigm that will totally break any software/OS incompatibility. Nowadays more and more custom commercial software is converted into web applications, as well as widely used commercial apps like MS office or Photoshop. Other applications should remain free and open source (do you really want to pay for CD burning software, or photo viewer :) ).