Given that Webkit is an open-source project with contributors from many different companies and areas of the industry, I don't see how monopoly could divert too far in the direction of non-standardness.
Really, the concept of 'monoculture' doesn't really apply to browser renderers, because a rendering engine isn't a cultural artifact. It's a medium. It's designed to be totally neutral. The only reason that we're discussing the competing browser engines right now, and discussing them in terms of culture and creativity, is an artifact of their history, not their nature.
Part of the reason for avoiding a monoculture is that you've put all your eggs in one basket; everyone's risks are linked together. While this can be good when things are going well, it can be disastrous when something goes wrong. For instance, if there's a worm that takes advantage of a bug in WebKit, it may be able to hit every single WebKit based browser out there.
Now, this is somewhat mitigated by the fact the WebKit is only one component in a browser. Each of the platform ports has a lot of platform specific code. The networking layer is different, the UI components are different, and so on. It's also somewhat mitigated by the different operating systems, architectures, compilers, and so on that make it hard to write an exploit against something like a buffer overflow, because of the heterogenous environment.
On the other hand, software that is just a small component of a browser, like libpng or libjpeg, can be all that you need to exploit a system. Look at how many vulnerabilities are reported in libpng and libjpeg on a fairly regular basis. And WebKit comes with a JavaScript interpreter that runs untrusted code by default, which can make exploits much easier as they can run code on the client side to adapt to the local environment.
A monoculture can also stifle innovation, and harm the market for new browsers. If everyone just codes to the capabilities of WebKit, it's harder for Mozilla to introduce cool new features that inspire WebKit to copy them, because a lot fewer people will pay attention. This is less likely to be a problem, however, because of the much greater market share of Gecko on the desktop.
Now, the benefits of sharing all that code and work may outweigh the risks of the monoculture. It would be nice to see a few more companies going with a Gecko based engine, however, in order to reduce the monoculture a bit. Fennec is coming along, but doesn't run on much hardware yet.
Well, yes and no. It isn't that big a deal with Webkit because it does a good job at being standards compliant. But what if the mobile phone market was converging on the IE6 rendering engine?
Competition helps drive innovation, but right now WebKit has so much forward momentum, it's hard to say that standardizing on WebKit is a bad thing. WebKit is LGPL-licensed, so if it were ever to stagnate, there's nothing preventing anyone (even companies) from forking it for their own desires.
I'd much rather see a WebKit-driven force than a proprietary one.
edit: LGPL-licensed, not just BSD. Thanks buymorechuck.
Well as a whole you have to think of it as LGPL as that is the most restrictive license among the code. But there is a bunch of code that is under the BSD.
Somebody compared the features of all these mobile browsers and discovered that they're all based on something called "WebKit", but they all end up being quite different. e.g. One browser uses a fork of a two-year old version of WebKit while another uses a fork of a one-year old version.
Open source seems to do this, doesn't it? Once upon a time there were dozens of Unices, and now there's just Linux. (Which isn't even a proper Unix.) There's Mac OS X, but that seems to serve a different market than the traditional Unix (now Linux) market.
Is it bad that we all use the same implementation of printf and strlen? It's important that something as fundamental as HTML rendering becomes plumbing that we don't even notice.
