Webkit vs. KHTML or Webkit & KHTML?

The dominant reaction to the release of Webkit as open-source was that Apple was finally doing the right thing. Opening up the development of their fork to the original developers of KHTML. The KHTML developers complained about the way Apple was participating, Apple listened and responded.

I’m not so sure this is what actually happened. This isn’t about pleasing the KHTML developers. It isn’t about moving Webcore code back to KHTML and moving to a common platform. I believe that what happened is actually much more significant. Apple is essentially launching Webkit as a rival to Mozilla and KHTML.

Think of the benefits to Apple. Instead of having a limited number of developers on your payroll to work on this product, you can use the potential of a whole community. A community that already existed before this launch (efforts were underway to port Webcore to several other platforms), but thanks to this move this community will only grow in number, but also in talent. Although you cannot compare it directly, it is essentially the same move that Netscape made when they launched the Mozilla project. And just like Mozilla, I think Webkit will grow beyond being the engine for a single proprietary browser.

It’s a move that already is starting to pay off. The community around Webkit is growing steadily and the first patches are trickling in. Ironically these patches also include improved CSS3 selector support, merged from the KHTML.

A strong and open Webkit could be beneficial to KHTML, but perhaps it could also mean the end of KHTML. One thing is pretty clear, the goals of the projects are different. KHTML is taking a more purists standpoint, while Webcore is going for compatibility, even if that means implementing IE-only, non-standard features. This is, I believe, the main reason why Webcore and KHTML grew apart in the last couple of years and why it will continue to grow further apart in the next couple of years. It is the main reason why Webcore will always benefit more from KHTML than vice-versa. This has nothing to do with easy access to the Webcore source code.

In the end the end-users will decide which project will survive. If Webcore is ported back to KDE, it could gain quite a following because of the improved performance and compatibility. Perhaps the suggestion that KHTML should move to Webcore isn’t so strange after all.