Stick A Fork In That Browser-Breakup Story, It’s Done
On Wednesday, Google announced it would change a part of its Chrome browser that users never touch directly, with differences that might take months or years to surface. The result was predictable: stories about Google’s “divorce” from Apple, underscored in some quarters with the claim that this is really Google sticking a shiv into Apple’s back.
Using the breakup metaphor to describe Google taking the Apple-led open-source WebKit code and using it to write its own Blink browser engine (also open-source) is tempting. But leaning too hard on it, or outright reading this switch as one company trying to sandbag another, may only show our continued fondness for soap-operatic analysis of the tech industry.
First, “forking”: It’s a normal, no-permission-required part of open-source development. Forking well-running code isn’t always advisable but sometimes is unavoidable: When developers of the OpenOffice.org productivity suite got fed up with Oracle’s stewardship of the project, they split the code into LibreOffice, and that effort has now taken a clear lead.
WebKit itself started life as a private fork of an older engine called KHTML (Apple contributed back its improvements after announcing the release of Safari in 2003). Google says it’s branching Blink off of WebKit to give itself room to write faster, cleaner, and more secure code; these improvements may be especially noticeable in mobile, and in the bargain Chrome’s development cycle should accelerate.
Google says Chrome’s openness won’t change. You may not feel inclined to trust it–why would you, when it’s only been weeks since the surprising, dismaying news of Google Reader’s impending demise?
But Google isn’t a monolithic entity, and the history of Chrome offshoots deserves consideration on its own. And with Blink using the same open-source licenses of WebKit, there should be no barrier to somebody else forking this code too.
The Blink fork matters more for how it should push back the threat of a Web monoculture–something I wrung my hands over two months ago here. A diversity of Web rendering engines (that is, the internal parts of a browser that draw pages on your screen) reduces the incentive of Web authors to support the majority platform and ignore others. For instance, Time’s Harry McCracken noted an intriguing possibility: Google’s move might make it easier for Firefox, which announced a new rendering-engine project with Samsung, to claw back some of Chrome’s smartphone market share.
And it can strengthen the Web’s collective security–see a 2010 Opera blog post pleading for Google to fork WebKit.
This change may inflict some extra work for Web authors, but there are already enough differences in WebKit implementations to require checking sites for compatibility in different browsers. As one Chrome developer opined: “If you test in Chrome but not Safari, you’re doing it wrong.”
Even if you suspect Google’s underlying goal is to subvert Web interoperability to hinder Apple’s products, an open-source project–in which the underlying code is open to everybody’s scrutiny and, if desired, forking–is one of the clumsier ways to go about that. Instead, make sure that Google’s own sites don’t lock out competing browsers. Watch out for changes to how third-party apps can connect to Google’s services–for instance, its puzzling switcheroo, since walked back a bit, about calendar-sync support.
And please remember to hold Apple, Microsoft and other major Web players to those standards too. It takes more than one company to play this game.