WebCore - KHTML - Firefox: Know your facts!

Friday, 13 May 2005  |  Pipitas

There is a big ballyhoo on Slashdot and many other newssites regarding a "KDE <--> Apple divorce", as well as "Firefox scolding the KDE Team". Let me summarize what happened. The story starts in 2003:

  1. 2 years ago, Apple reveals to the KDE Team that they had been taking the KHTML code from KDE to build their own new browser, Safari, around it, and that they are nearly finished and about to release.
  2. Both sides are happy. (Note, that KHTML is under the LPGL license, and Apple is behaving perfectly legal in their further road to fork their own codebase named "WebCore" from KHTML -- and this is openly acknowledged by the KDE side ever since. It may have been less cooperation, support and "give back" than most of us had expected or hoped for at the time, but well....).
  3. On the Apple side about a dozen developers (and, how many managers and PR people?) start to work fulltime on their KHTML-based "WebCore" code (which, one should add, besides KHTML, also uses KJS, KDE's JavaScript engine), On the KDE side the KHTML/KJS developers (not one of them fulltime) continue to lift "their baby" to new heights, working in their spare time.
  4. It should be noted, that the core of the Apple-Safari browser team consisted of long-time developers with many years of experience in various prominent projects: some of them come from Gnome or companies like Eazel (yes, the one that once wanted to create a kick-ass innovative file manager for Gnome), some of them had even participated from the beginning of Mozilla/Netscape going Open Source.
  5. Apple acknowledges that their decision for KHTML was based on its very clean design, its easy to understand source code structure, on its HTML standard conformity and on its extremely fast rendering by being a lean and efficient code base. They say that they had compared to "Gecko", the Mozilla rendering engine, and still choosen KHTML, even despite of the fact that their workforce had previously been very familiar with Gecko.
  6. Apple/Safari/WebCore programmers create their own wrapper around KHTML (bear in mind two things here: first, they do not use Qt like KDE does; and second, Mac OS X's GUI is not based on X11, like KDE's is, but om their own proprietary Core Graphics engine....).
  7. In the following 2 years, KHTML developers even manage to backport many (but by way not all) Safari improvements from WebCore to KHTML, and they always appreciated the improvements coming from Apple and still do so.
  8. While Apple WebCore developers have KDE CVS accounts and full access to the KHTML codebase as well as the KDE bugzilla system, KHTML developers don't have access to the Apple internal source code versioning control system, nor to the Safari bug data base. Not even the willingness of individual KHTML developers to sign NDAs (non disclosure agreements) with Apple does help to pave the way towards their access to Apple's source repository or bug data base.
  9. KHTML developers receive all the code changes from Apple in rather large chunks, with many single "patches" put into one (sometimes MegaByte-sized) data blob. Many comments accompanying the large patch sets do not make sense to non-Apple people, because they say things like "fixes issue number 12345" (which is a reference to the internal Apple bug tracking system not accessible to KDE-ers.)
  10. This makes "backporting to KHTML" extremely difficult, technically speaking. Also, Safari/WebCore code quality (while "doing its job") does often not meet the KDE coding standard (in style as well as in quality) -- so many of the KHTML improvements are purposefully not taken from Apple, but implemented independently by the KDE side.
  11. A few weeks ago, Apple makes publicity, rightfully praising themselves being the first ones to pass the "Acid-2" test without errors, a test which measures the rendering of CSS (Cascading Style Sheets) and HTML code.
  12. Users and non-users of KDE start expressing their expectation of a quick update to KHTML so that Konqueror, the KDE web browser, also passes this test; Slashdot postings suggest that KHTML developers are too lazy and/or too stupid to take Apple's marvellous and easy to-digest-patches and merge them back into KHTML.
  13. A KHTML developer clarifies in his blog that this is not going to happen any time soon -- because of the de facto fork of WebCore from KHTML, which just doesn't give an easy path to integrate Apple's WebCore changes back into KHTML. He also does not hide the fact that he is pretty pissed off by clueless user comments which give all the credits to Apple but don't acknowledge the KHTML developers' work who mostly work for free in their spare time on KHTML.
  14. News sites start to pick up the blog entry and create stories about how KDE was in a quarrel with Apple; misguided users start to flame pro and contra Apple, pro and contra KDE, pro and contra Firefox and what not. This goes on for a few weeks.
  15. Apple is a bit concerned about the bad PR, and starts to contact KHTML developers about discussing how to improve the mutual relationship and ways of future cooperation. There is even a joint meeting in IRC where KHTML and Apple WebCore developers discuss how they could better exchange ideas and code.
  16. A leading Firefox developer blogs, very belatedly, about the topic, drawing his conclusions from one of the news stories (admittedly one of the saner ones), but not from the original blog entries. One of his conclusions in trying to teach KDE the right way ("This means you may have to cut corners in some areas in order to ship on time") is particularly well boded to provoke user comments like "Ah - that's why there was this flurry of security flaws in Firefox" and nurture further flaming of misguided users from both sides.
  17. New stories on various news sites appear, and many clueless people chime in with their bits of wisdom...
  18. KDE is still working to integrate the Gecko rendering engine into its future Konqueror browser (not as a replacement, but as a switchable alternative to KHTML), and explore the the integration of making other Mozilla technologies into the KDE platform, like started by KAXUL . KDE will not stop this effort because of an ambiguous blog entry from one Firefox/Gecko developer. KDE on the contrary, still aims to cooperate with the Mozilla Foundation to advance the cause of Free and Open Source software. Mozilla can still reckon on the feedback and patches for bug fixing and improvement for their Gecko engine from the KDE camp.
'