Seite 2: Wo bleibt der Linux-Desktop?

Inhaltsverzeichnis

Linux als Entwicklungsplattform

Soll Linux über die Randbereiche hinaus wachsen, sind also mehr Desktopanwendungen nötig. Für einen Windows-Programmierer sieht die Softwareentwicklung unter Linux allerdings alles andere als einladend aus: Er sieht sich einer endlosen Fülle von Programmiersprachen, GUI-Bibliotheken (Toolkits), Bibliotheken und Entwicklungsumgebungen gegenüber, die sich entweder auf dem Weg zur ersten stabilen Release, in ständiger Entwicklung oder bereits in der Totenstarre befinden. Hochintegrierte, stabile Lösungen zur Softwareentwicklung mit klarer, verlässlicher Roadmap gibt es nicht.

Um zu verstehen, warum es derzeit so unattraktiv ist, Anwendungen für den Linux-Desktop zu entwickeln, muss man noch genauer hinsehen. Die meisten Windows-Applikationen werden in C++, Java, Visual Basic und C# entwickelt. Wie sieht es hier mit Linux-Pendants aus?

C++ ist auch auf Linux weit verbreitet, und es ist durchaus möglich, Code zu schreiben, der sowohl auf Windows als auch auf Linux kompiliert. Allerdings reicht die Sprache alleine nicht aus: Für die Bedienoberfläche verwendet man unter Windows Toolkits wie die Microsoft Foundation Classes (MFC). Außerdem wird heftig Gebrauch vom Windows-API gemacht, also den Laufzeitbibliotheken von Windows. Beides gibt es unter Linux zwar mittels des Emulators Wine, der ist jedoch immer noch im Beta-Stadium.

Die Firma Trolltech bietet mit Qt eine Lösung an, die es ermöglicht, C++-Programme für Windows, Mac OS und Linux aus dem gleichen Quelltext zu erzeugen. Bestehende MFC-Programme müssen dazu jedoch umgeschrieben werden.

Java verspricht schon seit jeher, dass ein Programm, einmal geschrieben, überall läuft. So ist Java natürlich auch auf Linux verfügbar, hat bisher allerdings nur mäßige Verbreitung gefunden, da es nicht wie die anderen Programmiersprachen als Open-Source-Software entwickelt wird. Es gibt zwar erste freie Java-Implementierungen, die sind aber wohl dazu verdammt, auf immer der offiziellen Version von Sun hinterher hecheln zu müssen. Das völlig andersartige Look and Feel von Java-Programmen ist ein weiterer Grund für die geringe Verbreitung von Java-Desktopanwendungen.

Eine direkte Alternative zu Visual Basic gibt es unter Linux derzeit nicht, allerdings könnten die in bei Web-Applikationen bereits verbreiteten Skriptsprachen Perl, Python und Ruby diese Rolle übernmehmen. Für grafische Bedienoberflächen benötigen sie jedoch Bindings zu den gängigen Linux-Toolkits, und deren Qualität ist derzeit ganz klar das schwächste Glied in der Kette: Ihre Releases hinken den Toolkits meist weit hinterher, und sie erhöhen das Fehlerrisiko durch ihre nicht unerhebliche Komplexität. Erst Bindings von gleicher Qualität wie die Toolkits machen diese Sprachen für einen größeren Entwicklerkreis attraktiv.

Zu guter Letzt gibt es mit Mono auch eine .Net-Implementierung für Linux. Es leidet aber unter den gleichen Symptomen wie Wine und die Bindings der Skriptsprachen: Je nach Klasse implementiert Mono lediglich zwischen 60 und 100 Prozent der Funktionen von .Net 1.1. Zwar liegen die meisten Klassen deutlich über 90 Prozent, aber .Net 1.1 wurde inzwischen schon von der Version 2.0 abgelöst. Das Mono-Projekt konzentriert sich jedoch derzeit auf die Version 1.1. Der Abstand zwischen Microsoft und Mono wird also eher größer als kleiner.

Und auch die schon erwähnten Toolkits, die grundlegende GUI-Elemente und -Funktionen zur Verfügung stellen, machen die Sache nicht einfacher. Hier stehen die KDE/Qt-Bibliotheken, entwickelt von Trolltech und dem KDE-Projekt, und das Gnome/GTK+-Toolkit aus den Gnome-Projekt gegenüber. Auf welches Tooklkit soll ein Entwickler setzen?

Die beiden Desktop-Projekte stehen seit der Gründung von Gnome in Konkurrenz zu einander. Zwar kooperiert man immer wieder in einzelnen Bereichen, allerdings benutzt ein Großteil der Linux-Benutzer entweder den einen oder den anderen Desktop. Immerhin lassen sich KDE-Anwendungen unter Gnome ausführen und umgekehrt, vorausgesetzt, man hat die Laufzeitumgebungen beider Desktops installiert.

Widersprüchliche Strategien

Die Linux-Distributoren Red Hat und Novell haben sich in der Vergangenheit immer wieder widersprüchlich zum Linux-Desktop und der Bedeutung der beiden Desktop-Projekte geäußert, was dem Linux-Desktop wahrscheinlich mehr geschadet hat als die Konkurrenz zwischen KDE und Gnome. Für kommerzielle Softwareentwickler fehlt hier die klare Linie.

Das LSB-Projekt versucht zwar, standardisierte Interfaces für Softwareentwickler zu definieren. Für Desktop-Programme ist der standardisierte Umfang aber noch viel zu gering und hinkt zudem der aktuellen Entwicklung weit hinterher. Solange sich dies nicht grundlegend ändert, ist wohl kaum mit einer nennenswerten Zahl von kommerziellen Desktopapplikationen für Linux zu rechnen.

Sorgenkind Hardware

Ein weiteres Hindernis ist der mangelhafte Support der Hardwarehersteller. Auch hier schlägt natürlich wieder der Teufelskreis zu: ohne Markt keine Produktentwicklung, ohne Produkte kein Markt. Immerhin umgehen die Linux-Distributoren durch immer ausgeklügeltere Installationsprogramme die ablehnende Haltung der meisten PC-Hersteller gegenüber einer Linux-Vorinstallation. So ist Linux heutzutage einfacher zu installieren als Windows.

Wenn aber für eine Hardwarekomponente kein Linux-Treiber existiert, hilft auch der beste Installer nicht. Bei Desktop-PCs kann man durch sorgfältige Komponentenauswahl Ärger vermeiden, bei Laptops muss man sich jedoch damit abfinden, daß gewisse Funktionen wie Suspend-to-RAM, Softmodem oder 3D-Grafik nur eingschränkt oder gar nicht funktionieren. Und auch vor dem Kauf von Zusatzgeräten wie Scannern, Druckern, Webcams, TV-Karten und Bluetooth-Geräten ist eine Recherche Pflicht, sollen sie problemlos mit Linux spielen.

Softwarelösung statt Betriebssystem

Auf dem Server hat sich Linux mittlerweile einen festen Platz erkämpft, aber auch dorthin war der Weg nicht einfach. Die im Privatkundengeschäft bereits recht erfolgreich agierenden Distributoren mussten das Geschäft mit Businesskunden erst mühsam erlernen. Produktausrichtung, Verkaufs- und Supportkanäle mussten neu erarbeitet, der Umgang mit Unternehmenskunden erlernt werden.

Der größte Fehler war jedoch die zu starke Fokussierung auf das eigene Produkt. Unternehmenskunden wollen kein Betriebssystem, sondern eine Lösung -- häufig komplett mit Hardware, Betriebssystem und Anwendungen. Partnerschaften mit großen Anbietern wie Oracle, SAP, HP und IBM waren nötig zum Erfolg. Verkaufsstart, Support- und Marketingprogramme mußten aufeinander abgestimmt werden. So dienten die ersten Versionen der Enterprise-Produkte nur der Schaffung eines Ökosystems. Mit der zweiten und dritten Generation hatten die Distributoren jedoch den Dreh heraus und sind mittlerweile recht erfolgreich im Servermarkt aktiv.

Nach dieser Lektion hätte man eigentlich vermuten können, daß sie sich zur Erschließung des Desktop-Marktes frühzeitig um die nötigen Allianzen bemüht hätten, zumal im Desktop-Bereich sowohl die Hardware- als auch die Softwarevielfalt deutlich größer ist. Aber strategische Partnerschaften mit Hard- und Softwareherstellern im Desktopmarkt werden bisher kaum gepflegt.