Time to fork WebKit
My wish for this year is for Google to fork WebKit. They should take the WebKit code, give it a new name, and create a separate browser engine based on that. This, I argue, would be in both Google's own interest, and in the interest of the open Web. …
What's in it for Google?
By forking WebKit and creating their own separate engine, Google would gain full control of the core of their browser on all platforms. They would not be dependent on Apple's plans, strategies or roadmaps, and would be free to do whatever they please.
And as the rivalry between Google and Apple seems to be heating up, it might be a good idea for Google to become less dependent on Apple.
What's in it for the Web?
I know that "WebKit is not WebKit", but I argue, in the name of security, that fragmentation should not only be a coincidence, but actually a strategy. The fewer separate browser engines there are on the market, the fewer targets there are for malware authors, and the less money, time and resources malware authors have to spend to infest a large number of systems.
The more widely used browser engines there are on the market, the more expensive it will be to write malware which covers a large number of people. Google forking WebKit would create yet another moving target, making life even more frustrating to those who seek to exploit security flaws in browsers.
A boost to open standards
More (and more diverse) browser engines out there means that it becomes even more vital to support open standards properly. Open standards do not prevent innovation either. Browsers can build innovations on top of open Web standards, and I argue that we could see even more innovation with a proper foundation in place.
A more diverse browser market would also force more Web developers to adhere to standards because it would no longer pay off to optimize for just one or two browsers.
Buzzword alert: This would create a synergy effect where browsers would become increasingly standards-compliant, and Web sites would be written according to open Web standards to an increasing degree. Furthermore, it would be even more important for both browser vendors and Web developers to work together on open standards.
I can't think of a lot of reasons to not fork WebKit, but there are a couple of "but"s here.
One reason would be the inability to maintain the fork. For example, Nokia tried to build a browser based on WebKit, but they didn't quite seem to know what they were doing. The result seemed to be that they had to scrap their work and build their browser again from a more current WebKit codebase.
However, Google definitely has the resources, brainpower and manpower to maintain their own fork (which would eventually be a completely separate engine with little in common with "Apple's" WebKit).
Against the open-source philosophy?
The concept of open-source is often seen as collaboration, and there is a genuine value in sharing the work in many cases. Indeed, our own Web developer tool, Opera Dragonfly, is an open-source project.
However, forks already exists for other open-source products. Apple's WebKit was a fork of KHTML, for example. There's no reason why one cannot support open-source as a way to develop applications, and still accept forks. I believe that a WebKit by Google fork would create competition, and move the Web along faster than if everyone was using the same codebase.
Open-source does not mean that everyone has to have the same ideas and goals.
Just Do It
In conclusion, a forked WebKit engine from Google it is in the interest of both Google itself, and the Web as a whole. Not only would Google be in complete control of its own engine, but it would be a major blow to virus and malware authors, and it would give a much-needed boost to open Web standards.
There are very few reasons why this shouldn't happen, and none of these reasons seem very compelling.
So dear Google: Please fork WebKit!