Optimism Generally Doesn't Triumph

Open Gardens has an interesting post looking at the reasons behind the fragmentation of the J2ME platform. I think they're dead right on most of those reasons, but I cannot buy in to the suggestions offered for what Mobile AJAX must do to succeed.
The argument runs: Java has forced a centralised approach to API definition which is driven by expert groups with competing interests, leading to slow API deployment with rigid specifications that cannot easily adapt to the changing needs of the market. This drives fragmentation through patchy API support and inconsitent implementation, despite the thousands of conformance tests. Therefore, the argument continues, the only solution to prevent fragmentation is to let every vendor define their own APIs, adapt them over time as they see fit, and then write custom wrappers to abstract all this magically away.
Is it me, or is this completely backwards? Supporting evidence for this approach seems to be the success it has had with the handful of desktop browsers and other technologies like WSDL - technologies running on open systems where the execution environment is given full underlying API access by the OS, where space and bandwidth are rarely an issue, and where redeploys are relatively simple. Decentralised systems can of course work in this context, where adding an API to expose an OS service is easy and wrapping a handful of APIs with similar functionality is also simple - it just takes a few extra clock cycles and kilobytes.

Mobile devices do not fit this model for a number of reasons:

• Rarely do phones run on open OSs with readily accessible APIs for underlying phone functionality (though proponents of mobile AJAX seem to be focus on the smartphone sector which probably accounts for a very large percentage of their handsets but a tiny percentage of handsets in the hands of ordinary users).
• There are many more phone variants (1737 currently on GSM Arena) than desktop browsers (maybe 3, 4, 5 in popular use?) and WSDL execution environments, and once released they cannot easily be updated and extended.
• Bandwidth is expensive, memory is limited and clock cycles have a large battery penalty - all factors which are reducing in importance but will still be relevant for many years.

This boils down to a single fact: on the desktop or a server, a user will buy one piece of hardware which will go through many software revisions (browser, OS and everything in between) before it is discarded - development is geared for this. With handsets we have a hardware market with very rapid turnover: software is written for a handset, deployed, and then immediately development is redirected to the next version for the next handset. We rarely have multiple firmware updates for a device, outside the Windows Mobile and Symbian worlds where bugs are considered de rigeur. the six major firmware revisions for the SE T610 are of course an exception, that's what happens if your OS team just kept getting it wrong...).

APIs defined ad hoc by different manufacturers will therefore have all the problems associated with the bad old MIDP1 days, and we'll still apparently have to write common wrappers which our users will have to pay to download every time they hit our mobile AJAX pages (not to mention the wait). We will not have a rapid spreading of fulyl featured APIs because once a phone is released, it will be locked in time - new phones may have more advanced versions of the APIs, but this will drive further fragmentation rather than ushering in some panacea of ubiquitous functionality.

Fortunately, the article ends on a positive (for me) note: this approach will allegedly not happen until the operators grasp the opportunity and run with it, as they are the only parties with enough clout across all the vendors. This would require the operators to 1) realise there was an opportunity before it hit them in the face, 2) act together to achieve something useful, and 3) push a decentralised approach where they are actually ceding control to the market and 3rd parties. I confidently expect them to do this, and furthermore to deliver the press release announcing it whilst ice skating in hell towed by a large team of flying pigs during the next month in which every day is a Sunday.