If you look at the commits, there's a fair argument that Google "controls" WebKit. You could almost say Apple got KHTML'ed ;)
I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achievement and really quite elegant if you've looked at the way they bolted it on, was bolted on all the same.
V8 without a doubt re-invigorated JavaScript. When V8 was announced there was a lot of "do we really need another JS engine" arguments. You could argue that other engines were getting fast as well, but v8 got people really thinking about JavaScript outside the browser. I am excited to see what new insights this new rendering engine brings -- and what unexpected positive consequences it generates.
If you want to really put a tinfoil cap on, you could say that by Google contributing to WebKit they are giving Apple a lot of free code, allowing them to devote fewer resources to their browser. Once Blink diverges father from WebKit it won't be practical for WebKit to merge in changes from there.
One has to wonder if Google will be recruiting other WebKit contributors (RIM, Intel, Nokia, etc) to move over to Blink. This would put Apple in a tough spot.
Blink remains very much open source: the repository should be visible in a minute or three.
We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features. I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.
Of course, I wasn't claiming otherwise, but over time porting code to WebKit from Blink will become more trouble than it's worth. They can still learn from it, but you can hardly deny that this move is going to cause WebKit some pain to fill in the tremendous amount of work you guys were doing (the part about this being the reason for the move was, of course, completely a joke.
The two engines will diverge, yes. I think it'll be better for both in the long run, as we simply have fundamentally different architectural approaches to some pretty core problems the engines are meant to solve. There will be short term adjustments on both sides as we get used to the new options that are now available.
I'm honestly quite hopeful, both about Blink, and about WebKit.
The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.
http://trac.webkit.org/wiki/WebKit2 outlines the technical differences between the architectures pretty well. Suffice it to say, the model runs deep, and has real impact on the way things like WebCore are put together.
>Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so.
If there is an engineering argument, I'm guessing it's to do with multi-threaded DOM+JS, given the mention of multi-process architecture.
Also, how much does Apple really control WebKit? At a glance, it looks to me like FOSS. (Apple might be the maintainer, but it seems trivial to fork it in a different direction.) Perhaps this is a more nebulous "thought leadership" kind of thing?
b) Although it is a little hand wavey, they do make an engineering argument: "However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects."
> Although it is a little hand wavey, they do make an engineering argument:
Immediately being able to eliminate and not worry about maintaining 7,000 files comprising 4.5 million LOC seems to be a pretty concrete benefit, rather than a hand-wavey one.
Chromium uses a different multi-process architecture ... and supporting multiple architectures over the years has led to increasing complexity ... we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines
Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. So I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. Perhaps an extra zero got inserted somewhere.
> Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code.
Mozilla isn't WebKit.
> I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines.
I suppose you could compare WebKit repos against Blink repos once the latter is live to see exactly what is cut, but I'm going to say the people working on the code that are the source of the count know how many LOC are involved, and that there direct count is more reliable than a third-party estimate based on a different browser's repo.
I think the implication is that most of the code they are removing is not actually code, but boilerplate/machine-generated build scripts/etc. Still, the number of LOC involved has little bearing on whether or not splitting from WebKit is a good idea.
4.5 million lines spread over 7,000 files is only ~642 lines per file, so I doubt there is an extra zero. Perhaps they included whitespace and comments in their count.
Of course the blog post doesn't go into technical detail. But if you would explore just a single link deeper you would see a pretty good explanation of the changes they're making. It's pretty obvious why they're doing it. It improves and greatly eases the amount of effort required to port/utilize Chromium/Blink not to mention the other benefits from the architecture that they indicate will enable better multithreading.
This blog post doesn't make an engineering based argument* so I'm left with the business ones. Which sucks.
* - Just vague "we need to innovate faster" boilerplate. Which is what business people say when there's not a solid engineering based reason.
EDIT:
At the bottom of the project page are some engineering reasons:
http://www.chromium.org/blink
Each person can judge whether it's worth forking or not.