Software::Kommunikation
Safari und KHTML driften auseinander
Der Quellcode von Apples Browser »Safari« und derjenige von KHTML haben sich so lange in verschiedene Richtungen entwickelt, daß sich am Horizont die endgültige Trennung abzeichnet - es sei denn, die Entwickler können ihre Differenzen überwinden.
Als Apple im Januar 2003 verkündete, KHTML, den HTML-Renderer von KDE als Grundlage für Safari zu nehmen, wurde dies von allen Seiten bejubelt. Doch es dauerte nicht lange, bis sich Ernüchterung einstellte. Es zeigte sich, daß die Ziele der KHTML-Entwickler von denen der Apple-Entwickler sehr verschieden waren. Zwar hatte sich Apple verpflichtet, die Lizenzbestimmungen von KHTML zu beachten und machte auch regelmäßig den Quellcode und Patches verfügbar, war aber, so die Ansicht einiger KHTML-Entwickler nicht sehr hilfreich beim Integrieren der Patches. Apple hatte von Anfang an seinen eigenen Zweig von KHTML und wegen der fehlenden Integration von Apples Patches wurden die beiden Zweige immer unterschiedlicher.
Teilweise liegt das Problem auch in den unterschiedlichen Vorgehensweisen und Zielen der Entwickler begründet. Während das ca. neun Personen starke KHTML-Team weitgehend unbezahlt daran arbeitet und Versionen freigibt, wenn sie fertig sind, hat das Apple-Team Termine einzuhalten und korrigiert Fehler notfalls auch in einer Art, die den KHTML-Leuten nicht sauber genug ist.
Es gab folglich auch Patches von Apple, die vom KHTML-Team nicht akzeptiert wurden. Das vergrößerte die Kluft zwischen den beiden Zweigen in einem Ausmaß, daß es inzwischen sehr schwierig werden dürfte, beide wieder zu vereinen. Oft enthalten die beiden Zweige Korrekturen für dieselben Probleme, die ganz unterschiedlich implementiert wurden.
Mehr und mehr kam es auch zu Verstimmungen zwischen den Entwicklern beider Lager. Apple hielt Fehlerberichte unter Verschluß, forderte die Unterzeichnung von NDAs für bestimmte Informationen und machte seine Testsuite nicht zugänglich, die offenbar teilweise proprietären Code enthält. Die Verstimmung erreichte ihren vorläufigen Höhepunkt mit der Forderung von Maciej Stachowiak, das KHTML-Projekt sollte seinen Code durch den von Apples Version, WebCore genannt, ersetzen. Da aber KHTML auch Code enthält, der in WebCore noch nicht zu finden ist, war das für die KHTML-Entwickler nicht akzeptabel. Eine Integration beider Quellcode-Bäume wäre, gleichgültig mit welchem man startet, mit sehr viel Aufwand verbunden.
Einige KHTML-Entwickler sehen inzwischen die Partnerschaft mit Apple als »bitteren Fehlschlag«. Apple habe dem Projekt mehr genommen als gegeben. Eine vollständige Trennung der Entwicklung beider Versionen liegt damit im Bereich des Möglichen. Eigentlich ist die Trennung bereits vollzogen, denn ein Austausch von Code findet fast nicht mehr statt.
Es ist allerdings noch nicht ausgeschlossen, daß sich die Entwickler noch einmal zusammenfinden. In einem offenen Brief schlägt KHTML-Entwickler Zack Rusin vor, daß die Entwickler eine längst überfällige Aussprache halten. Er sieht verschiedene Möglichkeiten, wie die Entwickler wieder zusammenkommen können, manche mehr, manche weniger realistisch. Noch ist offen, wie es weitergehen wird.
Die Zusammenarbeit zwischen freien Entwicklern und Firmen bei freien Projekten ist recht häufig, wobei es naturgemäß zu Interessenskonflikten kommen kann. Aus dem möglichen Scheitern der Kooperation zwischen KHTML und Safari darf aber nicht geschlossen werden, daß solche Kooperationen zum Scheitern verurteilt sind. Im Gegenteil sind die meisten sogar ziemlich erfolgreich. Apple selbst arbeitet reibungslos mit dem Darwin-Projekt zusammen.
