On January 25th the OSDL released their 2006 Linux client survey analysis, which identified the following barriers for Linux deployment on desktops:
- Application availability
- Quality of peripheral support
- End user training
- Desktop management issue
It is not that applications don’t exist for the Linux desktop, but users grow accustomed to certain applications that they just can’t live without.
Users report they are missing applications as Microsoft Office (OpenOffice.org is the alternative), Adobe Photoshop (which has The Gimp as the closest, but still far alternative), AutoCAD (with QCad as a very far similar) and others.
For peripherals, this is the list:
- Personal storage devices (i.e. USB memory)
- Digital cameras
- Mail and messaging devices
- Web cam / video
However, it is still difficult to buy a printer at your local electronics store and expect it to work out of the box on a Linux machine. While most printers are supported on Linux, there is still a lag from the time when a printer hits the market to when the driver driver is available and automatically installed on your computer by a commercial distro update.
And as a Linux user, I must add that when the device works, it usually won’t work with its full set of capabilities, because drivers are usually written by third parties on the OSS world – and not by their manufacturers, which are expected to have a much deeper knowledge (and project commitment) on these hardware capabilities.
So the problem is a committed application and drivers development. Well, how can companies commit themselves to develop desktop software (which means friendly to non-technicall users) in a world that had not decided yet about some elementary standards? Yes, there is the FreeDesktop.org initiative but the standards they are focused on are more related to KDE-Gnome interoperability.
Most important standards that must be defined will find their home in a layer bellow: LSB. But unfortunately, the Linux Standard Base still has a big job to finish and still seems to have difficulties to catch up with ISVs.
As an example, there is no de facto standard defined for things as trivial as a configuration files format for the whole system, not only for desktop apps. This is particularly important because configurations are what makes software run in a specific way. They are the soul of any software (while code is the body). A popular standard for configurations will provide ways for any software to collaborate with, and auto-configure any other software. On Windows, this was successfully achieved with its registry. On Linux, similar but broader and better alternatives exist (as the Elektra Initiative), but this is a subject that seems to not inspire the OSS community.
Standards bodies can’t do everything alone. The community must be ready for changes, adaptations, and have courage to throw away code that was not choosed by the standard, and start focusing on what was selected to be part of it. Courage to stop reinventing the wheel. For example, on a vanilla KDE installation you will find about 4 different media players (Amarok, Juk, kboodle, noatun, etc) and 3 different plain editors (kate, kedit, kwriter). If you have Gnome installed on same system, add a few more to each class of applications (and to the icons that will appear on your menus). This is confusing, fat and bad.
Another important fact on the analysis is a 49% desktop share for Canonical’s Ubuntu Linux, against RHEL and SLED with 16% each. RHEL and SuSE are more popular on servers and are essentially and structurally different distributions, but both use RPM as their packaging system. While Ubuntu is radically different from both, based on Debian, with the DEB format for packages. A well known and well used packaging system is very important on a desktop world, because this is what guarantees an easy, painless software installations and upgrades. So if I am an ISV with limited technicall staff and time resources, how should I package my software for easy deployment? DEB or RPM? If RPM, should I focus on Red Hat or SuSE flavors? Though questions.
Application vendors cannot afford to develop, distribute, and support applications across a fragmented Linux market.
Red Hat and Novell should look at their future server market, paying attention on what is happening today on the desktop. History shows that people tend to bring to work (and to servers) what they like and use on their desktops at home. This is Ubuntu’s long term strategy and they seem to be succeeding, at least on their first phase.