A years-long marriage of convenience that linked Google and Apple browser technologies is ending in divorce.
In a move that Google says will technologically liberate both Chrome and Safari, the company has begun its own offshoot of the WebKit browser engine project called Blink. Initially it uses the same software code base that all WebKit-based browsers share, but over time it will diverge into a totally separate project, Google announced today.
The starting code base for what will become Chrome 28 is in place, and programmers are updating it. Blink’s birth was not without labor pains, though.
Yesterday, Google announced the project, which splits its browser work from Apple’s in the open-source WebKit project, and today, it’s up and running. The first updates — including a new list of 36 Blink “owners” who have authority to approve changes — are arriving.
“Chrome 28 will be the first blinking release,” said Chrome programmer Mike West in a Hacker News comment. The current stable version of Chrome is version 26; new versions arrive about every six weeks.
“The repository seems to be mostly up and working and commits are coming in,” added Eric Seidel, one of the Blink leaders, in a message on the new Blink-dev mailing list. The brain surgery Google has in mind will have to wait until things settle down, though. “Our focus this first week is to make sure everyone gets up and running smoothly.”
Chrome and its open-source foundation, Chromium, got a running start by drawing on the WebKit project that underlies Safari and that originally began with the KDE project’s KHTML engine.
Now Google evidently believes it’s time to fledge from the nest so that the company can make deep changes to the software — changes that would be prohibitively difficult to accomplish across the entire WebKit project. Several Googlers are exultant about their newfound browser-development freedom.
Google paid its respects to WebKit. In another message to the WebKit developer mailing list, Seidel expressed his gratitude and bid WebKit adieu.
“I’m writing to say thank you, personally, and on behalf of the Chromium project,” Seidel said. “Chromium could not have happened without WebKit and the help of its contributors.”
But not all parting was such sweet sorrow. Some of it had a more bitter taste, as one discussion about the divergent plans for rebuilding Chrome and Safari fundamentals showed.
In 2010, Apple began adopting technology called WebKit2 that better accommodated the need to split browser tasks into multiple independent processes. Google, though, adopted a different multiprocess approach with Chrome.
“Chrome’s multiprocess architecture is more mature than the WebKit2 design. I wish we hadn’t ended up in a position where we felt we had to make our own,” said Apple WebKit programmer Maciej Stachowiak in a comment. “But stay tuned — we have some great stuff coming up.”
In January, Apple asserted its control over WebKit2, announcing that only those on an owners list had authority to approve changes. Of the 18 people on the list, 16 are affiliated with Apple, according to the WebKit leadership roster, one is with Nokia, and one is with both Apple and Nokia.
Later, Stachowiak laid the blame for WebKit2 move at Google’s feet. He said:
The main reason we built a new multiprocess architecture is that Chromium’s multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.
Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.
At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever…
If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.
That raised the hackles of Justin Schuh, a Chrome programmer. “I don’t understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration,” Schuh said. “I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated.”
And, Schuh added, “Members of the Chrome team were also interested in helping better incorporate Chrome’s model into WebKit.”
Stachowiak disputed some of Schuh’s comments, for example saying Apple did indeed discuss WebKit2 with some Chrome team members before Apple wrote any code.
Perhaps, as Stachowiak suggested, history might have been different if the two teams had found a way to work together. But they didn’t.
Effectively, yesterday’s Blink fork formalized a break that in practice already was real.
“Chrome, Safari, and other [WebKit] ports have been diverging for years while still living in the same tent,” said Chrome programmer Alex Russell in a comment on his own blog post about Blink. “This has been enabled by pervasive use of build flags that allow ports to agree to disagree about the feature set we respectively ship to the Web.”
So Blink’s birth was not without labor pains. But born it is.
Credit: This article was previously puublished at cnet.com