Software Everywhere — David Beers on Mobile Computing

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.

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.

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.