Nicht alles, was man liest, ist korrekt. Hier eine Zusammenfassung der Ereignisse. Die Sache fängt bereits 2003 an:
Vor zwei Jahren verrät Apple erstmals dem KHTML-Team, dass es den KHTML-Code aus KDE verwendet, um darauf einen neuen Browser für Mac OS X namens »Safari« aufzubauen, dass die Arbeit beinahe schon fertig sei und der Browser kurz vor der Release stünde.
Beide Seiten sind happy. (Bitte festhalten: KHTML steht unter der LPGL-Lizenz. Apple hat sich an die Bedingungen dieser Lizenz gehalten. Auch Apples Entscheidung, einen »Webcore« genannten Fork dieser Codebasis vorzunehmen, ist dadurch abgedeckt - und dies wurde von den KHTML-Entwicklern auch stets anerkannt. Die Kooperation mag in der Folgezeit weniger eng gewesen sein als von uns ursprünglich erhofft, aber was soll's...)
Auf Seiten Apples arbeiten seither rund ein Dutzend Entwickler (und wie viele Manager und PR/Marketing-Leute?) hauptamtlich am KHTML-basierten »Webcore«-Code. Auf der KDE-Seite bleiben die KHTML-Entwickler am Ball, allerdings weiter während ihrer Freizeit.
Bemerkenswert ist die Tatsache, dass die Kernmannschaft des Apple-Safari-Browserteams aus langjährigen Veteranen der IT-Branche besteht, die von Apple extra wegen Safari angeworben worden waren: einige kamen von Gnome und Firmen wie Eazel (ja, dieselbe, die sich einstmals das Ziel gesteckt hatte, einen innovativen Dateimanager für Gnome zu entwickeln), andere hatten mitgeholfen, aus dem alten Netscape den neuen Open Source-Browser Mozilla zu machen.
Apple begründet seine Entscheidung für KHTML mit dessen technischen Meriten: sauberes Design, eine leicht verständliche und übersichtliche Codebasis, HTML-Standardkonformität, extrem schnelles Rendern, schlank. Nach damaligen Aussagen fiel die Entscheidung für KHTML, obwohl die eigene Apple-Mannschaft mit der Codebasis von »Gecko« (der Mozilla-Engine) weitaus besser vertraut war - oder eben gerade deshalb.
Die Apple/Safari/Webcore-Programmiere erschaffen notgedrungen ihren eigenen Wrapper für KHTML (bitte nicht vergessen: für Mac OS X wird von Apple kein Qt verwendet, anders als für KDE; außerdem ist die Mac OS X-GUI nicht X11-basiert).
In den folgenden zwei Jahren gelingt es den KHTML-Entwicklern, viele (allerdings bei weitem nicht alle) Safari-Verbesserungen von Webcore nach KHTML zurückzuportieren, und sie haben die Arbeit von Safari-Leuten auch immer entsprechend gewürdigt.
Während Apples Webcore-Entwickler in KDE stets CVS-Zugang (und teilweise sogar eigene Accounts) haben, den aktuellen KHTML-Code stets in jeder Form einsehen oder in einzelne Patches zerlegen können und außerdem vollen Einblick in den KDE-Bugzilla erhalten, gilt dies umgekehrt nicht: die KHTML-Leute haben keinen Zugang zu dem Apple-internen Fehlerverfolgungssystem für Safari, und keinen Zugang zu den Apple-Sourcen für Webcore.
Die KHTML-Entwickler erhalten den Apple-Sourcecode praktisch nie in Form einzelner Patches, die leicht zu integrieren wäre, sondern praktisch immer nur als große Brocken, die mehrere Dutzend Änderungen zugleich beinhalten, manchmal gar nur als fertige Release, aus denen sie die verschiedenen Änderungen dann mühselig einzeln herauszuklauben haben. Begleit-Kommentare zu Code-Änderungen enthalten häufig lapidare Hinweise wie »berichtigt den Fehler 12345« (wo die Zahl eine Referenz auf das interne Bugtracking-System von Apple ist, das KDE-ler nicht einsehen dürfen).
Diese äußere Umstände machen aus rein technischer Sicht eine einfache Rückverschmelzung von Safari-Verbesserungen nach KHTML extrem schwierig oder gar unmöglich. Es macht nicht besonders viel Freude, aus einem Riesenwust von Änderungen jede einzelne herauszutrennen. Außerdem war den KHTML-Leuten die Safari/Webcore-Codequalität oftmals nicht sauber genug, obwohl sie nach außen hin oft ihren unmittelbaren Zweck erledigte. Viele Apple-Änderungen wurden folglich nicht direkt akzeptiert, sondern in KHTML von Grund auf neu implementiert.
Vor einigen Wochen gibt Apple eine Pressemitteilung heraus, in denen die Verfasser Safari zu Recht als den ersten Browser loben, der den »Acid-2«-Test bestand (Acid-2 ist eine Prüfung, die korrekte Renderung hinsichtlich HTML und CSS unter die Lupe nimmt).
Anwender von KDE (und auch solche, die es nicht nutzen) äußern daraufhin in verschiedenen Online-Foren die Hoffnung, dass es ein schnelles Update von KHTML gibt, so dass Konqueror diesen Test ebenfalls bestünde; einige Slashdot-Postings suggerieren, dass die KHTML-Entwickler wohl zu faul und/oder zu blöde seien, Apples wunderbar auf dem Präsentierteller gereichten Code richtig zu würdigen und zu nutzen, um ihn sogleich in KHTML zu übernehmen.
Ein KHTML-Entwickler stellt die Sachlage in seinem Weblog klar: ein einfaches Zurückmergen der Acid-2 Änderungen ist unmöglich und wird nicht passieren - nicht in unmittelbarer Zukunft. Er erklärt den de-Facto-Fork von WebCore weg von KHTML, die einfach keinen »Königsweg« für Apple-Änderungen zurück nach KHTML bietet. Er verhehlt auch nicht, dass ihn die unsachlichen und oftmals von keinerlei fachlicher Ahnung getrübten Ergüsse vieler Kommentatoren ankotzen, die hauptberufliche Apple-Ingenieure in den Himmel loben, aber die Arbeit der KHTML-Leute schlecht reden, die oftmals ihre ganze Freizeit in das Projekt stecken. Er stellt dabei ausdrücklich das Recht von Apple heraus, sich so zu verhalten, wie es der Fall ist, und dabei in Übereinstimmung mit der LPGL-Lizenz zu sein.
Einige News-Seiten im Internet greifen den Blog-Kommentar auf. Eine besonders krasse Story stellt die Äußerung als Angriff auf Apple dar und stilisiert das Ganze zu einer Auseinandersetzung »KDE gegen Apple« hoch; fehlgeleitete Anhänger beider Seiten verwickeln sich in diverse Flamewars - pro und kontra Apple, pro und kontra KDE, pro und kontra Firefox und was so alles dazugehört.
Apple-Manager machen sich ein bisschen Sorgen um die »schlechte Presse«, die sie erhalten (schließlich ist gerade auch »Tiger«-Releasezeit). Sie kontaktieren KHTML-Entwickler, um eine künftig bessere Zusammenarbeit zu besprechen, und Wege für eine bessere gegenseitige Beziehung zu finden. Es findet sogar ein gemeinsames IRC-Meeting statt, bei dem KHTML- und Apple-Webcore-Entwickler überlegen, wie sie trotz Fork ihre Ideen und Code gegenseitig besser nutzbar machen könnten.
Ein führender Firefox-Entwickler meint nun, ziemlich verspätet, sich ebenfalls zum Thema äußern zu müssen. In seinem eigenen Blog zieht er seine Schlussfolgerungen aus einer der Newsstories, aber nicht aus den Original-Blogs (die er wohl gar nicht gelesen hat). Eine seiner Schlussfolgerungen, in denen er KDE über den richtigen Weg zu belehren versucht (»Manchmal muss man Abkürzungen nehmen, um Software pünktlich ausliefern zu können«), ist besonders gut dafür geschaffen, Nahrung für einen neuen Flamewar zu geben, den sich irregeleitete Fans beider Seiten liefern, und die Begründung zu liefern für Kommentare wie »Aha - das ist also der Grund für die Vielzahl von Sicherheits-Schwachstellen in Firefox, die in den letzten Wochen ans Licht kamen...«.
Und die Presse springt natürlich wieder auf. Besserwisser und Wichtigtuer geben ihren Senf zum besten, und die Hits auf den entsprechenden Seiten nehmen wieder zu...
KDE arbeitet gleichwohl weiter daran, die Gecko-Rendering-Engine in den Konqueror-Browser der Zukunft zu integrieren (nicht als Ersatz, sondern als eine umschaltbare Alternative zu KHTML). KDE wird dieses Vorhaben nicht wegen eines vagen Blog-Eintrags eines Firefox/Gecko-Entwicklers aufgeben. KDE wird im Gegenteil weiterhin mit der Mozilla-Foundation daran arbeiten, dass gemeinsam die Sache der freien und Open Source-Software weiterkommt. Mozilla kann sich auch in Zukunft darauf verlassen, dass ihr aus dem KDE-Lager konstruktives Feedback und Patches für Bugfixes und Verbesserungen an der Gecko-Engine zukommen.
