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."
Companies can work together just fine... (Score:5, Insightful)
...just as long as you keep managers, marketeers, sales people and HR out of it.
Re: (Score:2, Insightful)
So who decided they weren't confident in opera's own engine and let's swap years of work out for webkit? Developers?
Re: (Score:3, Insightful)
So who decided they weren't confident in opera's own engine and let's swap years of work out for webkit? Developers?
I doubt it's so much a matter of confidence as it is a matter of outbreaking common sense. Why spend resources on your own engine when there is an open, fast, very popular, well-supported, and well-regarded engine available for free? I'm surprised they waited so long, though I am not surprised that Microsoft is outlasting them.
A small fraction of users care about what engine their browser is using. They care that the websites they visit work, and WebKit certainly has the edge over Opera's old engine o
Re:Companies can work together just fine... (Score:5, Insightful)
You don't think management was involved Apple's decision to use KHTML as the basis for Safari rather than Gecko (the Mozilla engine)? Or the decision to use an open source engine in the first place rather than creating their own proprietary engine? You don't think sales and marketing were involved in the decision to feature the open source nature of the engine when Safari was first announced [apple.com] ("Safari’s features include ... the industry’s best rendering engine based on KHTML, from KDE’s Konqueror open source project, to which Apple has made significant enhancements that will be contributed back to the open source community."). You don't think HR was involved in recruiting software engineers with experience working with open source projects?
The same is true of every other company that has used WebKit. Companies that base products on open source projects are not self-governing programmer utopias.
Re: (Score:2)
What was avoided here is the usual horde of slavering, shambling, mindless middle managers who usually bring every worthwhile software development effort to a pathetic halt.
Re:Companies can work together just fine... (Score:5, Informative)
Google did this first, they helped Firefox to really take off
No, Apple announced Safari in January of 2003, years before Google began seriously funding Mozilla through search referral kickbacks and hiring a few engineers to work part-time on Mozilla projects. Work on WebKit started within Apple even further back, in mid-2001.
Re: (Score:1)
Re: (Score:2)
It didn't get popular until long after Firefox got popular.
Re: (Score:2)
Re:Companies can work together just fine... (Score:5, Informative)
From the guy who chose to base Safari of KHTML [donmelton.com]: "But I chose the engine we used — with my team’s and my management chain’s support, of course —"
Sounds like an engineering-led decision to me.
Re: (Score:2)
Sounds like an engineering-led decision to me.
Engineering-led, sure, but that wasn't the claim I was responding to. The claim was "Companies can work together just fine... ...just as long as you keep managers, marketeers, sales people and HR out of it." Management was clearly involved.
Re: (Score:1)
Management was involved but did not decide. Don Melton decided to use KHTML [donmelton.com]:
That's not really involved though (Score:1)
Just letting someone do what they want is not "involvement". Involvement is stopping someone from doing what they want, or making a choice for them.
Mere support is not involvement.
Re: (Score:2)
Having embedded both Gecko (mozilla's rendering engine) and WebKit into various applications, it doesn't take any sort of silly thinking to understand why they picked WebKit.
Gecko is a fucking mess that no self respecting programmer will get with in half a billion miles of. It is a shining example of how to write shitty code. It is in fact the most bloated, buggy, confusing pile of shit I've ever had the dis-pleasure of working with.
WebKit is far from a trivial beast to work with, but its a HTML layout en
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.
Re: (Score:2)
...just as long as you keep people out of it.
FTFY
If what you said was true and there weren't any problems so long as it was just engineers, programmers, and the like on a project, then a number of forks of open source projects would simply not exist at all. The fact is, everyone fails to get along at some point, though I'll readily admit that some of the types you left off that list are more capable of getting along than some of the ones you put on that list..
Re: (Score:2)
Re: Companies can work together just fine... (Score:2)
Yeah a proprietary Web browser controlled by a convicted monopolist is just the same as an open source rendering engine that has multiple contributing companies, two of whom are bitter rivals.
Re: (Score:1)
As long as Mozilla and IE continue to be viable, I don't think your concern is valid with regard to the browser.
As for your other points, particularly the abominable choice of H.264 instead of a free codec for HTML5, you're spot on.
Re: (Score:2)
Why won't this paradigm work on an Office Suite? (Score:3)
Why won't this arrangement work on an Office Suite?
That's the question.
Re:Why won't this paradigm work on an Office Suite (Score:5, Insightful)
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.
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?
Re: (Score:1)
Microsoft upgraded IE and caused all those IE6 sites to not work properly in newer versions of the browser so the issue had to be addressed regardless of outside influence.
Microsoft killed IE6, not anyone else. It wasn't until Microsoft killed it that anything else changed.
Re: (Score:2)
Re: (Score:2)
Critical mass and a lack of companies that indirectly make money off it. The kernel is free but Red Hat makes money selling service and support, Webkit and the web browsers are free but Google makes money selling web services - or giving them away and making ad revenue, same thing. Who makes money off Open/LibreOffice? The StarOffice business model never really worked for Sun and Oracle simply killed it outright. The Linux distros a little bit maybe, but desktop Linux has never been a moneymaker. On Apple's
Re: (Score:2)
Re: (Score:2)
There is nothing stopping you sending ODF files to MS Office users, they can open them just fine with any version of Office from the past five years.
Re: (Score:2)
Prolblem is a lot of businesses and individuals are still on 2007.
Re: (Score:2)
2007 supports ODF. I should have said 6 years.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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 k
Re: (Score:2)
Re: (Score:2)
Every format is alterable. Every format.
I think you lack experience in this area. I personally work for a company which requires government interfacing and all of the strict standards and polocies associated. Yes, some archiving does require PDF/A. However there are other forms of data which are best stored in a more accessible format. Often times, the government requires both PDF and the original format simultaneously.
But what would be a likely reason for needing the original source document? Lots.
Re: (Score:2)
Re: (Score:2)
Re:Why won't this paradigm work on an Office Suite (Score:5, Funny)
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 .
Re:Why won't this paradigm work on an Office Suite (Score:5, Funny)
Re: (Score:2)
Mod up. This is really what we need - it would truly knock a big nail into MS Office's coffin.
Not that I'm against either MS Office or indeed MS per se. Apple is just as bad.
Goggle has progress to do; you can open a "pages" document in Google docs, but not then save it in another format.
For the love of Christ, how hard can it be?
I'm just so sick of trying to manage, and use, documents with needlessly opaque and complex formats.
It's a losing strategy, but still a powerful one, "I own your data, because I o
How about fixing memory management? (Score:1)
I'm not knowledgeable enough to understand the deep innards, but the first browser that doesn't slowly (or sometimes quickly) consume all my Mac's RAM will win my undying allegiance.
There's an extensive thread about this problem with Safari here: https://discussions.apple.com/thread/3255375?tstart=0
Some people have reported that disabling JavaScript fixes the problem, but that obviously isn't a realistic solution. But it leads me to suspect that in the race for bragging rights about having the "fastest Java
Re: (Score:3)
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.
Re: (Score:2)
But it leads me to suspect that in the race for bragging rights about having the "fastest JavaScript", developers have prioritized execution speed over memory efficiency. Personally I'd be happy with a slower JavaScript that paid attention to memory use.
You can get 16GB of RAM these days for less than $100. In a couple of years you'll probably be able to get 32GB for that amount. CPU speeds, OTOH, aren't going to get a whole lot faster (more cores notwithstanding). So I think there is a good case to be made that trading memory for CPU cycles is a good strategy in 2013 (along with parallelizing whenever possible).
Re: (Score:1)
You can get 16GB of RAM these days for less than $100.
But can I put 16 GB of ram into my mother board?
The limit is not how much memory I can afford.
The limit is the physical hardware. Or rather, The FIRST part of the limit is my physical hardware
The second part of the limit is even simpler: I don't run a single app as my whole machine.
I don't run a single app as my whole machine. My machine is multitasking.
Right now, what do I have running?
Gui:
Finder, Process monitor, Temperature monitor, Terminal (With 10 different windows on 7 different desktops), TextEdit
Embrace.. extend... (Score:1)
extinguish
Re: (Score:1)
Re: (Score:2)
Antitrust (Score:1)
When Microsoft dominated the browser market by abusing its market power in the operating system market, that was an antitrust problem. Should we not be concerned when a group of competitors collude to dominate the HTML rendering engine market? It's a different kind of market than the browser market, but it is still a market, and a dominant player will cause problems for both competitors and consumers. For example, even though the WebKit browsers are generally free, WebKit's dominance is steadily leading
Re: (Score:1)
No. Being a monopoly is perfectly legal, abusing the power is not. They are not abusing their power, and they are not even close to being a monopoly.
Opera were not forced except by the fact that writing an HTML renderer these days is hard, and they are a small company. By trying to keep up, they would have wasted effort that could better be used otherwise (everything around the renderer).
Basically, you have no idea what you are talking about and just throw around words that make you sound clever.
Re: (Score:2)
No. Being a monopoly is perfectly legal, abusing the power is not. They are not abusing their power, and they are not even close to being a monopoly.
There is much more to antitrust law than monopolies. For example, there are "contracts, combinations..., or conspiracies in restraint of trade or commerce" in violation of the Sherman Act. I did not suggest that WebKit was a monopoly. I suggested that competitors (such as Google and Apple) were colluding to dominate the HTML rendering engine market. That kind of concerted anticompetitive action is precisely what the Sherman Act is aimed at preventing.
I am not the first person to suggest that collaborati
Soon. (Score:1)
Soon. Microsoft.
... 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.
Re: (Score:2)
This is exactly why projects should be run by the community instead of a for-profit corporation. Such corporations simply have not learned to really work together for a common goal. In theory, it is impossible for them to do so, anyway, since, by definition, the only goal a for-profit corporation can have it to make a profitable return on the investment of its owners.
Re: (Score:2)
Right, because they exact same thing wouldn't happen with 'the community' in charge.
THERE ARE ALWAYS CONFLICTS, even in your fantasy hippie commune. Not everyone gets what they want in the real world.
Re: (Score:2)
I am pretty sure Google URL has many more intentional bugs. One of the interesting things about Google URL is that it is been designed based on Googles vast knowledge of URLs used on the internet, and has been designed with enough insane quirks to parse almost all of them.
Re: (Score:2)
And Apple were right. Merging in a patch that breaks Webkit is utterly wrong. If Google had been serious about the fix they would have patched the bug and also all the places in Webkit that they had then broken. Instead Google followed their usual route - a half-assed change that only works for them. Google is the new Microsoft: embrace, extend .... and soon extinguish.
You seem to have misread the parenter's description of the problem, and are possibly also confusing WebKit with Safari. He said there was a bug in WebKit which *Safari* relied on. Apple refused to fix the bug in Safari, and refused to accept Google's WebKit bug fixes. This, if true, is COMPLETELY a problem with Apple, not Google.
Re: (Score:2)
Does anyone know what happened to KHTML?
It is still the default in Konqueror although many users swap it out for Webkit. Kubuntu, probably the largest KDE distro, dropped Konqueror for a Webkit based alternative, so the KHTML fork of the code seems pretty close to dead from my perspective.
Re: (Score:2)
Stritcly[sic] speaking, WebKit is the fork. Credit where its due.
Strictly speaking, they're both forks of the same code. While some people use the term "fork" to try to indicate a spin off of a code base, that sort of connotation becomes really murky really fast. Is LibreOffice or OpenOffice the fork? It all depends upon your perspective. In truth, like forks in the road, when code diverges both divergent code bases are forks.
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.
Does it matter (Score:2)
a parallel view (Score:1)
Re:how a market can work together to achieve (Score:2)
Since the Slashdot tradition is to apply caution to news-spin, here's my reply to your fair post.
I certainly agree that if multiple companies can agree to work together on something like a rendering engine, they all share the cost savings. That's the easy part.
Right now the blend of players is interesting - with Opera folding its efforts on Presto, the player mix is becoming "Them", who all that ever entails, Microsoft, and Mozilla. I wish Opera well but I never saw them as a "shaker" in the scuttle of the
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:3)
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,
Re: (Score:1)
You're right. Sorry for the error.
Couple things to say on this... apk (Score:1)
1 point others have noted, in "monoculture" (bad in ways, since it has parallels in 'the real world', ala diseases being like a grenade (in the disease here), that can take out a "single group" genetically for instance, whereas that isn't as possible in genetically varied groups as easily because of their having adaptations from diff. environments steering them to be 'different' & in some ways, better (or worse, conversely)).
The other is my disappointment in a way, with Opera doing it... they have done
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 d
Re:Is there any reason (Score:4, Insightful)
The moment "everyone" goes to the same platform is the moment everything slows to a crawl or even a stop.
Re: (Score:3)
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.)
Re: (Score:2)
The moment "everyone" goes to the same platform is the moment everything slows to a crawl or even a stop.
I disagree. Monopoly, slows innovation to a halt, because there is no motivation to improve to gain share. Apple, Google, Opera, etc. still want to gain share from one another and they still need to advance Webkit to support those advancements in applications and services. The nature of copyleft prevents the normal monopoly issues (although patents can still introduce that problem).
Re: (Score:2)
Except WebKit isn't copyleft.
The core components are LGPL, which means if it is distributed contributions have to be submitted back. That's pretty copyleft in my book, in fact it is about the most copyleft license I know of that is practical for a library that the developers want to be widely used.
Re: (Score:2)
Webkit is just a layout engine. Network operations, rendering and script execution is all handled by the browser, which should also be sandboxing the layout engine anyway. A flaw in Webkit shouldn't cause a major problem in a well designed browser.
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: (Score:2)
Mozilla should fork Webkit, GPL it, then compete on that basis. More efficient all round. We will still have great competition and rapid evolution, what we won't have is the nasty hairball that is Gecko sandbagging Mozilla progress.
Re: (Score:3)
We could call it... KHTML [wikipedia.org] and make it a part of KDE!
However, to be fair, KHTML is actually LGPL.
Re: (Score:2)
and the lgpl-part is, why companies like apple can use it without opensourcing their browser.
Re: (Score:2)
and the lgpl-part is, why companies like apple can use it without opensourcing their browser.
And also, perhaps, the reason they use and improve the open source part.
Re: (Score:2)
I don't know. I don't find webkit much better than gecko as a user. I mean, seriously, if you remove all the "webkit-only" websites, I don't see anything faster in chrome than in firefox. Sometimes I bench webgl out of curiosity (mainly because the other pages are all instant on both browsers), and some webgl demos are 2fps faster on one or the other.
When I'm on Android, Firefox is actually noticeably faster than Chrome, for some reason (memory footprint maybe?).
Thus, I'm not sure what the gain would be wit
Re: (Score:2)
The sheer fact that you call Gecko a "nasty hairball" shows how objective and impartial you are, and just how seriously you ought to be taken.
The sheer fact that you do not understand that Gecko is a nasty hairball shows that you do not have the slightest clue about anything to do with software design, and nobody should take you seriously.
Re: (Score:2)
Proved my point. Mozilla foundation should GPL KHTML (call it MozML?) and restore MathML.
Re: (Score:2)
Not so fast - MathML's in WebKit already. [webkit.org]
Re: (Score:2)
I feel better now
Re: (Score:2)
Google just decided to remove MathML from Chrome 25 [maths-info...e-jeux.com], so much for "great competition and rapid evolution" for academic e-books.
Looks like it's going to be restored as part of WebKit [webkit.org] though.