I have mentioned it before, and I will repeat it here again: any commercial software vendor pondering to sell his product or service on the Linux platform is horrified by the complications he has to deal with.


As you might know, I am involved with FreeNX, the project to make remote GUI access fast. FreeNX is based on the core NX libraries and utilities which are developed by NoMachine.com (a commercial company), but released under the GPL.


Now, releasing code under the GPL, and for free, doesn't sustain a commercial company. What NoMachine does for a living, is to compile their code and bundle it into an "NX Server" product, put some good propietary addons into the bag and sell the thing, while still releasing the core parts as GPL-source code. Their source code is an invaluable gift to the Free and Open Source Software communities -- but it requires an experienced user to compile, install and use. NoMachine's server products are easy to handle. FreeNX makes the source code gift from NoMachine usable for a broader user base.


NX and FreeNX are pretty cool, because they can help you to gain remote access to your own company desktop while you are "on the road" or working from a home office -- and it works amazingly well even over a dial-up modem link. Or they can help to create and run a Linux (and Cross Platform) Application Server Farm for Thin and Fat Clients much more efficiently than by using traditional means like LTSP. NX and FreeNX provide the fastest remote GUI experience that is out there, and the most secure one (using SSH) over the internet.]


But this is not an editorial about the technical merits and features of NX. I'd rather take it as example to hightlight another topic: the pains any ISV has to take upon himself if he decides to support the Linux OS with his products.


Look that the download site of NoMachine.com, look closely on the list of NX Clients they offer (for free as in beer, I should say -- NoMachine only charge for their server licenses):

• there is exactly 1 MS Windows executable for download,
• while there are 16 (in words: sixteen) different packages for Linux for download.

Moreover, I know that this one Window NX Client executable works, and works fine on Windows 95, Windows 98, Windows ME, Windows 2000 and Windows XP (don't know about Windows 2003) -- MS operating system spanning over a decade. And it sports an easy to use installer.


Enter Linux. There are 7 different packages that support SuSE. (SuSE versions 7.3 - 9.2, RPMs as well as statically linked versions in tar.gz format). There are 6 different packages to support Red Hat and Fedora. There are *rpms, *.debs and *.tar.gzs package formats... But the versions supported span not even 5 years.


Can you imagine how much blood, sweat and tears (let alone time, money and other resources) it takes to create a single new release of their software? Create all these packages, test them, upload to the website and adapt the website too to reflect the new versions?


Now, NoMachine for sure is a very Linux and Unix-affine company. They and their workers have already some tradition and experience in developing and packaging for Linux. But what about ISVs pondering to move from their current "Windows-only" realm into a "Linux-too" world?


The NoMachine download website does highlight in a nutshell the problems any ISV has to solve before he can offer his products for the Linux platform.


Ah, I hear voices saying "Linux Standards Base!" Oh, yes. The LSB is great. But is its version 2.0 already something that can satisfy a software vendor interested in Linux? When will version 3.0 be ready? If soon -- how long will it take for the Linux distributions to adapt it? How long will it take to re-create or re-compile all the software that by now runs fine on their current hosts so that it complies to the LSB? How long will it take to provide a KDE version that complies to LSB 3.0?


Now imagine you are an ISV (independent software vendor) who wants to offer his software on a Linux desktop. You don't want to do the ugly thing -- you want to integrate it as tightly as possible into the environment it runs in.


"Easy", you say. "Take KDE!". Yes, KDE is a great platform to develop for. But what about the other desktop environments? You sure want your app to run there too, and to utilize their infrastructure (or at least what they offer for one).


An ISV new to Linux does not want to decide for one of the two desktops. He wants his products to run on both. He does not want (or he can not afford) to package 16 different versions for each point release of his software. And he wants an assurance that his current release will run and work well even in the KDE of 2008.


How can we solve that? How we can offer ISVs an entry point to the Linux desktop platform that is manageable for them?


The future of the Linux desktop, in terms of adoption, offers two different alternatives:

• either it basically remains what it is now: a desktop system used by
  geeks and nerds, and a few ambitious industrial or governmental
  early adapters, where there is no major buy-in from the
  traditional ISVs, and where there are substantially less than 5%
  of workstations running a Linux desktop.
• or it evolves into a platform that conquers not only a few corners
  of the market, but a substantial chunk (say, at least 25%), and where
  each ISV ponders for each if its new products to offer a Linux version.

The fate of the Linux desktop is tightly coupled to how we can solve the fundamental problem highlighted by the example I gave above.


There are a lot of ISVs out there who already invested a lot of time, money and energy into going towards a platform independent direction. But they didn't go for Qt, despite its technological leadership. They did neither go for Gtk. Both, Qt and Gtk are a minority. The overwhelmingly big part of ISVs aiming for "platform independence" have embraced Java.
There is a whole big ecosystem of Java programs out there. There is the big community that has formed around the Eclipse framework and plugin system.


How can we make these programs first class citizens in our desktop environment?


Note, I do not mean that these programs should simply run. (That we already had with Acrobat Reader 4). What I mean is that they should, to the user, feel native, look native, behave native and fully utilize the native infrastructure of KDE. What I mean is that we should give an ISV who has years of Java development experience to develop a Java application that is a KDE program as soon as it runs on a KDE desktop.


Our current assets on this front are things like the QtGtk library and the Gtk-Qt Theme Engine. These are nice -- and certainly better than anything else there is for other desktops. But they are not enough.

Recently it came to my mind what the Ghostscript folks invented for themselves, already a few years ago. (Actually, the development was originally initiated by HP). And I wonder if this could be something of a model that could be used for the desktop as a whole.


Ghostscript previously has had all printer drivers compiled in. 200 or 300 different drivers (depending on your version of it) all statically linked in! Ghostscript is a beast... For every new printer model/driver to support it would require to be newly compiled.


The solution was to create a core Ghostscript and a plugin interface. The interface is able to ingest external driver plugins, which add functionality to the core Ghostscript. The thingie is called "IJS" (InkJet Server) -- but the "inkject" in its name has historical reasons. Ghostscript still supports older drivers (compiled in) -- but future work will more and more lean on utilizing external plugin drivers. IJS is more than a oneway pipe. It is a two way communication channel. It is a protocol. It is meant to remain stable and unchanged for many years. It is the new native way of executing modern printer drivers. But it is also meant to allow innovation, inside the Ghostscript core as well as outside of it, by whatever the printer driver developers may come up with, where the stable IJS interface accomodates both needs.


I am not a developer. I am not sure if what I imagine can become true. (One can dream, eh?) Someone with more knowledge will have to think hard about it. But tell me: why can't we create an intermediate layer for KDE that enables 3rd party software to run natively in our environment? We have "language bindings", which enable non-C++, non-Qt languages to create KDE applications. Why can't we have a "KDE Desktop binding"? Think of it as an analogon to the IJS interface of Ghostscript. The "KDE Desktop binding" would have to provide a well-defined, longterm-stable interface and protocol for ISVs to code towards. It this intermediate layer should in turn empower the application to gain as much native feel (not just look) as possible. And if we win the Gnome camp to support it via Freedesktop.org, it would guarantee that each and every application would run natively inside each desktop environment -- ISV products included.