Without specifically calling any particular journalist out (is he too chicken? why not a link to prove his point?), eWeek columnist Guy Kewney is taking to task any journalist who has claimed that PalmSource's lukewarm support of Java is the PalmOS licensor's leading ailment. Said Kewney in this week's column:
Some have argued that Java was the right alternative to Garnet. This is a little like suggesting that a fleet of a thousand 50cc moped bikes is a sensible cargo-shifting alternative to a 60-ton truck.
Garnet was the old PalmOS. It was replaced by Cobalt (the new PalmOS). I'm not sure who the "some" are. I wrote an e-mail to Kewney to find out who he was referring to but haven't heard back. I Googled "Palm Java" to see if there was anyone but me saying this. If you do it too, you will get 2.76 million results. I looked at all of them this morning between my first and second cup of coffee. I found a lot of people asking about Java development on Palm and plenty of banter about the various decisions (PalmOne, PalmSource, etc.) to support Java (invariably via a partnership with IBM). But as far as I know, I'm the only one that has singled out this issue as the most important linchpin to PalmSource's future (or lack thereof). Not that there aren't others. But computer industry's version of "it takes a village" is "it takes an ecosystem."
For close to four years, I've argued that the PalmOS must become more of a pure Java environment in order for the platform and the company to truly endure. And by pure Java, I mean a wholesale swap: Leaving the look and feel of the built-in applications in place as best as possible, but completely rewriting them in Java and giving the 400,000 or so existing PalmOS developers (claimed by PalmSource) whatever help they need to migrate their software. I first suggested the idea in December 2001, then hinted at it in January 2002, mentioned it in July 2002, said it in October 2002, pressed PalmSource CEO David Nagel about it in July 2003, said it again later that month, discussed the bigger Java picture in June 2004, said it again in August 2004, then again in September 2004, responded to PalmSource VP of product marketing Charlie Tritschler about it in October 2004, reminded everyone of it again in November 2004, then again and again in December 2004, and finally, again, earlier this week).
According to Kewney, the real reason for PalmSource's woes is that the old Palm, in all its glory, became such a fat cat that it couldn't move fast enough to keep up with the Joneses, much less keep its licensees up with the Joneses. 3Com let it whither on the vine. Evidence Exhibit A is the way PalmOne continues to include the the old Garnet OS (which is unable to multitask real-time communications) in its newest Treos. Kewney pins PalmSource's decline on the "It's not dead yet Jim" donkey. PalmSource is apparently haunted by Garnet's legacy.
The OS version mish-mash is clearly a problem and always has been. So too is the fact that the company stuck too hard and fast to the simplicity ethos that put Palm on the map in the first place. The first Palm Pilot did only a few things but did them extraordinarily well. The designers accepted the limitations of the handheld environment and never came close to exceeding them. But when the limitations changed, the PalmOS deliberately did not. Palm truly believed that simplicity would continue to prevail over other, obviously overly ambitious projects (destined to repeat the mistakes of others) like Microsoft's PocketPC. Back in April of 2001, the company's chief competitive officer Michael Mace told me that the Pocket PC is too big, too complex, and requires too many pit stops at the recharging station to be appreciated by anybody but the techno-elite who are typically willing to make such sacrifices to own a pocket rocket. "Handheld technology is immune to Moore's Law," he says. "The situation is not about to improve for Pocket PC any time soon."
Indeed, the newer better PalmOS (Cobalt) that acknowledges a change in the limitations (or Moore's Law) may have been too long in coming. Had it been here three years ago and battle-tested by now, maybe there would be more of the more capable devices in the market today. More than zero that is. You see, it's not just that the new Treo doesn't have the Feb 2004-born Cobalt (also aka PalmOS 6.0). It's that almost 18 months after it was announced, no shipping devices have it (at least not according to the lists of supported smartphones and handhelds on PalmSource's Web site). In the interim, Cobalt and PalmSource's time-lines have not been that impressive.
Better than half a year passed (and well before any devices have shipped), and the company released version 6.1 of the OS (see the review), a version specifically optimized for smartphones. Days later, PalmSource announced a more mobile-capable Web browser for Cobalt. With no devices under Cobalt's belt, doubts were cast upon PalmSource's ability to deliver when news surfaced that PalmOne (the hardware guys) was pondering its Linux and Microsoft options. Doubt about Cobalt's roadmap was exacerbated when, in December 2004, PalmSource announced the acquisition of China Mobilesoft with the intent of building a Linux-based version of the PalmOS. A full year after Cobalt first shipped, a smartphone reference design (based on 6.1) was finally released. But, then, the April 2005 headline First Palm 'Cobalt Smartphone Reportedly in Works, well into year two of Cobalt's life, isn't exactly an encouraging sign of the operating system's adoption rate.
When you review history, you may not help but come to the same conclusion that Kewney did -- that this success-induced gaping hole in innovation has turned a golden egg into charcoal briquette (one that has yet to fully flame out). But Kewney's explanation still misses the bigger picture. The history speaks for itself. But even if, at the present moment, the Cobalt or even a Linux-based version of the PalmOS were well into the market, the result would be no different.
Sure, device prowess (multitasking, multithreading) plays a role. But no platform survives without a thriving ecosystem where more applications beget more users and more users beget more developers (who want to make money off those users) and more developers beget more applications, and so on. Today, the only two seriously thriving ecosystems are .Net and Java -- moreso now than before now that the two can talk to each other (thanks to Web services). Sure, there's a fair amount of work being done in C/C++ (right on top of OSes like Windows and Linux) and stalwarts like Perl and Python are holding their own. But, there's hardly a computer-using human on earth who isn't also a target for .Net or Java developers. Think of it this way: Imagine a budding developer looking to enter the job market with marketable skills. Or one that wants to shrink-wrap his or her software for resale. Which target will most of them go after first and then second? .Net? Java? Linux? PalmOS?
Granted, 400,000 developers is nothing to sneeze at. But if PalmSource (or its ancestry) decided to go the Java route four years ago (or even five, before I had some insight into the situation), those 400,000 developers would instead be the 3 million developers that are developing Java applications. It might even have been 3.4 million (if you add it up). Imagine 3.4 million developers, all in a position to develop applications that run on your operating system. Which would you prefer in the face of the threat from Microsoft? That, or 400,000 developers?
Final word: Kewney is right. PalmSource slipped up in terms of innovation and as result, is not in the market today with a contender. But that slip-up started with the failure to set its sights on Java. Had it done that, and done so on a timely basis, everything else would have fallen into place as it has so done for Research in Motion which began its Java march in early 2002 and which continues to mature its Java offering to this day.