The Ideal Mobile Software Stack by Simeon Simeonov

By Simeon Simeonov

sim_blog.jpg

Note from Ajit:

This post comes from Simieon. The views expressed here are not 100% consistent with mine, however – this is the OpenGardens blog :) i.e. differing views are welcome – and in some ways – encouraged!. Sim of course, knows a bit about Adobe/Flash and Macromedia since he was vice president of emerging technologies and chief architect at Macromedia before joining Polaris ventures.(Polaris is a Tier One VC based out of Boston). Sim is also a good friend and is a contributing blogger to the OpenGardens

It was great to meet Simeon personally at 3GSM and we had a great time discussing technology, industry vision, technology trends etc etc. Sim attended my session at 3GSM on Mobile Web 2.0 and we discussed this post extensively before my talk. On the way back to my hotel and the location of the Ogilvy Telecoms conference (more on that later), we discussed more things tech related – it was surreal discussing ‘Sim’ cards with Simeion Simeonov Simeonov :) . So expect more such posts from Sim

Sim’s post follows …

I’ve written previously on the need for a better mobile software stack.

My ideal phone stack consists of Linux as the HW abstraction layer, real-time Java as the phone middleware and Flash Lite as the presentation tier.

I’ve gotten quite a few questions about this so let’s look at the problem more broadly (with the addition of AJAX as a possible presentation tier) and then layer-by-layer. I should start by saying that I have very little specific experience in phone HW/SW design. My comments are based on my experience with platform runtimes, N-tier architectures and developer ecosystems–most of which are gaping holes in the mobile space.

Some general observations, i.e., the set of my high-level biases about mobile:

• The mobile space is likely to continue its rapid evolution. Video is the new big thing. Location-based services (LBS), 3G/WiFi/WiMAX, advanced voice apps, security, advertising and others are on the horizon.

• Phone HW evolves quickly and there is increased pressure for it to evolve even faster to meet market timing needs. Being at 3GSM this week confirms this.

• Device capabilities are getting better. For higher-end devices, memory and CPU are rarely the constraints these days. It’s most likely I/O (screen + text input) and battery life.

• There is significant device fragmentation, which is likely to get worse because HW is becoming more and more tuned to the target market segment. Saw several companies at 3GSM offering mass-customization of phones for narrow demographics or affiliate groups.

• ODMs know HW. They don’t know SW. The big ones are learning slowly. The Tier 2/3 cannot invest enough to learn quickly.

• Most on-device software is pretty terrible. (Some favorite examples… Until the very latest Blackberry models came out you couldn’t forward emails as texts and vice versa, even though they are in the same inbox. A MOTO friend told me that RAZRs used to, perhaps still do, have separate inboxes for SMS vs. WAP Push messages. The WAP push inbox didn’t have notification so consumers wouldn’t know that they’ve received a link.) Take a poll. Who of your friends loves their phone software experience? More than 10+yrs after the arrival of the Mobile Web, the phone experience is predominantly still voice and text.

• Phones are increasingly adding 3rd party software, e.g., instant messaging clients, Flash Lite, on-device portals (ODPs), etc. It’s a struggle to integrate this software with the device given the tight market cycles. Very few companies, e.g., SavaJe and Open Plug, offer solutions in the space and none that I know have any significant traction.

• The closed garden walls are starting to come down, no question about it. Phones that support WiFi will serve to accelerate this trend. There are some very cool startups, such as Fonav, started by my friend Ram Fish, working hard to make this happen.

• Eventually, mobile advertising will work. I’m not sure exactly how it’ll happen and it certainly won’t happen as fast as some of the mobile advertising startups are hoping for but advertising will ultimately be figured out because content and not pipes is what attracts end-users, which would lead to an eventual opening of carrier networks, which leaves tapping the advertising/direct marketing value chain as the most obvious revenue model. Subscriptions won’t go away but there will be more all you can eat subscription plans, again, a trend confirmed by announcements at 3GSM.

• Mobile content is developed by a relatively narrow + fragmented ecosystem of about 1M developers. (It’s a very rough guess. I’ve asked everyone from MS to MOTO to Nokia to carriers about numbers and nobody knows for sure but they all agree that around a million is probably a good bet). There are probably 10+M non-mobile developers.

The biggest problem in the space from my naïve perspective is that there is too much friction in the mobile value chain. Friction increases the cost of experimentation and hence market entry. The result is a slower pace of innovation in the mobile space. Much of the friction is due to cultural issues and business models, a topic too big to tackle here. The rest is due to technology.

The first tech problem to tackle is the introduction of new phone hardware.

Once you have the HW you have to bolt on the SW. Traditionally, this has been done through hardcore hacking/porting of an embedded OS (for the cheapest phones), some modified version of Linux or one of the smartphone OSs, e.g., Windows Mobile or Symbian. Windows will do great in the enterprise because of the ability to integrate with the installed base of Office, SharePoint and Exchange users. Symbian is neat but I expect it to have difficulty becoming a dominant platform because, like Windows Mobile, it is proprietary yet it doesn’t have the demand pull that Microsoft can generate through its installed base. The rest of the world will want something cheaper, more flexible and less controlled by big vendors. This set of requirements will sound familiar to people who built appliances in the enterprise space. Their choice was Linux. The same set of forces will make Linux the choice in the mobile space. The current approach of hacking Linux to force fit it to devices will give way to a more architected approach with a meaningful hardware abstraction layer (HAL) supporting binary compatibility with the higher OS layers, akin to some of the work that startups such as A La Mobile are doing. The task of high- and low-level driver development will spread to the various component manufacturers, making the load bearable. This is the only sane approach to lowering costs and time-to-market on the HW/SW interface side, especially when one takes into account the ODM’s lack of SW skills. That’s an opportunity for third parties.

The mobile version of Linux should stop far short of the set of capabilities one would find in a desktop OS. There should be no focus on UI or even basic user services. Linux as an environment and C/C++ as the programming language are not the best-suited for this. I’ll grant that this is an arguable point. Most of the very cool mobile/embedded UIs (from the iPod to the early Blackberries) are done in C/C++. However, I see that primarily as an artifact of history. By the same argument, one can say that the best user experiences on the Web are done using plain HTML as opposed to Flash/AJAX but that would be ignoring the trends. C/C++ fail what I call the ecosystem test.

The second tech problem to tackle is the integration of various phone services into a flexible, manageable, extensible on-device service delivery platform.

Think of it as the API into the phone but not in a fixed (these are objects/methods) way. Instead, think of it as something akin to a mini-SOA architecture for the phone without all the runtime overhead because the environment is constrained. Does something like this exist right now? Not that I know of but it should. (Open Plug and similar companies offer dynamic binding upon application/service installation but do not go all the way to dynamic service discovery and invocation.) Without this type of abstraction layer, building applications that leverage phone services and integrate them together becomes much harder. Upgrading services may or may not break applications.

Conversely, upgrading applications to take advantage of new services would also become harder. It is important for applications to plug into this layer and expose their own set of services to the phone and other applications.

Let’s look at some examples:

• You install a new IM client. It registers as a texting and messaging service with the phone, allowing you to forward texts, emails and pictures to your IM buddies, even though the texting and emailing apps never considered the existence of IM as a way to exchange messages.

• You download a Skype client to your phone. It should be able to integrate with phone features controlling microphone, speakers, and call services. If allowed (by the user, operator, …), Skype could become a callout service + integrate with your address book + more. If so configured, Skype voicemail should be able to trigger the phone voicemail indicator yet not interrupt how phone voicemail is processed.

It’s not easy to build this layer in the phone since it has to encompass telephony services (both on the cell network and VoIP), broadcast services (mobile TV/video), data services (real and non-real-time over the cell network, WiFi, WiMAX, etc.), etc. It has to have real-time dispatch and event processing capabilities. It has to have a strong security model. It has to have easy to document/use APIs and fit SOA concepts well. It has to target a large, existing, globally distributed developer ecosystem armed with good tools. Some standard set of frameworks/services built on Java seems to be the only viable answer for the time being. And it has to be small and simple enough to run on common phone platforms.

MIDP2/3 are not relevant here in the sense that there is no UI involved. This is truly a multi-threaded middleware layer, making the phone HW and installed applications work well with one another. My guess is that J2ME CDC should be sufficient.

The final layer in the proposed three tier mobile stack is the presentation tier.

The requirements for a good presentation tier are that

(a) it can generate engaging user experiences on target devices and

(b) there is a ready ecosystem that can deliver content and applications to that presentation tier. The latter point is, in fact, the most important one, getting back to the ecosystem test and the claim that content, broadly speaking, rules in the end. Ecosystems take years to build out and nobody has time for that.

Java goes out the window when evaluated against these requirements. There are very few examples of truly engaging user experiences developed with Java. There are not many developers who know how to develop these. Most of the people doing UI work with Java have been in the enterprise domain. This issue isn’t that you can’t build cool mobile apps on J2ME, it’s that there aren’t enough people who know how to build lots and lots of them.

Realistically, there is only one broad community of developers to tap into to grow the supply of content and application in mobile in a big way and that’s the Web developer + designer community. The designer/developer role split is very complementary for consumer experiences. A mini-app (widget) or a container for some interactive content, e.g., a video with some interactivity, can probably be handled by a designer type with some development ability. More sophisticated apps (say an IM client for the phone) will be developed the same way they are done on the Web–interactive designers architect the core of the user experience and graphic designers + developers fill out the pieces on top of the middleware architecture/services provided by the phone.

The Web 1.0 experience, with its constant page refresh cycles, is poorly suited to the low bandwidth, unreliable wireless networks. That’s why most WAP/WML mobile sites suck. Even Google has switched to downloadable clients for its mobile apps.

The solution is to go the way of Rich Internet/Mobile Applications using either DHTML + AJAX or Flash (Lite).

Neither is a perfect choice in the short run. As a side note, it is important to notice that this presentation tier runs on the phone, not in the browser. It is the phone UI, while the browser is just one of the applications. Ideally, it will include the phone top. MSX is a good example of a company developing flexible phone tops using a high level of abstraction.

Whether Flash Lite or AJAX ends up with a dominant market share in the future is a topic worthy of another post. Both have strengths and weaknesses. My personal bias puts me closer to Flash, yet Ajit makes a very compelling argument as to why AJAX is the better chance in the long run in his post Flash Lite is not WICD but it should be . The biggest problem on the AJAX side is fragmentation—there are too many browser limitations and incompatibilities right now even when one considers the high-end offerings such as Openwave’s MIDAS or the Opera Platform. I don’t expect these to get resolved for years–just look at the problems that PC browsers have had over the years.

Efforts such as mojax, may play an increasing role in this space, especially since mojax, through its J2ME implementation, is exposing lower-level phone capabilities to the presentation tier.

mojax is one of the worlds first Mobile AJAX Application Frameworks. Unlike traditional AJAX Web Frameworks, mojax Moblets do not run within a browser and are not subject to the availability and quality of a network connection. Also, unlike a web application running on a mobile device, a mojax moblet has access to lower level device features such as Camera API, Push Messaging, Bluetooth, Location Services, Contacts and more.

Flash Lite offers great tooling and consistent runtime capabilities/experience but that comes at the cost of slower market penetration and a higher minimum bar for device capabilities.

Flash has several things going for it:

• There is a thriving ecosystem of 1.5+M Flash designers + millions of developers who know how to use what the designers give them. There are dozens of ISVs in the third party ecosystem.

• There is extensive tooling for both designers and developers, including runtime platforms for general applications (Flex) and specific content delivery platforms for carriers (FlashCast).

• Adobe takes a broad approach towards user experiences, including, for example, audio and video as part of the experience. This is why they bought ActImagine in 2006.

• Widgets and smaller apps can offer the same user experience online and on mobile. For example, Mobitween’s games run off of the same codebase on phones and in PC browsers.

Japan is the showcase market for Flash. I’ve heard of staggering differences between the monetization of rich (Flash-based) vs. static content there. Outside of Japan, Verizon Wireless is the showcase operator pushing Flash Lite. Adobe must be very close to ironing out additional deals or there would not have been the contingent of CxO and SVP execs I saw at 3GSM.

The two main things going against Flash are the minimum device capabilities and the price. Moore’s Law helps with the former but not fast-enough. For years Macromedia under-invested in figuring out how to get Flash to feature phones. Now it is an important target for Adobe. Some have raised concerns about Flash Lite being proprietary, closed-source and expensive. All valid points to the extent that it would be more desirable for there to exist a free, standards-based, open-source, ubiquitous, rich mobile device presentation layer. I’ll take that and world peace anytime :) . Delivering and maintaining software across hundreds of mobile devices requires significant investment. I don’t expect to see Flash Lite or the good AJAX-enabled mobile frameworks becoming free anytime soon.

It’s interesting to wait and see where open-source efforts such as mojax end up. My expectation is that they’ll do great on features and will suffer where performance and quality are concerned–those have typically not been the strengths of the open-source community. Unless ODMs and operators contribute significant resources to these projects, it’ll take a long time before they are ready for prime time.

So there it is–the mobile stack of the future: Linux as the OS, Java as the middleware on the phone and Flash/AJAX as the presentation tier.

There are a number of startups working on the Linux front. The Java piece is probably the most scarce in the industry. Apart from SavaJe, no one has done serious Java work on the phone. The presentation tier will be the playground of large vendors (Adobe, Openwave, Microsoft) on one hand and also developer-focussed companies like Opera and Trolltech on the other hand (because they have been historically close to the developer community thereby mitigating to an extent the high costs of ecosystem development and developer marketing).

Finally, it makes sense to ask the question why would operators, especially the large ones, who ultimately control the mobile stack want to move in this direction. Some answers are:

• Lower costs, both for getting new devices operational and for evolving on-device and network services. Also, application certification costs go down significantly.

• Faster time to market, again for both devices and services that integrate with the handset.

• Greater monetization potential of subscribers due to the availability of more content and applications, especially niche content and apps, which are of relevance to niche audiences.

These become particularly important in a world where mobile search and advertising are starting to take a foothold.

Comments

  1. Paul says:

    Just an FYI .. I think you’ve been plagiarized:
    http://universalvoid.blogspot.com/2007/03/idea-mobile-software-stack.html

  2. kostya says:

    Java goes out the window when evaluated against these requirements. There are very few examples of truly engaging user experiences developed with Java. There are not many developers who know how to develop these. Most of the people doing UI work with Java have been in the enterprise domain. This issue isn’t that you can’t build cool mobile apps on J2ME, it’s that there aren’t enough people who know how to build lots and lots of them.

  3. Ranjhith says:

    > free, standards-based, open-source, ubiquitous, rich mobile device presentation layer
    The result is “SVG Tiny”. Its scriptable & can be programmed/manipulated with Java.
    more: http://www.w3.org/TR/SVGMobile12/intro.html

  4. Tony says:

    Ranjhith: It’s all very well to say that SVG Tiny is the answer but there will need to be at least one good cheap implementation for the major platforms before it’s actually useful.