Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Safari and KHTML

This does not surprise me in the slightest.

I have been subscribed to the KHTML development mailing list for several years now, and every time a new public WebCore is released, Apple sends along a changelog and a tarball, and that's about it. The first time it happened, the KHTML guys were overjoyed to be getting patches and spent a great deal of effort and time in getting a lot of the changes backported and getting the diff size down, but the second and 3rd times....well, getting help in the form of a shotgun to the head gets old pretty quickly.

This isn't to say that Apple hasn't gotten better. The Apple WebCore guys are now significantly more active on the lists than before, and large changes tend to get discussed more in the open, but huge diffs continue to land and the patch backlog is ever-increasing. I don't think the state of affairs is tenable, and Apple (since they're the offending party here) has two choices as I see it:

  1. suck it up and decide to live on KDE HEAD and submit patches for review like everyone else
  2. fork


I'm mildly in favor of the first, since the second is essentially where Safari is at now, and it's not working. Either way, I think both sides should drop the charade. If Apple is going to do Open Source the right way (which is how they do so many other things), then they need to participate as first-class citizens and drop their private branch for non Apple-specific features.