Friday, February 15, 2013

Why software monocultures are bad

If you do anything with web development, you are probably well aware that Opera recently announced that it was ditching its Presto layout engine and switching to Webkit. The reception of the blogosphere to this announcement has been decidedly mixed, but I am disheartened by the news for a very simple reason. The loss of one of the largest competitors in the mobile market risks entrenching a monoculture in web browsing.

Now, many people have attempted to argue against this risk by one of three arguments: that Webkit already is a monoculture on mobile browsing; that Webkit is open-source, so it can't be a "bad" monoculture; or that Webkit won't stagnant, so it can't be a "bad" monoculture. The first argument is rather specious, since it presumes that once a monoculture exists it is pointless to try to end it—walk through history, it's easier to cite examples that were broken than ones that weren't. The other two arguments are more dangerous, though, because they presume that a monoculture is bad only because of who is in charge of it, not because it is a monoculture.

The real reason why monocultures are bad are not because the people in control do bad things with it. It's because their implementations—particularly including their bugs—becomes the standards instead of the specifications themselves. And to be able to try to crack into that market, you have to be able to reverse engineer bugs. Reverse engineering bugs, even in open-source code, is far from trivial. Perhaps it's clearer to look at the problems of monoculture by case study.

In the web world, the most well-known monoculture is that of IE 6, which persisted as the sole major browser for about 4 years. One long-lasting ramification of IE is the necessity of all layout engines to support a document.all construct while pretending that they do not actually support it. This is a clear negative feature of monocultures: new things that get implemented become mandatory specifications, independent of the actual quality of their implementation. Now, some fanboys might proclaim that everything Microsoft does is inherently evil and that this is a bad example, but I will point out later known bad-behaviors of Webkit later.

What about open source monocultures? Perhaps the best example here is GCC, which was effectively the only important C compiler for Linux until about two years ago, when clang become self-hosting. This is probably the closest example I have to a mooted Webkit monoculture: a program that no one wants to write from scratch and that is maintained by necessity by a diverse group of contributors. So surely there are no aftereffects from compatibility problems for Clang, right? Well, to be able to compile code on Linux, Clang has to pretty much mimic GCC, down to command-line compatibility and implementing (almost) all of GCC's extensions to C. This also implies that you have to match various compiler intrinsics (such as those for atomic operations) exactly as GCC does: when GCC first implemented proper atomic operations for C++11, Clang was forced to change its syntax for intrinsic atomic operations to match as well.

The problem of implementations becoming the de facto standard becomes brutally clear when a radically different implementation is necessary and backwards compatibility cannot be sacrificed. IE 6's hasLayout bug is a good example here: Microsoft thought it easier to bundle an old version of the layout engine in their newest web browser to support old-compatibility webpages than to try to adaptively support it. It is much easier to justify sacking backwards compatibility in a vibrant polyculture: if a website works in only one layout engine when there are four major ones, then it is a good sign that the website is broken and needs to be fixed.

All of these may seem academic, theoretical objections, but I will point out that Webkit has already shown troubling signs that do not portend to it being a "good" monoculture. The decision to never retire old Webkit prefixes is nothing short of an arrogant practice, and clearly shows that backwards compatibility (even for nominally non-production features) will be difficult to sacrifice. The feature that became CSS gradients underwent cosmetic changes that made things easier for authors that wouldn't have happened in a monoculture layout engine world. Chrome explicitly went against the CSS specification (although they are trying to change it) in one feature with the rationale that is necessary for better scrolling performance in Webkit's architecture—which neither Gecko nor Presto seem to require. So a Webkit monoculture is not a good thing.

6 comments:

Anonymous said...

One of the better arguments I've read on the subject.

Anonymous said...

I am very sad to see Opera/Presto disappear, even though I mostly use Firefox now. I am going to cherish my current copy of Opera. I hate Webkit every time it crashes on my Kindle Paperwhite. What am I going to do now? Support IE10? Unfortunately it’s not available on my favorite OS. Anyway, that mediocre rendering engine that is Webkit needs to be stopped from becoming the next IE6!

ledahulevogyre said...

I am very sad to lose a brilliant engine, and I think monoculture can be bad. But not for the reason you write.

You give examples of polycultures with a dominant player. Not a real monoculture.

Would it be a real problem if backward compatibility is not sacrificed ?
If you fear that too much bugs become standard, prefixes are there to help. And it doesn't matter if some websites use the old buggy prefixed syntax forever.

I really think the only two problems are: stagnation and who controls it.

Anonymous said...

You've convinced me of why mono-culture (even in open source) is bad from a technical standpoint.

A question I'm getting is how can mono-culture be practically avoided? The nature competing software is that eventually one wins out over the other.

This is pretty much what the browser market look like now.
IE 50% : Firefox 30% : Chrome 20%

How monetizable is creating multiple implementations when user experience is about the same between each? Webkit only exists because Apple planed on making a iPhone at some point. Firefox was only funded because Google feared Microsoft could use IE against them.

If mono-culture is unavoidable I'd rather it be with multi-platform open source software.

Unknown said...

If open-source monoculture is "just as" bad, does that also color similar open-source "monocultures" like the hundreds of operating systems which use GNU/Linux as bad? They each implement their own flavors of Linux, many with features that focus upon specific hardware uses.

Or is it specifically bad for layout engines because of how layout engines interact with networks and file formats? Is there something unique about the function of open source layout engines that distinguishes them from other classes of open source software creations that make their diversity more of a necessity than a liability, a hobby or a nicety?

Finally, who pushes more, and benefits more, for web standards from diverse constituencies of browsers? Browser developers, web developers or corporations?

Thor said...

I'm not programing to comment about the web kit appliance, but I understand about to decode.

Good point, good, acknowlodge... I'm exercising both sides of my brain, right now. The one wich serves to each all.

Sometimes we need to rout ourselfs in another perspectives, but with nor losting our legends.