I've written embedded browsers based on Gecko (ages ago), Chromium and WebKit. Gecko was a big pain (they were redoing graphics at the time, moving to "thebes/c

I've written embedded browsers based on Gecko (ages ago), Chromium and WebKit. Gecko was a big pain (they were redoing graphics at the time, moving to "thebes/cairo"). At some point the GNOME guys were complaining hard about not having a stable API to Gecko, and Mozilla said "we're not interested in that, we're doing Firefox". Really wish they hadn't taken that path. Chromium is going in a similar direction, they used to have a very clean "WebKit" implementation (the bit which every port does itself, sits on top of WebCore) but over the years they've added a lot of policy to it and now it's hard to do anything which uses Chromium WebKit that isn't "Chromium". And the code outside of WebKit is very very hard to disentangle (they did some work on that for Chrome on Android, breaking out "content" which is a minimal embeddable browser, but it's hard to do any work on "content" and I have no faith that they'd want to merge anything they're not directly using). Chrome for Android is closed source, too, so it's not like they have any real commitment to OSS at all (and I think this hobbles Android as a platform -- maybe it's just a reaction to the Kindle Fire, but the Android team do still seem to be working on WebView as well). WebKit recently (2010?) started on WebKit2, which is a peer to Chromium's WebKit and is very straightforward to hack. WebKit2 supports multiple platforms and the WebKit project accepts contributions that aren't used by Apple, etc. So I would say that if there's a big hole that Mozilla drove into, then Google Chrome is diligently driving into it too. WebKit is on good track, though, and benefits from a lot of the Google contributions (though V8 WebCore integration is a point of contention).