Linux

Beim Lesen dieses Artikels sind mir mal wieder ein paar Dinge aufgefallen, angestoßen durch einige Aussagen, die im folgenden Text etwas näher betrachten möchte.

Im Grunde geht es in dem Thread darum, dass der integrierte MUA von KDE oft abstürzt. Daraufhin äußert “traurig’”, dass ihm das debuggen zu aufwändig wäre und stellt die Frage, warum Outlook denn so gut funktioniere:

Ehrlich gesagt, ist mir das zu viel Aufwand. Es kann nicht sein, dass das Programm schon bei simpelsten Sachen abstürzt. Bei keinem anderen Programm hatte ich das bisher… Wieso läuft denn Outlook einwandfrei?

Man sieht ganz gut, dass die Funktion eines MUA als simpel abgestempelt wird und beim “normalen” Benutzer keinerlei Wissen über die Komplexität und das Zusammenspiel mehrere Mail-Protokolle (SMTP/IMAP/POP3) sowie der GUI vorhanden ist – reine Feststellung meinerseits. Ein anderer Benutzer antwortet folgendermaßen:

Weil (hoffentlich) mit viel-viel-viel Geld Tester dafür bezahlt werden solche Programme stabil zu machen. – Outlook hat zusätzlich eine lange Geschichte und ist dementsprechend auch deshalb recht stabil. – Opensource gilt eigentlich als besonders stabil, da die Rückmeldungen und Fehlerberichte der Benutzer oft besser laufen als bei MS. Wenn es aber niemand meldet, ist MS sicher stabiler. Darum.

Nun, natürlich steckt in der Outlook-Entwicklung viel Geld und Arbeit. Interessant ist aber tatsächlich, dass die nachträgliche Versorgung mit Bugreports und Patches bei Open Source-Projekten viel besser und effizienter zu bewerkstelligen, ja sogar ein Zeichen von Qualität ist. Patcht Microsoft am ihrem Patchday 100 Lücken, sagt jeder: “Bäh, was ist das denn für eine Bananensoftware.” Gibt es an vier Tagen in Folge bei Linux-Distribution $xyz$ 25 Updates, denkt jedermann: “Gute Arbeit Jungs, so will ich das sehen.”

Weiter gehts:

nunja – 10Jahre Entwicklungsgeschichte KDE sollten eigentlich langen um stabile Software zu entwickeln !!

10 Jahre sollten reichen, wenn an einem einzigen Programm gearbeitet wird. Das Projekt KDE beinhaltet aber nicht nur einen MUA oder einen Browser, es ist eine ganze Arbeitsumgebung! Außerdem wurden in der erwähnten Zeitspanne 4 “Major Releases” veröffentlicht, KDE 1, 2 ,3 und 4 (nicht ganz, KDE 1.0 ist am 12. Juli 1998 erschienen). Was es in 10 Jahren für Veränderungen geben kann… auch in Firmen wie Microsoft. Da wechseln die Projektmanager, da streiten sich Entwickler, Entwickler verlassen das Projekt, das Qt-Framework, auf dem KDE basiert, wird aktualisiert… kein Anzeichen von Kontinuität.

Die Dynamik eines Open Source-Projekts ist auch eine ganz andere, es liegt viel mehr Wert auf dem Individuum und nicht auf den Anforderungsspezifikationen. Hat der Entwickler die Zeit und Lust, einen Bug zu beseitigen oder ein Feature hinzuzufügen, tut er das – sonst halt nicht. Wird es dem technisch versierten Benutzer zu bunt mit dem Entwickler-Team, wird der Entwicklungszweig geforkt und dort vielleicht in eine andere Richtung weiterentwickelt (um sich im Optimalfall am Ende wieder zu vereinigen, wie vor nicht allzu langer Zeit Compiz und Beryl wieder zu Compiz Fusion geworden sind). Letztendlich ist die Motivation das Entscheidende, wieviel Zeit steckt man in das Projekt, schreibt man die Software für sich selbst oder für einen großen Personenkreis?

Betrachtet man auch mal den Microsoft Desktop inklusive Internet Explorer, Outlook Express, Windows Explorer und den anderen Programmen drum herum, ist auch nicht viel von einer besonderen Innovationskraft zu sehen. Da wurde also sehr konservativ gewirtschaftet, wenig neue Features, dafür viel Wert auf Stabilität gelegt.

Hier werden also Äpfel mit Birnen verglichen, wie so oft in der Software-Welt. Erstens liegen ganz unterschiedliche Projektmodelle zugrunde, zweitens eine ganz andere Motivation. Aber das ist das Schöne und Flexible an Open Source – und Microsoft, Apple, IBM und viele andere Hersteller haben es begriffen. Wann begreift es die Community?

P.S.: Ich nutze lieber Gnome, weil es (subjektiv) stabil und schnell ist. Ab und an schau ich mal in KDE rein, aber auch ich habe die Erfahrung gemacht, dass in einigen Dingen noch nicht die rechte Reife steckt. Und mittlerweile benutze ich mein System lieber produktiv, statt Debugging zu betreiben und Workarounds anzubringen. Mea culpa