Slashdot Mirror
How Competing Companies Are Jointly Building WebKit
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."
...just as long as you keep managers, marketeers, sales people and HR out of it.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Why won't this arrangement work on an Office Suite?
That's the question.
Critical mass.
*.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.
And then there's the ridiculously high amount of integration which is the expected norm for all of this. It's more than just office. It's everything it touches. And as we saw when Microsoft took an active role in attempting to stop ODF from becoming an ISO standard and we saw it in how Microsoft inexplicably got an incomplete and impossible to implement standard fast-tracked through the same process.
They have no shame or sense of morality when it comes to defending their territory and will never allow anything to get in their way.
Now, if there were such a collaboration I'd be all over it. Right now? I just can't see it happening.
The moment "everyone" goes to the same platform is the moment everything slows to a crawl or even a stop.
Here's a pretty good discussion 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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
*.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?
Why won't this arrangement work on an Office Suite?
That's the question.
The transformation of the office Paradigm will be disruptive and imperative in a cloud computing initiative and to leverage Web 3.0 and deliver a truly seamless Prosumer solution .
Tell your friends about xenu.net
We could call it... KHTML and make it a part of KDE!
However, to be fair, KHTML is actually LGPL.
We have never sought to become a monopoly. Our products are simply so good that no one feels the need to compete with us. -CEO Nwabudike Morgan, Alpha Centauri (Fictional quote, by the by.)
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.
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.
Aww, you were only missing "synergy" to win Bullshit Bingo.
systemd is Roko's Basilisk.
No, Chrome is the Google branded closed source version of Chromium, which is the open source browser tied to Chrome. ChromeOS is the OS.
As is traditional of tech companies, the names they chose are confusing and retarded to anyone who doesn't follow tech religiously.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
That is just the Safari Mac defaults. It is using up to 1Gbyte on JIT code, and even more on various caches, but it should throw it out when hit with a memory pressure event. The iOS defaults are much much smaller of course.
As noted, Chromium is the open-source browser project, Chrome is Google's branded version of that code (much as Netscape v6 and later and Mozilla were related).
The bigger error in the article is calling Opera one of the 5 major browsers. The summary then links to a page that isn't overall browser share, but is only non-mobile browser share. When you stop cherry-picking data, it becomes clear that:
a) There are only 4 major browsers; Firefox, Chrome, IE, and Safari all have about 10-30% of the market share, and nothing else has more than 5% share; and
b) The 5th largest browser is the Android stock browser. Opera is at best the 6th biggest browser, with 3.2% of the market.
rage, rage against the dying of the light
it is supposed to make a difference when government entities require that ISO standards are followed when possible and one exists for documents, that it should be used. So if/when government follows its own laws and policies, they would have to select software which utilizes an accepted ISO format. If Microsoft wasn't able to manipulate its way through, there would have been some really tough questions to answer.
And let's be clear on how important an issue this is. We're talking about government record keeping. We are talking about file formats wihich should be able to stand the test of time... 10 years, 50 years, 100 years from now if documents are to be accessed, which format do you think would be most accessible? A clean and clearly defined spec (ODF) or an XML formatted memory dump (OOXML)?
As for MS Office getting it right? Do you actually use MS Office? I more than use it, I support it so I get to identify and manage problems associated with its use. I encounter problems all the time... well not "all" the time, but often enough to keep me employed.
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 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 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.