How Competing Companies Are Jointly Building WebKit 125
New submitter jgb writes "WebKit is, now that Opera decided to join the project, in the core of three of the five major web browsers: Apple's Safari, Google's Chromium and Opera. Therefore, WebKit is also a melting pot for many corporate interests, since several competing companies (not only Google and Apple, but also Samsung, RIM, Nokia, Intel and many others) are finding ways of collaborating in the project. All of this makes fascinating the study of how they are contributing to the project. Some weeks ago, a study showed how they were submitting contributions to the code base. Now another one uncovers how they are reviewing those submitted contributions. As expected, most of the reviews during the whole life of the project were done by Apple, with Google as a close second. But things have changed dramatically during the last few years. In 2012, Google is a clear first, reviewing about twice as much (50%) as Apple (25%). RIM (7%) and Nokia (5%) are also relevant reviewers. Code review is very important in WebKit's development process, with reviewers acting as a sort of gatekeepers, deciding which changes make sense, and when they are conforming to the project practices and quality standards. In some sense, review activity reflects the responsibility each company is taking on how WebKit evolves. In some sense, the evolution over time for this activity by the different companies tells the history of how they have been shaping the project."
Re:Is there any reason (Score:5, Interesting)
Here's a pretty good discussion [arstechnica.com] of the issue.
Selfishly, I hope Mozilla never adopts WebKit because both the Gecko and WebKit teams tend to stagnate when nobody is out-classing them, but they both have strong competitive instincts and everybody benefits from that.
And, frankly, I think the aesthetics of Gecko are much nicer on Linux than Webkit. I use Chromium for Google Apps because I pretty much have to, but the text layout and rendering really has room for improvement. I do too much work in a browser all day to use that as a primary tool until the necessary work is completed on my platform.
Re:Why won't this paradigm work on an Office Suite (Score:4, Interesting)
*.DOC(X) is not just he most universally accepted format for word processing documents, it's the most universally EXPECTED format for word processing documents.
But I remember IE was in this exact position not many years ago. Heck, you could hardly "get anywhere" around the web without hitting so called "IE only" sites. What happened in this case?
... so long as it meets their interests (Score:5, Interesting)
I interned on the Chrome team 3 years ago. Google was still building up towards being a major player on Webkit. This lead to issues when Google's interests didn't match Apple's.
For example, there was a bug on a KURL object (held a url in it or something). According to specs, it was supposed to wipe out certain data whenever such and such an event occurred. I do not remember the specifics. But, Webkit had this bug where it did not do that, going against its own documentation and specs. This was causing Chrome some issues, so they wanted to patch the problem.
Apple refused to accept the patch- there were many places where Safari RELIED on the bug to work. If you wanted to fix the bug in Webkit, Apple would have to fix Safari. Since Apple had the majority of commiters/contributors, they could outvote any decision, open source be damned.
In the end, Google made a GURL object for their own purposes, which was essentially the same object, without the bug.
*Note: I may be mistaken on many of the details here, or the specific object names (it was a while ago), but the overall scope of the issue, I'm telling it to you like I remember it happening.
Monoculture (Score:4, Interesting)
Much as I like the idea of competitors working together I do have a slight concern that a security flaw found will be exploitable on many platforms. OK: more developers working to kill bugs, but this code is large and complicated.
It's not all wine and roses (Score:2, Interesting)
Webkit is riven with architectural compromises, technical debt, lousy infrastructure, competing corporate agendas, mistrust and factionalism that will probably destroy it sooner or later. This recent post on the Webkit dev mailing list [webkit.org] is illuminating. Eric Seidel is an almost-decade-long contributor to Webkit, both as an Apple and Google employee, and he has a laundry list of problems with the Webkit project. Perhaps most telling is that there is almost no trust between Google and Apple, with each having developed an "us" and "them" attitude, and also that there is essentially no management of the project's overall direction. Contributors just work on what they want, when they want, without telling anyone else, and the first and only way their supposed collaborators hear about it is by seeing changesets show up in the Webkit trunk.
Here's another Webkit dev post [webkit.org] by Google employee Adam Barth, regarding Apple's attempts to upstream its iOS Webkit port, which for the duration of iOS's existence has been Apple-internal. It's pretty illustrative of the level of discourse between Google and Apple on Webkit:
"A growing trend of unilateral action" does not seem like a healthy place for a collaborative project of this sort to be in. I get the impression that these kind of conflicts are become more common not less, as Google and Apple compete more strongly and openly, and their patience with each other runs out.
In fact, in some respects, Google and Apple already maintain their own forks of Webkit, albeit stored under the same source tree. How does that work? Well every feature that is implemented in Webkit nowadays is done behind what is called a feature flag. This means it can be turned on or off in a particular Webkit port at compile time. The set of features enabled by Google's Webkit ports (in Chrome and Android), differs wildly from those enabled in Apple's ports (in iOS and Safari), but basically can be summed up as, Google uses features developed by Google, and Apple uses features developed by Apple, with just occasional crossover. This means anything you read about "Webkit browsers" is meaningless, because one Webkit browser can be totally different from another in capability, even if it was compiled from the same source.
This situation, coupled with the apparent nightmare they have encountered trying to construct infrastructure to support building and testing Webkit, makes you suspect each will eventually conclude the diminishing benefits of shared labor are not worth the myriad headaches and loss of control, and go their separate ways. They'll maintain separate trees, with occasional cherry picking of features from each other, but also growing incompatibility as each pursues their own independent vision.
Re:Companies can work together just fine... (Score:4, Interesting)
http://donmelton.com/2013/01/10/safari-is-released-to-the-world/ [donmelton.com]
But back to Steve’s presentation.
Everyone was clapping that Apple embraced open source. Happy, happy, happy. And they were just certain what was coming next. Then Steve moved a new slide onto the screen. With only one word, “KHTML” — six-foot-high white letters on a blue background.
If you listen to that video I posted, notice that no one applauds here. Why? I’m guessing confusion and complete lack of recognition.
What you also can’t hear on the video is someone about 15 to 20 rows behind where we were sitting — obviously expecting the word “Gecko” up there — shout at what seemed like the top of his lungs:
“WHAT THE FUCK!?”
KHTML may have been a bigger surprise than Apple doing a browser at all. And that moment was glorious. We had punk’d the entire crowd.