QotD: WebCore and KHTML
Posted May 13th, 2005 @ 08:23am by Erik J. Barzeski
Question: Who do you believe is in the right: Apple or the KHTML folks?
My Answer: Here's the nickel summary. Apple forked KHTML to create WebCore because KHTML relies on the KDE windowing/display environment. Apple has been supplying a ton of fixes and patches to WebCore (the fork), but the KDE/KHTML folks think that the patches should be easily applied to KHTML itself and that the documentation of those patches is weak. (Someone at) Apple suggested the KHTML folks move on to WebCore, and now the KHTML people are all up in arms. Sources: One and Two.
My take: the KHTML people should quit their yappin'. They're free to keep working on the original trunk, and Apple is abiding by all the rules and regulations of the open-source project. A fork is a fork. Deal with it, KHTML weenies.
You are encouraged to answer the Question of the Day for yourself in the comments or on your blog.
Donate Life
Posted 12 May 2005 at 8:38pm #
I think the problem lies with KDE. Apple doesn't appear to have these problems working with the GCC or the FreeBSD developers: Perhaps KDE's process lacks something that the others have, or ego's are getting in the way of real progress.
Posted 12 May 2005 at 8:57pm #
Leon:
I think they have fewer problems with gcc because
FreeBSD isn't an issue because Apple's involvement there has always been in one direction and it's expected.. the Darwin project doesn't even represent itself as a FreeBSD fork. (And it's not, really, as it's rooted in old NeXTStep code and has only recently had a lot of bits and pieces of FreeBSD added.) Also, the various BSDs (FreeBSD, NetBSD, OpenBSD) have always borrowed bits and pieces of code from each other, without going to any huge effort to backport their changes to each other.
With KHTML Apple should have made it clearer that they were forking the code (the had to make some big changes to it, as it runs on top of Cocoa rather than KDE) so that people wouldn't expect them to be working with a plain KHTML source tree. I think this was obvious to anyone paying attention (their initial announcement even talked about their KDE/Qt to Cocoa bridge code) but a lot of non-programmers didn't understand. The present conflict started because the KHTML developers were annoyed at the KHTML users for not understanding that it was non-trivial to port Apple's changes to KHTML.
Apple has certainly done everything required of it under the LGPL (all of their source code is available via CVS). I don't see why Apple should port all of their WebCore changes to the main KHTML tree. Apple does the work when it borrows from KHTML, the KHTML team should do the work when borrowing code from WebCore. And if it's too hard to borrow code from WebCore, then they don't have to. (But the problem here is that their own users are demanding that they do so.)
Posted 12 May 2005 at 8:59pm #
hmm, somehow part of that was missing. Must have been cutting/pasting something and forgot to paste, or something. 🙂
anyway, I think they reason they don't have problems with gcc is that they don't have to make many changes to gcc. whereas with webcore they obviously have to make lots of changes to the KHTML code, due to the differences between KDE and Cocoa.
Posted 13 May 2005 at 12:07am #
I don't really have any firsthand knowledge about the situation, but it sounds from your description (Erik) that if KHTML had a lot of dependencies on the KDE windowing/display environment, then it wasn't very well designed. The fork wouldn't have been necessary if KHTML were a more portable component, Apple could have just used it as-is and been contributing their patches to the source tree rather than to their forked version.
Posted 13 May 2005 at 12:55pm #
Tim: Actually Apple does have a number of issues with GCC. Some of the flamewars on the gcc mailing list about objective-c++ support have gotten to the point of being amusing (or disturbing, from a certain point of view). The reason, imo, they don't have as many problems is because they have a stated goal of wanting to be able to use the FSF release, even though that may never happen. As a result, they've gone to quite a bit of trouble to rewrite sections of their code (objc++ being an example) in ways that the FSF is willing to accept. This is what the webcore team is not doing (which is up to them, of course. No one is requiring them to help out).