Comment by robocat
10 days ago
> Google forked WebKit
Yes - working code that everybody uses now including a major competitor - Microsoft. Where's the alternative timeline with a WebKit browser on Windows? Oh, Apple killed v5.1.7 Safari on Windows in 2010 - their choice. Windows Safari had its issues but it was a great browser when it was released. Virtually nobody has chosen to base their browser on WebKit - and they choose not to for good reasons. Similarly why nobody forked Gecko - they didn't want that code.
> without having to fork a whole browser (just drop WebKit into your app and go).
But Apple failed at that goal - saying that WebKit works better as an engine is just not what happened in reality. WebKit was certainly a worse choice for open source engine on Windows back when Windows really mattered. Nobody used it.
> likely to serve as a moat
That is just making shit up. If Google wanted a moat then they could have built a moat. History has shown that the multiprocess design of Chromium was no moat. You might argue there are other moats - and that is what the DOJ seems to be arguing.
Link to the reasons the Chromium team wrote: https://www.chromium.org/blink/developer-faq/
Edit: I guess I would also like to link to a great response to "you must be the product": https://danfrank.ca/most-businesses-dont-work-that-way/ and we should always refer to Spolsky's "comoditize your complement" https://gwern.net/complement
WebKit never took off on Windows, true, but saying that it was a failure is a stretch. It’s served Mac and iOS devs well in the past 22 years, both as a full-featured embeddable multiprocess webview and as the core of alternative browsers (OmniWeb in the past, Orion today).
The reason I believe that moving functionality out of the engine into the browser serves as a moat is because it gives Google more power to exert its will on Chromium forks.
If Blink were fully independent, third parties wouldn’t be beholden to forking Chrome; they could just drop Blink into their bespoke UI. Google’s decisions in Chrome would be entirely irrelevant to these third party devs. As things are now, forking Chrome is for practical purposes required if you want to use Blink, and diverging from mainline presents a risk — the more divergent forks become, the more effort and developers it takes to keep up with patches. Few organizations have the kind of manpower required to move at the Chrome team's pace while also maintaining their own large sets of patches.
This means that every decision in Chrome that forks disagree with adds more maintanence overhead, limiting the bulk of changes to those that are skin deep.
Google may not have intended this effect from the outset but it’s certainly realized the leverage it gives them in the time since.