Software Everywhere — David Beers on Mobile Computing

So you've no doubt read that Palm canceled the Foleo. A lot has been said about this and I could write volumes myself. But as you've noticed, time and energy for blogging has been very scarce of late. I did make a few comments on a couple of forums the day we heard about the cancellation and in the interest of time I'd like to piece them together into a coherent post that says some things I haven't heard said anywhere else—why Foleo was really canceled and what it means for Palm.

Foleo and its Linux OS were born at a time when Palm's founders were returning to the helm of a Palm that had been ravaged by poor management and divested of its own OS supplier. They looked at the successor to Palm OS 5 that PalmSource had built (Palm OS Cobalt) which had huge built-in risks because it was proprietary everything—kernel, drivers, middleware, UI layer...at one point they were even developing their own compiler. They looked at the fact that an independent PalmSource would have its own business priorities. They identified it as a potential acquisition target for their competitors. And when they finished saying "Holy crap!" they decided three things.

First, they would hedge their OS bets by talking to Microsoft about using Windows Mobile; second they would keep a sharp eye on any acquisition activity directed at PalmSource and be ready to defend against it; and third, they would have a backup plan in case they were unable to keep control of Palm OS. They didn't want to be in a position where Microsoft was the only way to go forward. Working on Foleo was a way for Palm to implement a back-up OS plan that would fold into product development no matter what became of Palm's relationship with PalmSource. If PalmSource for any reason failed to deliver a smartphone OS that satisfied Palm's requirements, they probably reasoned that the work and in-house expertise developing Foleo could become the basis of a new in-house Palm OS. Foleo was Palm's "Next Big Thing" and it was also an insurance policy for their bread-and-butter smartphone business.

That's probably how I would have figured it, too. But Palm didn't have the luxury of being dealt their best-case scenario. First they failed to keep PalmSource from being acquired when ACCESS made a $324 million bid that Palm knew its shareholders would not be willing to match. Now Plan B had to become Plan A because Palm needed to keep control of their OS destiny if they were to differentiate and survive. If I'm right, at that point the Foleo team was developing the OS that Palm planned to use on future smartphones as well.

The next problem was, well... we don't know, exactly. But I have pretty good idea.

I think we can surmise that when Palm made a big deal to the media back in March about bringing in Paul Mercer, a guy who is famous for architecting the iPod OS as well as that of some very slick iPod competitors from Samsung, there was already a big rethink going on at Palm. Mercer is the kind of guy you'd hire to be a lead in a new OS project, not to join one mid-stream where most of the big architectural issues had been settled.

Still more telling, Mercer's outspoken views on system design are quite a departure from the traditional Palm approach, which is to keep application code close to the metal for maximum efficiency. "This is a ridiculous notion that’s been left behind by history," he once said in an interview on Intel.com. "On a network device, you simply can’t afford native code." He founded Iventor in 2000 to develop a "high level runtime environment for deployment of advanced, dynamic user interfaces." That's certainly the direction that Palm's competitors have taken, with Microsoft and RIM moving away from C/C++ native application interfaces and toward virtual machines that execute "managed code" for greater security and reliability.

Sure enough, Palm has posted more than a dozen device software positions over the last two months that list Java experience as a requirement. One from July read in part:

Development engineer for implementation of Java based mobile system software on new product development project. Responsible for all mobile development (design through implementation and release), working with other device engineers and design lead on overall system architecture and design.

It looks very much like Palm reached a decision back in February that it would not be repurposing the Foleo operating system on its smartphones after all. Instead they would have a go at adapting Mercer's platform technology to the smartphone Linux OS and let the Foleo team finish out their work.

That's crazy on multiple levels. Ed Colligan admits as much when he explains the cancellation of Foleo as a way to refocus Palm's development efforts. Supporting two operating systems, with separate toolchains and SDKs is more than a company Palm's size can handle. But just as important, the Foleo is a smartphone companion: its applications should be source compatible, if not binary compatible with those that run on the phone so developers can create paired applications easily. And it's not like Palm has no need for urgency in shipping a new OS on its smartphones. What could have prompted a decision to make a fresh start?

Now, Mercer is a magician when it comes to coaxing stunning graphic effects and elegant, performant user interfaces out of resource-constrained devices. If you have seen some of his recent work you'll know to expect a beautiful UI on the next Palm OS. But I've spent some time with the Foleo operating system and it's a very nice piece of work, too. I'd go so far as to say that Palm's lightweight DirectFB windowing system sets a new standard of responsiveness and simplicity for mobile Linux. As far as I can see, it would have made a great smartphone OS. Given how far Palm had got with Foleo, there's really only one solid reason I can see for Palm pulling the plug on it.

That would be the wireless carriers.

I have some grave doubts that the carriers in the US are enthusiastic about releasing phones with a new, open native Linux platform. Sheesh, they're even twitchy about sandboxed Java MIDlets running on their phones. AT&T completely blocks access to the file system by a Java application. No files for you! There are mass market phones with native APIs, namely BREW, but getting an app onto those handsets is a little like mustering a siege on a well-fortified castle. Certifying a single BREW C/C++ application to run on Verizon handsets costs several hundred dollars and requires at least a couple months of testing by NSTL, often much more. Then if you tweak a feature or fix a bug, you must certify again. The carriers do not want support hassles, and it's the native applications, which are vulnerable to buffer overruns and security problems, that concern them the most. Dollars to doughnuts, more than one Tier 1 carrier came to Palm with a requirement that native applications would have to be digitally signed and undergo rigorous carrier testing to run on their phones. That would have thrown a huge bucket of ice water on Palm's developer ecosystem. It's even quite possible in my view that one or more carriers said "no native 3rd party applications at all" as I bet at&t said to Apple. "Why can't you bring us an OS with a nice Java runtime environment for applications like your competitor, RIM?"

Ouch. Was Palm faced with a choice between torching it's 3rd party ecosystem and torching the OS it had been working on for two or three years? I have a feeling they were.

So there sat Paul Mercer, "dreaming about a personal device that offered complete access to information and media" where he could put his eye-popping, secure mobile runtime environment to work.

And there went the Foleo OS.

Foleo will be back. I doubt very much that Colligan would have mentioned a "Foleo II" if he wasn't pretty darned confident he wouldn't suffer the embarrassment of a second Foleo cancellation. And when it does come to market Foleo will surely be running Palm's tweaked Linux kernel, just like the new Palm smartphones will in a year or so. But the evidence points to the high-level intefaces being some flavor of Java, not native C. (Don't worry, I'm sure there will be a Garnet emulator for backward compatibility—for a couple years anyway.) If you're a developer and next year you're able to write "Palm OS" applications that you can distribute without carrier testing and pricey digital signing, you'll probably have Paul Mercer to thank for that.

And if your apps start fast and are as snappy as the original Palm OS when they run on the phone, thank Ben Combee and the Foleo team for that. You'll know their work on the Linux underpinnings was not in vain.

I'm putting a good face on this. Frankly, the cost in time, money and reputation is awful. It's not just that we don't know when we'll ever see the Foleo again (and I do think the concept is important and viable). It's that there will be still more delay before we see a Treo running a new Palm OS—12 to 18 months, says Colligan now. On the (slight) upside, since it typically takes that long for a new smartphone with an existing operating system to make it through all the carrier testing and approvals, this actually means that Palm is pretty close to being done with the new new smartphone OS and has hardware ready to begin that process.

The ultimate decision to cancel Foleo "in its current configuration" was right, but the embarrassing debacle was avoidable. If I'm right about the change of course coming down to carrier requirements, Palm could and should have known its customers and seen this coming a long time ago.