What the Linux Desktop Needs -- or: Why an ISV shouldnt have to provide 16 different distro/version packages for his application

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 (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, 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):

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, it would guarantee that each and every application would run natively inside each desktop environment -- ISV products included.


The first question you ask; is why eclipse stuff can't work with KDE better. There are a lot of problems with the framework including the swt widgetset that it uses. It only works really well on Windows and moderately using gtk. There is a Qt version available, but thats illegal since swt and eclipse are licensed in a bsd-like license and therefor can't use the gpl version of Qt.

But you ask several questions here; a good second is how we can create a library that an ISV can program to and be guaranteed to work on all linux-boxes. Well; Qt is such a library, Gtk is another. Creating a layer on top of them is not a smart thing to do from a maintainance point of view. (though I'm sure there have been attempts already). With Qt and KDE already in place I don't really see what problem will be solved with such a solution in the first place. The current problem I hear about is that companies go for GTK since its cheaper to build on top of, only to find out halve way through that it would have been cheaper to use Qt instead, including paying the license. There need to be better total-cost-of-project papers out there for KDE versus Gnome. And not from open source projects either!

I've been doing Java for work for a long time; you can see the results from my work in a recent blog of mine.. Note that that screenshot is JavaSwing.
More importantly; it uses QtDesigner for most of its UIs and I wrote an application to parse the xml-based .ui file and spit out Java code. In fact it can spit out just about any code you want, so creating Java SWT code is an option, but spitting out Java code that uses the kdeJava-bindings is another, if only someone will program that :) See also this email on an option. Maybe thats something worth persuing?

Personally; I'm not even sure why LSB does not help the situation...

By Thomas Zander at Tue, 05/17/2005 - 10:12

There is a Qt version available, but thats illegal since swt and eclipse are licensed in a bsd-like license and therefor can’t use the gpl version of Qt.

BSD'ed software can link to GPL'ed software without problems, it's just that you'll still be restricted by the terms of the GPL. For Eclipse this creates a problem because they're essentially distributing a toolkit as well and they don't know in advance which applications will use that toolkit.

So, for example, if someone writes a proprietary application on Windows using Eclipse they can't move that over to UNIX using the Qt bindings because they don't own a Qt license.

For IBM that's obviously a show-stopper since they can't require everyone who wants to develop with Eclipse to buy a Qt license.

By Scott Wheeler at Tue, 05/17/2005 - 10:34

So, for example, if someone writes a proprietary application on Windows using Eclipse they can’t move that over to UNIX using the Qt bindings because they don’t own a Qt license.

Wow, never thought of it like that.

Is there not another option? Could IBM not pay for a couple of Qt development licenses and create a set of appropriately licensed Qt bindings for SWT that they could sell for a fee (well, they do do that but it's not well known), or even give them away for free? Might be a bit like the PyQt stuff. A lot of silly people who use free software think that Eclipse and SWT just fall off the nearest tree, but the fact is that IBM puts quite a bit of developer resource into maintaining SWT and Eclipse and it is by no means trivial. It's a 24x7 job, and a couple of Qt licenses pale into insignificance when compared to the resources currently required.

Using a reasonable toolkit and technology to bind against would be quite a bit better than what they've got now, and certainly the GTK/SWT port requires an awful lot of time, work, sweat and tears and it currently isn't really good enough for a full-time developer. The best desktop/toolkit citizen for SWT and Eclipse is currently Windows unfortunately.

Apparently, IBM are quite big on Qt internally and the Qt bindings are actually a part of Websphere/WSAD (their closed source products based on Eclipse).

By segedunum at Tue, 05/17/2005 - 15:14

if someone writes a proprietary application on Windows using Eclipse they can’t move that over to UNIX using the Qt bindings

They use SWT, how does it affect them which version the user has installed?

I think that the licence SWT is under contains something that makes it explicitly incompatible with GPL code, also GPL'ed application code.

By krake at Wed, 05/18/2005 - 19:35

Ok, here's the step by step:

- FooCorp develops Foomatic with Eclipse
- FooCorp releases Foomatic under a proprietary license
- John Userman downloads Foomatic
- John Userman is using the Qt bindings
- The Qt GPL license has been violated because it's now linked to a proprietary library and FooCorp isn't allowed to link their proprietary application to Qt without a commercial license

This isn't a made up case -- this is why the Qt version was never released.

By Scott Wheeler at Wed, 05/18/2005 - 20:01

Sorry, I am obviously missing something :-/

This means that the user violates the GPL because he runs a proprietary program against the GPL licenced SWT/Qt?

Does this imply that you have to have two libqt in memory once you run any non-free but dynamically linked Qt application because you need to have the included libqt/commerical loaded for it?

By krake at Wed, 05/18/2005 - 20:31

This means that the user violates the GPL because he runs a proprietary program against the GPL licenced SWT/Qt?

I suppose figuring out who was the violater could be tricky -- but it'd probably be IBM somehow. ;-)

Basically the infringing condition is what you mention.

Does this imply that you have to have two libqt in memory once you run any non-free but dynamically linked Qt application because you need to have the included libqt/commerical loaded for it?

No, because the Free Qt is dual licensed under the GPL and QPL and the QPL allows for licensees of the commercial Qt to link to the Free version.

By Scott Wheeler at Wed, 05/18/2005 - 22:40

I suppose figuring out who was the violater could be tricky

My understanding was that the CPL contained something that made it incompatible with the GPL and I think the FSF's licence list says something like that as well.

Because if it where compatible, someone could create a SWT/Qt, resulting in a GPLed implementation.
Maybe not IBM if they want to ship it with Eclipse, but pretty sure any third party.

Which makes the whole situation kind of sad, because usually toolkit licences allow usage in GPL code.

But as you mentioned the QPL, I wonder if the CPL is also incompatible to it as well.

Perhaps the IBM guys just "missed" that licence option deliberately.

(yes, I know that QPL is only an option for Free Qt/X11 but that is the platform without a single native widget API so SWT/Qt would only matter there)

By krake at Thu, 05/19/2005 - 09:38

There are a few problems here:

  • There already are attempts at producing toolkit abstractions; they're essentially toolkits in and of themselves. wxWidgets is the most prominant example.
  • For an ISV to develop towards that, were there a Qt backend (there presently isn't), they would still need a Qt development license, without most of the benefits of developing with Qt. That's a hard sell.
  • The packages issue is a tough one, but it's not one that the community can solve; it's one that will largely be resolved between the major Linux vendors, since their distributions are the ones that tend to be targeted by ISVs. Right now Linux vendors, notably Redhat, see their differences as a competitive advantage. If an American ISV is going to produce one package it's probably going to be tested and built for Redhat. That's a selling point for them. It's something of a watered down vendor lock-in.

In a nutshell there's no silver bullet here. Building packages is hard; there's nothing to motivate the non-commercial elements of the community to standardize and there's a reason for the largest Linux distributions to not want standardization.

Even the packaging systems themselves really aren't set up with ISVs in mind.

Looking at it I'd say it's a commercial opportunity waiting to happen -- a company that takes a source tree and handles the package generation for a certain set of Linux distributions.

In essence, this is a problem that ISVs have and it's a problem that ISVs will have to influence the solution on. ISVs are nice, but generally speaking the Linux community doesn't and won't fix their problems for them. When they want this sort of thing solved they have to step up and be part of the solution. In fact that is happening with major ISVs getting behind things like the LSB, Linux kernel development, etc.

By Scott Wheeler at Tue, 05/17/2005 - 12:35

Note: following hypothesis can be very weird for you, so be warned. :)

This may be funny, but a very special licensing terms can solve a few problems. Imagine entire KDE (and a few other) developer community agreed on following license addition (let's forget obvious problems with *GPL that can arise):

"Distribution of this software in binary form is permitted if and only if binaries were build using official source code delivered by KDE Team. Any changes and fixes made to the source code outside of the KDE Project (read: distribution makers) must not break official KDE's Binary Compatibility and Behaviour Tests. In a case when any of these requrements are not met, distributing binaries outside of an organization is not permitted."

Yeah, this is utopia, a modified flavour of "freedom as in... what?" Don't know. After years, we're dependent on Qt, other hundreds of other packages with solid licenses (except for BSD-like). And there's no single person/organization able to tell/ask/force you and me to go this way. For now, many of us are more and more annoyed by making use of "freedom to breaking compatibility", no matter if that's thoughtless "for fun" activity (read: free distributions like that) or to actions performed to differentiatiate from a competition (read: commercial distributions like that).

The question is: can we adopt a piece of such "Binary Compatibility and Behaviour Tests" in the future? You may ask "why? -- we still have incompatible C++ ABIs". Hmmm. This is entire industry's fault, not only FOSS.

What would be changed? Current state is that, e.g. Mandriva dev says "I want be a hot distro so I will include all unofficial tweaks here". SuSE dev: "me too, and I want to make the code faster, so I am gonna to tweak entire compilation process". The state after "the change": "Mandriva and SuSE: ah, we really can't drop KDE from our offer... so we need to comply... whit these requirements". But we have still Gentoo, with it's ecosystem incompatible with the new way...

Of course even if mentioned "tests" were delivered even in a small piece, what can be unlikely, we will need to wait another 2 or more years because existing distros' installations are not going to disappear.

We're not in 1995. So it's utopia. What do you think?

By Jarosław Staniek at Tue, 05/17/2005 - 18:23