Compatibility paradox: Can't we all just get along?

Sam writes: "Most of the advantages that World of Warcraft has over the web is its closed-platform nature." Indeed exercising full control over the system allows Blizzard to avoid all kinds of compatibility problems. The next platform should offer the best of both worlds—the deployment model of World of Warcraft and the open development model of Firefox.

The mission of both the World Wide Web Consortium and Mozilla Foundation is to promote the Web as a platform. Why are there two separate organizations then? Imagine if W3C from the start, in concert with developing the standard, supplied a production-level implementation of the HTML parser and rendering engine that could be easily and freely embedded in third party products. First, the lives of Web browser implementers would be easier—all they would have to do is take the standard code and add chrome. Second, the lives of Web developers would be easier—because the implementations are homogeneous and thus interoperable.

"One standard—multiple implementations" is an obsolete model in the software industry. A centralized open implementation is better in every respect: it is both faster to market and has fewer compatibility problems. The main drawback of the latter model is that commercial derivatives of the open implementation can't be exorbitantly priced, since the barrier to entry is much lower and the competition is greater. Is that really a drawback, though?

A single implementation is also more resistant to an "embrace, extend, and extinguish" strategy. Stricter licensing terms can be attached to source code than to a standard; they would legally prevent a malicious entity from corrupting the platform. An open implementation can be viewed essentially as a proprietary system owned by the user community. (I've used "open" instead of "open source" because I am not sure whether effective anti-corruption protection will be compatible with the open source definition. This is a minor point that I will try to resolve later.)

To complete the picture on a technical level, the system must first, support a transparent autoupdate at all levels, and second, be able to run multiple versions of the code—including core components—concurrently. The former is a polite way of saying "forced upgrades", and you can't get away from it. The latter gives components that are not forward compatible—because of bugs, for example—a way of requesting a specific environment and coexisting with newer instances of peer components.

There is an important argument against homogeneous implementations: security. A vulnerability in the standard implementation is a vulnerability in every installation. This is no worse, however, than a hole in a commercial implementation that has a near-monopoly on the market—and in fact it is much better, since "given enough eyeballs", it's likely that the bug is discovered by the community and promptly fixed via autoupdate. Pooling resources and cooperating on security, as well as on other aspects of design and development of the system, can lead to a better product for everyone.