> and it’s all managed at the pleasure of their bottom line.
As if Android’s come-one come-all is done out of benevolence. Google doesn’t have a heart, it had a bottom line too, and supporting those tools makes dollars come its way.
Google HAD an opportunity to ensure that one browser engine ruled the web—-but they chose to fork WebKit into Blink, in part _because_ they didn’t want to share the work they were doing. It propped up competitors. Google would rather have a competitive—-read, monetary—-advantage than ensure web technology is widely available for all to use.
For example, when Google refused to share the multi-process mode that differentiated Chrome from other browsers, it was a compelling enough security feature that Apple/WebKit reimplemented it independently so that everyone using WebKit could have it.
Google proceeded to cry crocodile tears, and then promptly forked the WebKit codebase into Blink. They claimed it was necessary to avoid having to carry around two multi-process models, but it was a A PROBLEM OF THEIR OWN MAKING.
So don’t imply Apple is profiteering, as if other companies are trying to give you hugs. Everybody’s finding cash in the ways that play to their strengths.
If Google was really interested in pushing the web forward, they’d swallow their pride, take the bottom line hit, and merge Blink back into WebKit.
> Google HAD an opportunity to ensure that one browser engine ruled the web—-but they chose to fork WebKit into Blink, in part _because_ they didn’t want to share the work they were doing.
Apple had the same choice when it forked KHTML to produce Webkit.
> but they chose to fork WebKit into Blink, in part _because_ they didn’t want to share the work they were doing
I believe that statement is false. As I understand it, from @tomalsky, Google simply had a different (superior) design for making WebKit multi-process, and Apple did NOT want to take those changes upstream into WebKit. So if Google wanted to use the better design, they had to fork.
Large parts of Chrome’s multi-process model were specific to Chrome, and not part into WebKit. Apple built “WebKit 2”, which integrated into WebKit at a higher level and allowed anyone using WebKit to get multi-process as a native part of the code base.
Three years later, Google forked Blink. According to this link:
“Specifically, [Google Engineering VP Alex] Komoroske noted, Chromium’s multi-process architecture is very different from the rest of WebKit (Chromium is the open-source project behind Chrome and Chrome OS). Having to integrate Google’s way of doing things with WebKit and what the rest of the WebKit partners were doing was “slowing everybody down,” Komoroske said.”
So, basically, Google built a version which was partially proprietary; Apple came in and built a completely open source version; and rather than standardize on a single code base, Google bailed, claiming it was too difficult to continue supporting two different multi-process models.
In the end, rather than collaborate, Google chose to keep their product proprietary and create a forked code base instead of doing the right, but admittedly difficult, thing and adopting the true open source option.
Google shipped their multi-process implementation years before Apple’s huge re-architecture of WebKit (which many forget now but lead to incredibly buggy behavior for years too).
They were able to ship earlier, and arguably at all, precisely because they just made separate processes that each had WebKit in them instead of doing a major change inside of WebKit. Had they tried to do the latter, the fork would have just happened sooner since everyone would have screamed that they were trying to completely change WebKit as complete newcomers: don’t forget, this was the major feature they shipped Chrome with. I’m personally happy that they set the standard that everyone then followed back in 2008 as opposed to having their initial foray into the browser space be some big RFC to change WebKit.
Having worked with it at the time, I was initially skeptical too. However, after working in the code, it definitely felt more natural to have the processes around WebKit instead of inside WebKit (as would be the case with most libraries). Ultimately, Apple’s approach took longer and lead to a big API-incompatible change (A “fork” level change arguably, but when it’s your own repo it’s not a fork, it’s just “2 point 0”). Not saying that’s bad, but Google's goal was to ship Chrome in 2008 and not have some huge incompatible diff with WebKit. Both made decisions appropriate to them, and in the end, gasp, we got two cool multi-process implementations, what a failure story for open source!
As if Android’s come-one come-all is done out of benevolence. Google doesn’t have a heart, it had a bottom line too, and supporting those tools makes dollars come its way.
Google HAD an opportunity to ensure that one browser engine ruled the web—-but they chose to fork WebKit into Blink, in part _because_ they didn’t want to share the work they were doing. It propped up competitors. Google would rather have a competitive—-read, monetary—-advantage than ensure web technology is widely available for all to use.
For example, when Google refused to share the multi-process mode that differentiated Chrome from other browsers, it was a compelling enough security feature that Apple/WebKit reimplemented it independently so that everyone using WebKit could have it.
Google proceeded to cry crocodile tears, and then promptly forked the WebKit codebase into Blink. They claimed it was necessary to avoid having to carry around two multi-process models, but it was a A PROBLEM OF THEIR OWN MAKING.
So don’t imply Apple is profiteering, as if other companies are trying to give you hugs. Everybody’s finding cash in the ways that play to their strengths.
If Google was really interested in pushing the web forward, they’d swallow their pride, take the bottom line hit, and merge Blink back into WebKit.