Software Everywhere — David Beers on Mobile Computing

The times when you have things you are dying to blog about always seem to be when there's the least time to blog. I've been thinking a lot about digital ink lately (among other things!) prompted by my use of a Livescribe Pulse Smartpen and of course the rumors of an Apple tablet device being on the way. These thoughts could easily run across multiple posts. For now I just have time to copy a comment I made on James Kendrick's blog entry Web Tablets and Text Entry—How to Do It?

I’ve been looking at digital ink a bit differently lately as a result of asking myself this simple question: when do I really need handwriting recognition? I think part of the failure of digital ink has been the focus on handwriting recognition, which has never been good enough to make people comfortable. The human brain is so much better at reading ink and most (not all, but most) of what we do with text is write it and read it with our eyes. If your colleagues at work got occasional ink emails or IMs would this be a problem? Blog posts or tweets in digital ink form raise some issues when it comes to indexing the content for search, but might not the “best effort” handwriting technology we have today be good enough to make this content pretty indexable? The main thing would be to get that HWR processing out of the user’s face so they didn’t have the unsatisfying and distracting experience of it’s imperfect operation.

The tasks I consider that I can’t reasonably do with pure ink are things like creating spreadsheets and writing code. By and large they’re things I wouldn’t normally do when I’m genuinely mobile. I’d love to see more mobile devices that takes ink seriously as a “first-class citizen” for communication of information rather than something that is bolted on in service to ASCII text, which even in the best case imposes so many unnecessary limitations. Livescribe’s Pulse SmartPen seems to have great potential and it will be interesting to watch it evolve (adding wireless, a good desktop SDK, etc). But I believe that there are millions who are still looking for something like Mike Mace’s InfoPad concept.

I think speech is interesting in a few scenarios, but is ultimately quite unnatural as well. A lot of the excitement over it seems to be from people who aren’t really considering the real-world texture of the mobile use context: there are way too many situations where speaking to your device is awkward, rude, or simply won’t work because of the amount of other voices and sounds around. I’m much more optimistic that a rethinking of digital ink will be the Next Big Thing in mobile input/output.

I'm being a bit glib here in writing off the need for text entry as much as I have. For one thing, every resource available on the web is identified with a text URL and every search request must begin with text. But I have a strong hunch that we will find that incremental or even major improvements in handwriting recognition are not the only or best way to address the text input problem.

I know I can think of some better ways, and I'm surely not alone.

Michael Vakulenko at VisionMobile says:

Despite high hopes, Palm and its WebOS software has (sic) barely made a difference in the growing smartphone market. According to Canalys, Palm shares 3 percent of smartphone market with Linux and proprietary platforms in the “Other” category. Clearly, it is not enough today to make an excellent device powered by modern operating system based on Linux and Web technologies.

Of course if you read the Canalys report you could as easily have used the same screwy logic to say:

Despite high hopes, Google and it's Android software has (sic) barely made a difference in the growing smartphone market. Hype notwithstanding, according to Canalys, Android shares only 3 percent of the smartphone market. Clearly, it is not enough today to make an excellent, modern operating system based on Linux.

These analysts always make me chuckle the way they start with a conclusion they believe to be true (usually just an echo of the rest of the tech media) and then filter the facts as needed to support it.

Maybe I should give it a try using the latest data from AdMob, which ranks all mobile handsets, not just smartphones:

Despite high hopes, BlackBerry has barely made a difference in the new smartphone market, having been displaced from AdMob's top five list by Apple, Android and, most remarkably, Palm. Palm's dethronement of the RIM "juggernaut" in just a few months on the market—despite the Pre's initial availability on just a single declining US carrier—shows that it is not enough today to make great hardware and software integrated with bulletproof messaging services. As Palm releases more webOS products on more carriers in the coming months expect it's innovative Web 3.0 application model to quickly take the wind out of the sails of the Android and Apple platforms which seemed indomitable only a few months ago.

There. Can I have Roger McNamee's job now? :-)

All joking aside, after using a Pre pretty regularly for the last month or so and working a bit with the SDK I do think they've got a helluva dog in the fight. It's kind of ironic, but despite my passion for mobile computing I'm not a guy who can say he's ever really fallen for a mobile handset. I like the idea of smartphones, but mostly they frustrate me in the ways they fall short of their potential, especially in terms of the user interface. I use a LOT of handsets on all the platforms in my work, but when I pick up the Pre I marvel at how much of the pain I experience on other phones simply isn't there. It's not perfect for sure, but it's an incredibly good start, in my opinion. I'm also hopeful that Palm is on a better track with their developer program than Google and Apple. Dion Almaer and Ben Galbraith from Mozilla and Ajaxian were an inspired choice to lead Developer Relations and I enjoyed immensely their sessions at the Sprint Open Developer conference. In all, I can't disagree with the analysts who identify Palm as an underdog, but I find myself rooting for them as enthusiastically as ever.

Update: Forgot to mention that if you want to understand what these smartphone market share reports do and don't mean, make sure you've read this (Mike Mace, Mobile Opportunity).

Went to the Sprint "Open Developer" Conference last week and, sadly, verified the suspicion I had expressed in my last post. Sprint, long one of the biggest proponents of mobile Java, will not be shipping Java on their future smartphones (unless they're BlackBerry's of course, which are natively Java). It wasn't exactly an "announcement," of course, since it's a deeply embarrassing reversal of a commitment Sprint has made to developers for some years now and this was a developer conference. But I raised the question in a general session where four execs were on the stage and, after alternately looking at their shoes and each other for a few moments, that's the answer that Mathew Oommen, VP of Network and Technology finally gave.

He then proceeded to insult his audience's intelligence with sophistry about Sprint being worried that having an open, modern mobile Java environment running across its device portfolio would "increase fragmentation." It's hard to think of a statement that could more succinctly have told his audience that (a) he didn't have a clue about what fragmentation means, and (b) he didn't really know or care about developers very much. Mr. Oommen seems to be part of a re-ascendant Old Guard at Sprint because this is a retrenchment from the new open image that the company has been cultivating.

Their strategy up until last week—never clearly articulated, I'm quick to add—was to bring mobile Java into the smartphone era by fitting as many handsets as they could (smartphones and feature phones alike) with powerful CDC Java environments. Critically, they also planned to end the mess of fragmented static stacks that we've called "Java ME" by delivering an open services framework on the device that would free developers and users to build the software stack they needed. That framework was called Titan by Sprint, but perhaps better known to Java developers as Mobile OSGi or JSR 232 for those who follow the Java Community Process. The mobile Java developer community has been waiting years for someone to commit to the next generation of Java ME, whether in the form of mobile OSGi or MIDP 3.0, and Sprint has looked for some time like it was going to be the first to get off the fence and say "let's do it!"

The plan was strategically sound and the technology great, but anyone who has watched the halting, timid way that Sprint introduced Titan over the last few years could guess that there were folks within the company who didn't understand the strategic value themselves, still less know how to articulate the vision for developers. Mobile developers could be excused for not knowing that Titan even existed or thinking that it was just some "enterprise" technology that had no relevance to what's going on in the rest of the industry post-iPhone. The first Titan devices—the HTC Touch Pro, HTC Intrepid and Samsung HD Pro—were released by Sprint this year with no Titan fanfare whatsoever.

Part of what was weird about Titan has been that Sprint did nothing to dispel the misconception that it was more than just "a Java VM for Windows Mobile handsets." The HD Pro is a BREW device running this powerful Java middleware. And my suspicion that Sprint had gone so far as to integrate mobile OSGi into their flagship Android phone, the HTC Hero, was proven true at the conference. HTC and Google gave away hundreds of Heros at the conference and while there was no mention of Titan, there it was, beautifully integrated into the firmware. The Hero (at least the one I received) lets you add OSGi programs exactly like any native Android app, even as widgets on the home screen. I am quite sure that this won't be the case for the Heros that end users get from Sprint, now that the Titan program has been canceled.

It's bitter-sweet to have one of the few truly open and modern Java handsets knowing that I can't develop apps for other users in that environment. OSGi is an enormous enhancement to the capabilities and openness of Android. And as I mentioned in my last post, I believe that's precisely why Google most likely talked Sprint out of including it on their Android phones.

Titan was admittedly a marketing conundrum for Sprint. It actually solves too many problems plaguing mobile Java, none of which stand out from the rest as anything like a "killer feature" to any developer that hasn't lived in the mobile Java trenches for some time. I'd have to kind of sit someone down and talk to them for a while to explain why OSGi running across most of Sprint's handset portfolio was more exciting to me as a developer than the latest iPhone SDK or Android 2.0. Even reviewing my blog posts on the subject I realize how difficult it's been to convey succinctly why I am so convinced it's is a game-changer. One moment I'm talking about how excited I am to develop mobile apps and desktop apps that interoperate beautifully because they share the same architecture and components. Next I'm going on about solving the deep fragmentation of mobile Java. Then I go on about RCP, which is the optional part of Titan that enables you to create a native GUI. Then I'm talking about the cool things you can do when you have a web server running on your phone, or why being able to remotely manage your phone from the network is so important. And then I go off on how the deep problem with Java in general is the absence of a good component model (which OSGi solves) and why having one can transform the whole economics of software development. I haven't been able to come up with a simple, punchy story. At the end of the day Mobile OSGi is not a new API candy, or pastry to follow Google's metaphor; it's the whole store! I've just been the kid blathering excitedly with his nose pressed against the store front window waiting for it to open for business.

At some point I'll give some analysis of what this means for mobile Java. Suffice it to say: it's not good. But right now I've got to get back to writing more mobile Java code and try to put all that out of my mind.

I've said for some time that Sprint's semi-stealth Java-on-steroids mobile platform, Titan, is one of the most inspiring innovations for mobile developers to come along in years. Sprint's development of Titan seemed to show they understood something important about their business: that to be more than a dumb pipe they needed not just to deliver services (all the carriers know that) but to compete for developer mindshare based on openness and power that is interoperable across a wide range of handsets. This year they changed the name of their developer conference to emphasize openness and, having followed the work on Titan since 2006, I had high hopes that Sprint was finally ready to make a big splash with it at the show next week.

Unfortunately, it appears that Sprint may have lost their nerve and decided to hang back with the pack after all. Looking at the agenda for the conference there is not a single session pertaining to Titan. The "big news" is that Sprint will start carrying some Google branded Android handsets, not that these handsets will run Titan in common with dozens of other devices across their portfolio. I suspect that Google may have strong-armed the carrier into scrapping the project. More on that in a moment.

First, understand why Titan running across much of Sprint's handset line (even BREW feature phones) was a brilliant plan to begin with. Titan is not a glitzy new UI layer, a powerful new API stack, a mobile cloud computing platform, or some trendy new way to consume or produce social media. But it is an enabler for all of these things and it puts developers and service providers in a highly productive relationship with each other with respect to them. Titan's profound service-orientation and remote management capabilities, coupled with a powerful VM and support for Java components that have never been available on mobile devices all combine to exhibit many of the characteristics that have made Web 2.0 such a strong ecosystem for applications. Having this common component framework extend broadly across a carrier's device portfolio as Sprint has been planning to do would make being a "Sprint developer" as opposed to an iPhone or Android or Java ME developer a surprisingly interesting option, especially once you consider what you can do with the platform.

So what can you do with Titan? I have to say, Sprint's not done a great job getting the answer across. Sometimes they've managed to make it sound like it's an enterprise application technology and had nice guys from IBM touting it for them at the booth. That's not going to convert many developers in this post-iPhone era. The truth is there are a lot of very cool things I am dying to develop (or, second best, have someone develop for me) that I can only imagine doing on a platform like Titan. Without it they would either be too much work, too costly to port across the platforms I'd want to target, involve waiting for some gatekeeper to open some API, or in some cases they'd simply not be possible at all.

Examples? Sure. Here are a few that I think about often:

• Personal server apps where my mobile serves up content to my desktop or home entertainment system using whatever connection is available and convenient at the time. ProSyst has already done the DNLA media server idea and it's awesome. But what would scratch my longtime itch would be to have an always-on-me personal web that holds all my notes, appointments and reminders and integrates with device capabilities like the camera, vibrating alerts, Bluetooth, GPS. I don't want my whole life in the cloud: I want it on me, and continuously accessible from whatever screen and input device is most convenient. With Titan, I can create standard Java servlets that run in Jetty on the device and have bindings down into those device capabilities. These could be accessed through HTTP and a static IP address using whatever radio is most convenient: carrier, wifi, or Bluetooth.
• Next up, a component for scripting UIs for some new machine-human interface concepts I'm working on. This would enable people who wanted to create apps using these design concepts to do so very easily and help me get traction for them. Note: Titan's OSGi framework lends itself to a more componentized way of writing apps, so my UI scripting component might work in one case with a rendering component that uses 2D graphics, in another with a component that renders a hardware-accelerated 3D visualization, and in yet another with a browser-based widget UI depending on what the phone would support. All would be implementations of the same service interface.
• Next I would use Titan to develop a micropayments mechanism for monetizing apps (later selling the company for a cool billion). This component would provide simple, standard ways to implement a wide variety of payment arrangements in any app that used it. Importantly, it would enable revenues from apps developed using multiple software components and/or content sources to be shared among the developers in a way that all could be confident that the agreed terms of the rev share were being met. Since Titan provides an OSGi-based middleware through which service calls between components are made, I believe that trustable and fine-grained logging of component use should be practical in a way that is impossible on any other platform I'm aware of.
• I want the components I create (not just the complete apps) to be available in an online Dev Store (hopefully using the aforementioned micropayment plugin) so I can make money building stuff that exercises my special expertise even if I'm not big enough to create all the incredible apps that need my component to fly.

I could go on, but I've done so before and frankly I'm not feeling very inspired to continue after looking at the Sprint conference agenda. Sure, some of this may be verging on pie-in-the-sky. But with some vision and the right partners, Titan puts Sprint is in a position to make all of the above possible and actually lead the next wave of mobile innovation. That's not something, I grant you, that mobile carriers are known for doing. But hey, I'm an optimist, Sprint has been acting admirably scrappy for a big-three US carrier, and they really seem to have been on the right track in this case. So pardon me for allowing myself to get some hopes up.

Now, the Sprint Android announcement is neat. Android has certain aspects of Titan's service orientation and openness, which is one reason it is attracting a lot of attention now and why it is expected to blow past iPhone in the next couple of years. But as much as I love Android, I have to say that Titan is more robust, more open, and better leverages standards that are already mature in the Java world, most importantly OSGi. In point of fact, Sprint could easily integrate Titan with Android (it's already been done) and augment Android's service orientation capabilities with those of Titan, bringing Android into the Titan family, so to speak. And this was what I most hoped to hear about from Sprint at their Open Mobile Developer conference next week. The only thing better would have been a Titan + Palm webOS announcement, but I wasn't hoping for that yet.

Instead, Titan is off the menu entirely. Probably canceled. What happened?

My best guess is that Google saw the open Titan model as a threat to their growing dominance in services to mobile apps. It makes it too easy for Yahoo or AOL (my current employer) to develop integrated app suites and open on-device APIs that bring developers and users to their services the way Google has used Android to expand it's reach. So I'm betting Google delivered Sprint an ultimatum: if you put Titan on an Android handset we will not let you use Google branding, and maybe not license you certain Google Apps. Because Sprint had not yet developed an ecosystem of competing services and apps to replace Google's and perhaps did not feel confident in their devices doing well without the Google branding, they caved. Sprint may have tried and failed to persuade Palm to put Titan on the Pre (more the pity for Palm in my opinion if that's the case) and when they started to look at their flagship devices not running their flagship middleware platform they saw the unifying aspect of Titan starting to fray. And they chickened out.

If I'm right, shame on Google for giving lip service to openness in public, while pressuring behind closed doors to stop it from occurring. And shame on Sprint for believing they needed Google's branding more than they needed to compete on openness, service and software innovation to win. If they really have abandoned Titan, they've shot themselves in the leg.

It seems that congratulations are in order to Palm for recognizing that its future depends on being more open to developers than the competition. I haven't had time yet to delve into the details of the new developer program that they announced this week, but the tech media seems to be impressed.

Rethink Wireless says that the new developer program terms "make Google's look tightly closed by comparison."

Software creators will be able to distribute applications on the web and will only have to submit to a review process if they want their software to be made available through the App Catalog, said the vendor, stealing some of the open web high ground from Google.

Palm recently hired Dion Almaer and Ben Galbraith of Ajaxian fame to head up their developer relations team. These guys know a thing or two about the power of openness and this week's announcement seems to show it.

Mobile software development first took off with the Palm OS platform, which was astonishingly successful at creating an ecosystem of small companies producing software, accessories and peripherals. Unfettered by wireless carrier business models since its evolution into the first successful smartphone platform was still a few years away, the original Palm OS and the PDAs that it powered made it tremendously open and easy for folks like myself to hang out their online "shingle" and start selling applications or custom application development to anyone who was interested.

Those days are gone and are unlikely to return. The reasons are well known to most of us and there's little point in rehearsing them in this blog post. If you want to be in the game, suck it up and learn what it takes now. The biggest challenge to a small company or individual developer first looking into the mobile market, or an old-school mobile dev looking to adapt to the new world: simply understanding the bewildering new platform landscape and all the hidden costs and hurdles of targeting each platform.

My good friend and Palm software veteran Justine Pratt at Creative Algorithms (run with her husband Corey) has done a great service to new entrants by producing an impressive matrix comparing all the major platforms—as well as some you probably didn't know about but should—in about 30 dimensions, both technical and market-related. Particularly helpful are the comparisons around digital signing requirements, benefits and costs, and around the various app stores: submission costs, commission rates. If you're not aware of the off-device distribution channels and which platforms they support, she covers these as well. Finally, she has provided estimates of the market size and the number of device models for each platform.

Making the right decision about what platforms to target with your application requires, in my view, some deeper intuitions about the platforms than could ever be captured by such a matrix. Some platforms are much better for certain kinds of apps than others, and you should not forget that each platform attracts different types of users. Also some platform vendors and app stores are better channel partners than others depending on their internal culture and their interest and experience in really supporting third party developers. But the information Justine has gathered is foundational and indispensable for such business decisions, and I'm surprised to say that I've not seen it all collected in one place anywhere until now. Justine is quick to call this a work in progress—as is the mobile landscape it aims to summarize. But grab the PDF off of Creative Algorithm's web site here and see if you don't agree that she's done us all a great service today.

Update: For updates on the document, follow Justine on Twitter.

Quick thoughts on webOS:

• Was I right or was I right about the JavaScript presentation layer running over Java middleware? I love this architecture. If/when Palm enables developers to write services in the device middleware the webOS ecosystem will really take off.
• By hitching its wagon to the rising HTML 5 star Palm is going to have less trouble supporting gaming and high-performance graphics than many expect.
• I still haven't bought a Pre because the Sprint coverage near my house is so spotty. Not to worry: I put the house on the market :-)
• I'm more certain than ever that webOS will soon have a desktop story to tell. I don't have the usual evidence to offer for this, just feel the stars aligning that way.
• I'd have a lot more to say about this platform were it not for a legal problem than I cannot discuss. I can't even develop on webOS right now, which is supremely frustrating to me.

I'm not dead yet!

One of the few pleasant things that can come of letting your blog languish is having a few long-time readers take the time to bug you about it. Thanks, guys... you know who you are! Apparently, flattery works.

I'm always impressed with the people who manage to make clockwork blog posts every day or even every week for years on end. For reasons I'm not sure I fully understand myself I seem to go through periods of furious spouting and then stretches where I go "heads down" and disappear from the web entirely. One thing: I don't have the self-control to write short snappy posts, so if for any reason I don't feel able to sit down and write the kind of essays that scratch my peculiar blogging itch I guess I just don't write at all. Another thing: after a long hiatus there is so much to talk about that the prospect of starting again seems overwhelming.

Enough of the self-analysis. This is a technology blog, so let me get on with it while I seem to be able! Queued up for discussion: Palm webOS thoughts, the LiveScribe SDK release, and another run at the perennial question: "where is the InfoPad?"

Wayne Parrot thinks it's going to be HTML5. His work on WebKit for SWT aims to prove it:

We have implemented a bidirectional bridge that allows you to implement JS objects in Java and to interact with JS objects from Java. This feature has turned out to be very useful as we are leveraging the power of HTML5 technologies in a much more dramatic and efficient manner from Java now. This is a dev strategy that I have wanted to leverage for sometime. I'm so impressed by what is possible that I'll make a controversial claim that if you are a Java UI developer and are not paying attention to the advances in web UI technology then prepare yourself to be blown away in a very short order by much more capable and productive UI developers that understand how to use new killer web UI features on the desktop.

WebKit's growing dominance in the mobile space (iPhone, Android, S60 and now Palm webOS) as well as the desktop make this a pretty intriguing UI option for Java developers—more so than JavaFX, perhaps. I like JavaFX script, but it wasn't the first dynamic scripting language specifically designed to complement Java for the purpose of developing RIAs. That was JavaScript, which already has great mindshare and energy that shows no sign of flagging. One can't help but wonder about JavaFX while the very future of Sun itself seems so uncertain.

Speaking of RIA's, a call-out to Jo Ritter for his recent comment on RMAs—Rich MobileNet Applications. This application model, which spans mobile and the desktop by introducing the stackless Java stack, is finally hitting some mainstream handsets thanks to ProSyst and Sprint. But let's get serious: that can't possibly come to pass until there is an entry for Rich MobileNet Application in Wikipedia, guys! Get on it!

Just a quick callout to the budding open source Blinki project at Eclipse Foundation (formerly known as FireFly). What caught my attention:

the FireFly project will develop next-generation technologies and frameworks to support the creation of mobile web applications that look and behavior similarly to native applications and are able to interact with device services such as GPS, accelerometers and personal data.

It looks like Genuitec (of MyEclipse fame) is leading this initiative. The first thing that's they've released is an SWT browser widget that uses the WebKit rendering engine. From Wayne Parrot's blog:

The WebKit for SWT browser API provides all the basic browser use-cases that you would expect. Additionally the cool features of WebKit such as HTML5, CSS3, V8 engine, and other things are now accessible from Java.

V8 is the super-fast open source JavaScript engine that Google developed for its Chrome browser. It's worth noting that it's been optimized not just for x86 processors, but for ARM Linux. Think Android... or the Palm Pre with its webOS platform.

Last week I mentioned that Mobile OSGi (specifically the Sprint Titan platform) would be a great starting place for the open source community to create a knock-off of the Palm webOS mobile platform. Now that the bindings between a Java runtime and the WebKit HTML5 rendering engine are in place the community is quite a bit closer... and webOS isn't even in the wild yet. The beauty of the OSS version would be that developers could write code not just at the JavaScript front-end as the Mojo SDK will allow, but they could also write Java modules that run as services in the middleware tier—or even native Linux or Win32 modules encapsulated in OSGi bundles. For Palm fans who read my blog, think webOS (or something much like it) running not just on the Pre, but on the Treo Pro with Windows Mobile under the hood.

I'd like to think that developments like this will force Palm to release an SDK that opens its own middleware layer. For webOS to get the most traction in the market Palm needs to leverage the architecture's natural advantages as a service oriented mobile platform. Android's Achilles heal is the weak component model and attenuated, non-standard affordance for apps to provide services to each other (i.e. be "mashed up"). If Palm doesn't go after that weak point early in the evolution of webOS, it won't take long before others make the first move.

UPDATE: The new Blinki blog is here. Watch it.

Working at MapQuest for the last year and a half has been an extraordinary opportunity for me in that the mobile applications I create there are targeted to an audience of 40 million people who use MapQuest.com at least once a month. A slight downside of being associated with the top brand in online maps and directions is that I'm not as free to talk about my work as I am when the signature on my paycheck is my own. That fact—and being on a small team that does daily battle with outfits the likes of Google—helps explain why I haven't posted on Software Everywhere as often as I like.

This week we had a new release of the MapQuest4Mobile application that has been my main "baby" over the last year, and the marketing folks asked if I'd like to blog about it. I still can't say much about what's coming next (aside from "you're gonna like it!") but at least you can get a feel for what I've been up to during this "heads-down" period of time. Check out my post on the MapQuest blog, and if you've got a supported BlackBerry device, check out MapQuest4Mobile!

(Pay no attention to the name on the MapQuest blog entry—it's me. I guess the "author" of the posts in the blogging application MapQuest uses is always the name of the guy in marketing who pushes the "Publish" button.)

The sleeping giant of the mass market is finally waking to the realization that mobile phones are personal computers. Software developers have been waiting for this day a long time—longer than most expected—but the sad irony of the situation is that the mobile software opportunity is now mired in software itself. Application developers aiming to target this broadening swath of mobile users are spread too thin to innovate: they spend most of their time and resources reinventing wheel after wheel and porting their applications to platform after incompatible platform. In sharp contrast to the circumstance of developers on the Web where interoperability and shared componentry are the norm, mobile developers find themselves corralled and Balkanized by scores of incompatible languages, runtimes, profiles, browsers, rendering engines, and SDKs, to say nothing of the fragmentation that makes the same API feature in any of these "platforms" work differently on each of a handful of different devices.

Allow me to do some back-of-an-envelope math to underscore the magnitude of the predicament. Consider five hypothetical independent software vendors developing five applications—each different but sharing five features in common. Just to put us in the realm of the concrete, suppose the features are real-time location awareness, consumption of RSS, rendering of complex animated graphics, instant messaging, and network presence. Each ISV wants their applications to run on 100 handsets spread across five mobile platforms: iPhone, Android, S60, BlackBerry and Palm webOS. (The execs said no budget for Windows Mobile, MIDP, BREW, JavaFX, Palm OS, WebKit browsers, etc.) Thankfully, some of the platforms have proprietary built-in components that implement these features and a couple have SDKs in the same programming language. Even so, if you work out the porting permutations, the total amount of duplicated effort across these companies could easily outstrip the effort of developing the differentiating features by two orders of magnitude.

Let's face it: while this crushing fragmentation persists (cloaked in the excuse of "differentiation" and "personalization") mobile technology will not only lag behind web technology, it will hold back the Web itself.

Many have blamed the carriers' pursuit of differentiation-at-any-cost for this perverse state of affairs. So who would have thought that Sprint-Nextel would be the first to chart a course out of this mire, still less to blaze a trail for developers across two million mass-market and up-market handsets this year? That is the significance of the Sprint Titan platform, the first mobile environment built on the proposition that real mobile innovation comes not from herding developers into a better silo (even an open source one) but from enabling them tie many APIs together dynamically using a universal component framework. Titan is not a new operating system. It's middleware that runs just above the OS, enforcing Lego-like interoperability among components—even for code written in different languages—and providing a service-oriented architecture so any developer can offer their own APIs for others to build on.

I've started working with Titan a bit and I'm really inspired by the possibilities.

Technically, Titan is comprised of an unusually powerful Java ME runtime environment (CDC/FP), a dynamic component framework (OSGi), a remote device management agent (OMA-DM compliant), and a basic kit of service components, called "bundles" in OSGi parlance. A few words about what each of these is bringing to the table:

• Java ME CDC is a big step up from what's on most phones today. Critically for Titan, it supports Java Standard Edition features like shared libraries, custom classloaders, invoking native code, and rich APIs for graphics and UI.
• OSGi is the same dynamic component framework that has made the Eclipse development environment easy for developers and tool vendors to extend with hundreds of plug-ins. But OSGi didn't originate with desktop-class hardware in mind: it came from the world of embedded devices. OSGi bundles are written in Java, but they can include native code to expose special OS or device features. They can also implement bindings to other languages like JavaScript, ActionScript, or JavaFX, enabling code written in these languages to access the same features. Titan is not just another Java SDK. It's greatest potential may be as an extensible mobile RIA platform.
• Remote management is part of the OSGi Mobile spec and a key to making mobile software development more agile. Application updates on many mobile phones today are so disruptive to users that most companies are rightfuly afraid to impose updates more than twice a year. Combined with OSGi's unique capability of updating components without restarting the VM, remote management should enable no-touch updates of rich client apps of the painless sort usually reserved for web applications. The agility advantage of "release early, release often" may finally be available to mobile software shops.
• Service bundles are where Titan surpasses mobile Java platforms like MIDP (even MIDP 3) and Android. For example, if Titan is running on an OS with a native GUI toolkit like Windows Mobile or S60 (or a desktop OS, for that matter) it can expose that toolkit as a service using eSWT and the embedded Rich Client Platform bundles. I believe you could develop entire applications in native code with the thinnest of Java wrappers to allow install/start/stop/update lifecycle management by the framework to maximize performance. Still more interesting, Titan ships with an HTTP service that is a full-fledged Java servlet container. This enables applications that use the browser to render the UI but have JavaScript bindings into system capabilities that web applications can't normally access: local databases, GPS, Bluetooth, the camera, etc. Where mobile browsers usually render the Web as a pale shadow of their desktop counterparts, the mobile Web on a Titan handset can be combined with mobile phone capabilities in ways never seen in a desktop browser.

In it's 1.0 release Titan has been implemented for Sprint's Windows Mobile Pro handsets, including the Palm Treo Pro, slated for release on Sprint this weekend. It supports writing apps in Java with a native Windows GUI (eRCP) or multi-tier web UI apps that use the browser engine for the front-end and Servlets running on the internal HTTP service for the business logic and access to features like GPS location. But insiders are saying that this middleware will stretch very broadly across Sprint's handset portfolio as well as devices designed for the XOHM WiMAX network, so we can expect that bundles for additional application models are in the works. Flash Lite seems like an obvious candidate, as does LWUIT. I've seen a presentation that hints that JavaFX could be a frontend on some Titan phones that Sprint releases.

The beauty of it is that no one has to wait for Sprint to implement new bundles and start embedding them in the firmware. If Sun wants to package JavaFX as an OSGi bundle, developers could add JavaFX apps to Titan phones that had no such support when they were released. I've already suggested that Palm give serious consideration to implementing its webOS middleware as a collection of OSGi bundles for portability. But even an indy developer could mash up some open source and homebrew libraries, create a new application model for Titan and share it with other developers. I predict that a Titan phone will be the first to run a knock-off of Palm's webOS developed by the open source community.

Creating your own SDK may not sound like a very practical idea for the average mobile developer (maybe only slightly manic ones like myself!) but building apps using middleware bundles that provide easy access to popular web services from Google, Yahoo, Amazon, Facebook, AOL and Twitter will be an exciting proposition for any developer. We can guess those vendors as well as smaller web startups will soon be populating Titan's bundle ecosystem with plug-ins for everything from messaging to mapping in a bid to extend their reach, leveraging the creativity of third parties to build the apps they couldn't—or wouldn't think to—build themselves.

Beyond the technical capability Titan provides to build applications by mashing up components, the question of how components can be published and optionally monetized is key to the success of Titan as a driver for mobile application innovation. Vendors like the ones just mentioned are likely to offer free bundles to developers that want to build on their services. And open source bundles will surely abound—they already do. But what about a marketplace where developers can sell components they have developed to each other? Possibly even a payments service on the device to enable component vendors to implement monthly recurring charges or micropayments to monetize highly complex or valuable components. I hope Sprint is giving some thought to this, because creating a great business model for developing components will make the difference between Titan being disruptive or just deeply interesting. And I'm also interested to understand what security policies Titan will implement and how Sprint will deal with testing and certifying bundles that aren't themselves applications, but middleware services for other applications to consume. Trustability of components will be critical to creating a vibrant market and a new era for component-based mobile application development.

By the way, check out Jo Ritter's blog for one of the best sources of information about Mobile OSGi and Titan.

My favorite company in the industrial handheld hardware business is, like many of the rest of us, seeing some tough economic times. In their latest newsletter they have announced they're having to sell the company jet:



These guys are old friends and we haven't sent much business their way in a while, so after reviewing things with the CFO (who I'm sleeping with by the way*) I've decided that Pikesoft will make an offer on the Aceeca jet to replace one from our own aging fleet:



I hope Alex's jet has WiFi like ours do.

*Usually with a 50lb dog between us.

It was hard to know where to start in talking about all the exciting software development prospects for the Palm Pre and webOS. I began by speculating about an eventual Java SDK for webOS, which would be a heck of a left hook to follow the Mojo SDK's right jab. But I'm getting ahead of myself. Even just considering the JavaScript SDK they have already announced Palm has put themselves in an astonishing strategic position that I'm surprised no one is talking about. By building a system using de facto cross-platform standards like JavaScript, WebKit, Java and Jetty, Palm has made a great platform for creating companion applications that can run on any desktop—Windows, Mac, or Linux—leveraging the same code that runs on the handset. You won't see Apple being able to deliver iPhone applications to the desktop like that any time soon, at least not for the 90% of personal computer users that don't own Macs.

Palm has prepared us not to expect desktop synchronization via cable or cradle like what Palm OS users have been accustomed to since the beginning. But the Pre is among other things a modernization of the original Palm concept of having always-on-you personal information management, updated to the reality that much of people's personal information now lives in the cloud. The desktop is still going to be the command center for most people's digital life and Palm knows it. So gazing into my crystal ball, let me tell you how the desktop story will in fact unfold:

LAS VEGAS, CTIA Wireless 2009, Apr 1, 2009 - Palm, Inc. (NASDAQ: PALM) today announced the Palm Desktop Companion, an application that brings to the Windows and Mac desktop the same integrated calendar and contacts found on the Pre smartphone.... Desktop Companion uses [crystal ball is clouding a bit here] to keep your calendar and contacts synchronized automatically without the use of cables or cradles. [Did I make out the phrase "peer-to-peer" when the crystal hazed over in that moment? Or was there a faint trace about a "secure web service"? Oh well, the future is coming through clearly again now.]

SUNNYVALE, CA - May 15, 2009 - Palm, Inc. (NASDAQ: PALM) today announced that the Mojo SDK will not only enable third party developers to write applications for webOS devices like the Pre smartphone, but to deploy the same applications to the Palm Desktop Companion.... "The SDK enables webOS developers that follow some simple SDK guidelines to build applications that 'unfold' naturally on computers with larger screens for the extra ease and efficiency of the full desktop experience" says Palm's VP of Developer Services Horton Hooville.... [The image dimmed for a moment there... not sure I got that name right.]

MOUNTAIN VIEW, Calif - June 23, 2009 - Three days ahead of the scheduled release of Palm's Pre smartphone, Google, Inc. (NASDAQ: GOOG) announced the release of GMail and Google Docs for the Pre as well as for the Palm Desktop Companion.... This announcement brings Google's popular mail service to the Pre as well as instant access to all of your office documents at any time. When at their desktop, users of Palm Desktop Companion now have access to Gmail and the ability to view and edit documents, presentations and spreadsheets even when they are offline....

BARCELONA, GSMA Mobile World Congress, Feb 15, 2010 - Palm, Inc. (NASDAQ: PALM) today announced the Foleo Pro Mobile Companion... The Foleo Pro runs properly configured applications created for the Pre without modification, but with the same ease of use found in the Palm Desktop Companion application.

The unfolding UI concept would be the key to making application screens that stack on the phone to display side-by-side in the familiar "master-detail" layout seen in applications like the original Palm Desktop and Microsoft Outlook. I blogged some thoughts about this idea way back in Sept 2005 in one of my very first posts, complete with a lame mock-up to illustrate. It's simple, really. Many, if not most mobile applications provide a "master" or "list" view of the data from which the user selects an item and then navigates to a screen that displays the details of the selected item with additional options for manipulating it. If these master and detail screens (or "cards" as Palm now seems to like calling them) are identified as having this relationship in the code by using an API that binds the selection in the master view to what is displayed in the detail view, all it takes to spread the stacked cards across a larger surface so they are viewable side-by-side is a little CSS. Making a desktop version of a webOS application might involve no additional coding at all, just some care to follow certain design guidelines.

The main work for Palm would be to create a native application that hosts the webOS environment on each system they want to support and provides some hooks into system services so that things like calendar event reminders work from the desktop. From what I can glean from looking at the leaked screenshots of the SDK in action, most of the hard work of developing this desktop presence has already been done since it went into developing the webOS middleware already on the Pre. That's the main reason I'm optimistic that Palm could pull this off during this period of severely strapped resources.

They would also want to integrate their application store in the desktop companion app, since the desktop is clearly the easiest and most engaging way to search for and try out applications. Letting application shoppers try an application in a simulated Pre phone launched from the desktop app would be a great way to break down the natural resistance to trying something new. I also believe there are opportunities to make installation of the application to the phone slicker and smoother than we've seen on other platforms using a desktop companion app like this.

Of course, some mobile phone features that Pre applications could use like the microphone, camera, voicemail, SMS and GPS would not be natively supported on most desktop computers. But if Palm or a third party were to implement peer-to-peer communication between the Pre and "Palm Desktop Companion" it wouldn't be much of a stretch to make even these phone features usable from the desktop. While you're at your desk you could receive SMS messages, proxied by your phone, and answer them using the keyboard and mouse already at your fingertips. With that link to the phone in place, seeing voicemails show up in the inbox of the desktop companion and being able to listen to them there might be a modest effort that extends Palm's story about total integration of messaging and contacts one notch further. Desktop web searches or mapping applications could be localized by clicking a "near my current location" toggle that geocodes a GPS fix retrieved from the Pre in your pocket and adds the location data to the query.

What a spectacle it would be to see Palm show up out of nowhere as one of the players in the hotly contested cloud computing arena. And not just to show, but to conquer a niche because their AJAX APIs expose unique messaging, location, even voice and camera functions on the mobile that only their position as a mobile software/hardware integrator makes possible!

Am I getting carried away now? Perhaps a bit. I may have compressed the timeline for these developments to unfold. But my bet is that their webOS strategy gives Palm a long enough lever to move some surprising mountains, even in their current weakened state. If they share the vision I've described, the key success factor in realizing it will be a peerless commitment to enabling the success of third party developers so that Palm has a strong ecosystem to pass the baton to. Palm's success in the 90's was built on stellar developer support and it's revival today must be built the same way. Early indications give hope that Palm gets this.

If Palm declines to offer a C/C++ or Java SDK and loses some developers in order to focus their energies on getting webOS and the Mojo SDK a place on the desktop, it'll be hard for me to feel all that disappointed. For that, I'll brush off my JavaScript skills and get right to work.

BoyGeniusReport has leaked some screenshots of someone using what looks like the Palm webOS SDK, complete with revealing console output. (You should know that a normal person looking at that gallery would be admiring at all the pretty UI pictures, of which there are many, but I'm most fascinated with the debug console.) The console shows the JavaScript code making requests using a "luna://" protocol to a Jetty web application server running locally, which in turn uses file I/O to access files with .json extensions in a Linux-like file system. It's not a sure thing I suppose, but it's a pretty darned good bet that we're seeing something very close to what happens when a webOS application is running on a real device like the Pre smartphone. If that's the case we've learned quite a bit, and can guess even a bit more.

First, at least as far as the application framework is concerned, the software on a Pre looks an awful lot like a Linux web server and nothing at all like Android, ALP or any other Linux-based mobile platform we've seen. Second, the server code that is running in the development environment is Jetty, which is Java. That makes sense from the standpoint of enabling developers to use Mac or Windows workstations but maybe there's a native C/C++ server running on the actual device. I doubt it. I say there's a Java app server running on the phone, too, inside a nice Java runtime. Why?

Well first, why not? Java is secure, stable, runs on all kinds of processors and OSes, including x86 PCs and Macs and a billion or so mobile phones. Palm didn't have time to mess around with porting or reinventing the wheel. Second, as I pointed out back in Sept '07 when the Foleo was cancelled, Palm was hiring Java engineers 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.

There have also been ads for Java web services engineers, but ads like the one above told me to expect that Palm's new Linux system would be "Java based." And I'm more sure than ever now that it is.

Here's what else we know: it's not a J2ME MIDP environment on the Pre like the ones on most other phones. To run an application server it's at least a CDC environment with Foundation Profile, which means it's pretty beefy and has a lot of the power of the underlying Linux system available to it. That doesn't necessarily mean that Palm will be letting 3rd parties write applications that run in the Java runtime as opposed to WebKit, but they certainly could.

This is where I get really intrigued, though. See, Palm's first carrier partner is Sprint. Sprint has been on the forefront of an idea to make mobile devices first class citizens on the web by enabling them to run "desktop class" software. The way they are doing this is through a platform they call Titan released just last month. Titan puts a powerful Java environment together with a technology called OSGi, which is the special sauce. It's a service platform that enables developers to create software by plugging together software components. For example, Sprint's Titan platform includes a web server module to enable iPhone-like widgets (hmmm). Because the server is running inside the OSGi container, widgets can interoperate with other components in the container: components for GPS location, messaging, multimedia, etc (hmmmm!).

The novel service-oriented architecture of webOS bears more than a passing resemblance to Titan. And I can't think of a better way for Palm to have put it all together than with OSGi, just as Sprint did. Loyal readers know I've been waiting years for OSGi to go mainstream on mobile phones. There are so many good reasons, for it, especially for Palm:

• OSGi fixes some unfortunate limitations of Java ME: incompatibility with standard Java packages, no shared libraries, no long-running services, no loading of classes that weren't installed with the app, no intercommunication between applications, no app updates without reinstalling the entire application, etc. Seems like half the places you think there should be a door there's a blank wall.
• OSGi also solves many of the problems that motivated these limitations in the first place, mostly having to do with challenges of delivering high reliability, manageability and security in an open component-based platform, long a sort of holy grail for software development
• OSGi is designed for remote management. It would be ideal for performing firmware, software, or configuration updates over-the-air. Such updates could originate from Palm, from a carrier wanting to deploy a new service or app, a third party developer, or possibly an enterprise customer wanting to update an application or setting across all their users. This capability would give Palm one of the advantages that RIM has traditionally held in the smartphone market.
• OSGi is ideal for delivering the same service with the same code across multiple platforms. If Palm is serious about delivering web services and plans to keep their Windows Mobile smartphone line they can reuse the Java service components they develop for the Pre on their WinMo phones. This can be true even when OS-specific native resources are involved. For example there is a powerful framework called RCP for creating Java GUI applications that can run on Windows Mobile, desktop Windows, Mac OS or Linux--all with a native UI provided by the underlying system. RCP and OSGi are the technologies that enable the Eclipse development environment to run fast with native look-and-feel on Windows, Mac and Linux desktops. Let me be clear here: It's totally feasible with OSGi under the hood for webOS applications and any special services that Palm develops for the Pre to also run on Windows Mobile, and that Java apps with native Windows Mobile GUIs could be developed using RCP that leverage the identical service software. I'd think that would be a pretty compelling proposition for Palm.
• OSGi makes Android's IPC-based component model look slow, weak and restrictive. OSGi communicates with its bundles by ordinary method calls, a much better way to enable the kind of mash-ups that have made Android attractive to developers.
• OSGi is a mature, open standard with strong industry backing, a sizable catalog of mostly free plug-ins, and considerable buzz among developers

So what to make of this? Has Palm jumped on the OSGi train? There's no way to really know at this point. All I really know is that if I were going to develop a system like webOS I would certainly use OSGi, and that some pretty smart guys I know at Sprint (and Nokia, by the way) came to the same conclusion. Keep in mind, if Palm is packing some OSGi goodness it doesn't mean it will all be open to developers when the first SDK is released. If they allow third party Java components at all there will likely be a digital signing requirement. But the day an SDK is available for Java as well as JavaScript developers, and we can target both webOS and Windows Mobile smartphones, Palm will be in a superb position to build a developer ecosystem that draws deeply and broadly on the talent that powers Web 2.0 today.

Oh, and I'll be there, too, heh. With bells on.