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:
Each person can judge whether it's worth forking or not.
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.
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.
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.
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.
1. Not affiliated with Apple or Google.
2. Not specifically associated with a port in terms of their review areas.
To me, that says a lot about how WebKit governance works in practice.
>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.
http://arstechnica.com/information-technology/2013/04/google...
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."
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.
How is that not engineering based?
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.
http://www.ohloh.net/p/mozilla claims that Mozilla is 11,614,049 lines of code.
Hmm. Not sure what to make of that, but the "we're removing 4.5 MLOC" claim still sounds ridiculous.