Software Everywhere — David Beers on Mobile Computing

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.