Last week I wrote about the benefits of open standards versus open source. I argued that open standards provide greater protection against vendor lock-in than open source alone. I was reminded of this conclusion when reading Peter-Paul Koch’s analysis of WebKit implementations. Thanks to Palm’s Dion Almaer for pointing out the analysis.

Readers know WebKit as the open source web browser engine used by several mobile and PC web browsers including Apple’s Safari, Google’s Chrome, Palm’s WebOS and the Web Browser for Android. In fact, Wikipedia lists 19 browsers that are based on the open source WebKit browser engine. As you read on, keep in mind that there is no standard that vendors using WebKit must adhere to or claim certification against. A WebKit based browser is, well, whatever the vendor wants it to be.

When Koch tested WebKit browser versions on twenty seven tests, he found:

  • Out of 19 tested WebKits, no two are exactly the same.
  • The best WebKit available is Safari 4; the worst is S60v3.
  • The Android G1 and G2 WebKits score rather badly; it’s the worst mobile WebKit except for S60.
  • Regressions are fairly common: iPhone 3.1, Android G2, and S60v5 all (partially) dropped support for something their predecessors did support.
  • The closest relation of a desktop WebKit to a mobile WebKit is between Safari 3.0 and S60v5. I’m now fairly certain S60v5 is actually based on Safari 3.0. Unfortunately this is the single example of such a close relation.

Koch’s testing highlights two truths. First, pity the mobile web application developer whose manager or customer expects that the application will work on multiple mobile browsers that are “built on WebKit”. Second, open source does not make it easier for customers, or their developers, to transition applications from, for example, building for the Google Android platform to, for example, Plam WebOS.

Imagine if there were a WebKit standard and a compliance test suite that vendors had to certify against to use the “WebKit” brand. Customers and developers would gain protection against vendor lock-in that open standards deliver to a much higher degree than open source alone. I’m not naive enough to think that open standards equals “write once, run anywhere”. But even if a WebKit open standard could drive a 50% improvement in compatibility across WebKit-based browsers, that would be something to write home about.

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

Mike Dolan believes that we need an open API for the various App Stores that are or will be on the market soon.  He writes:

“I can’t help but think with Apple, Sun, Nokia and others with “AppStores” live and working or clones in the works, is it time to have 1 set of open, “AppStore” APIs?”

I couldn’t agree more, especially from the ISV point of view.

Most ISVs will wish to submit their applications to multiple stores.  For instance, an ISV with an application supporting Linux would want the product listed on the Novell, Red Hat and Ubuntu application stores.  Reducing duplicate, or worse, conflicting work, while packaging and submitting the application to these three stores would definitely be a good thing.

The App Store standard would be less about lock-in, since the ISV isn’t locked into any of the App Stores they’ve submitted their application to.  The standard would be about driving consistency, to varying degrees, across application packaging, submission, installation, update, etc. process.

Redmonk’s Stephen O’Grady has written about the need for an App Store for the Enterprise:

“I would love for Ubuntu, our server platform at RedMonk, to connect me back to qualified, rated community resources capable of working on the various packages available in the repository…To the extent that I would pay them for it.”

As enterprise platform vendors, at the operating system, middleware and application levels, begin to expand their App Store capabilities, the wrong path forward will be for each vendor to invest in building the store platform themselves.  The App Store isn’t going to be differentiating technology, so why invest in it individually?  A better approach is for one of these vendors to open source their existing store platform code, with the goal of building open standards based on that implementation.  Then the cost of maintaining and evolving the App Store platform code would be shared across multiple vendors.

What do you think?

Follow me on twitter at: SavioRodrigues