Going upstream
We've put a huge amount of effort into not becoming a fork of WebKit; such a thing would be bad for all of the obvious reasons like duplicated effort, splitting the community, etc. But on the flip side it means that we need all of our modifications to WebKit to end up in the upstream WebKit tree (down to even the build system — otherwise we can't track when well-intentioned commits break our build).
The WebKit community (reasonably) greeted our release and its accompanying hundreds of forked files (primarily for multi-process, v8, and Windows) with some skepticism. The payoff for letting us land all this code in the WebKit tree (aside from helping prevent a fork) was the promise of more collaboration in the future — the patches Google funds on behalf of Chrome benefitting all WebKit-based browsers.
It's been a long and slow process, but these days, a year later, we've mostly unforked. Though there's always more to refactor and push upstream, our trunk pulls code directly from Apple's source repo when building Chrome — at a version typically lagging trunk by a day or so, though we have builders that track trunk too. I still question the wisdom of this a bit (sometimes it'd be nice to be able to make a quick hack in WebKit for the urgency of a release, something that is no longer available to us) but it's more a less a limitation of our source control tools that ends up with the societally-beneficial effect that it's often more work to not do things the Right Way.
The original hope of shared effort has also played out to some extent so far; off the top of my head, there's been work on making WebKit form rendering match IE better (important in east Asia where sites don't test against Firefox), rich text editing (important for all the rich text Google sites like Gmail, Pages, and soon Wave), the developer tools, and many other places like QA effort. Various members of our team spend more time on WebKit than Chrome these days — abarth, formerly our rockstar security intern, now is WebKit's rockstar security researcher. I have the impression that there are HTML5 features now coming out of Google (Web Sockets and App Cache, I think?) rather than Apple, but I don't follow it too closely.
Another unanticipated consequence of this unforking work has been that we've become the de-facto Windows port of WebKit. Apple did a Windows port for Safari, of course, but it relies on the whole proprietary Apple library stack so it's not usable by any third parties. (What libraries? We use a different 2d engine, the native font rendering system, our own network stack, etc.)
And since for sandboxing reasons our WebKit port was all about insulating the rendering from touching the containing OS, now you'll see the occasional project that wants to embed WebKit in a cross-platform manner end up embedding the Chrome port. I think this is good for WebKit's health in general — even if WebKit had 100% of the Mac marketshare it'd still be an under-10% marketshare engine without the help of a Windows port (and phones, of course).
We're still not yet to a place where you can just checkout WebKit and
build an independent libwebkit.so that exports a C++ interface. But
we're working on that, too, and there are a variety of projects (I can
think of at least three third-party
librarifications of the Chrome renderer) that will benefit from
it beyond just us.