Symbian’s open source challenge

[Will Symbian learn from the iPhone as it transitions to open source? Guest blogger Roger Nolan looks at the challenges iPhone presents to Nokia and its OS strategy.]

Symbian’s EVP of Research, David Wood, posted a well-written response to TechCrunch’s rather ill-founded claims about iPhone and Symbian’s relative market shares. Nonetheless iPhone sales have been surprisingly rapid. The queue to buy iPhones outside the San Francisco Apple Store was something any retailer would dream of, and certainly nothing the mobile phone industry has ever seen.

So what is it about the iPhone that caused this frenzy? Why is the iPhone selling in the US when Symbian handsets do not? Why is the iPhone popular in US whilst it seems to have trouble in other markets?

To understand this, I think you need to understand exactly what Apple have built and what their customers want.

Comparing iPhone to Symbian OS is a little like comparing apples and oranges – or perhaps an apple tree to an apple pie sitting in the baker’s store. Symbian is an operating system without a UI built into many many handsets where iPhone is a single device and set of services. Still we can look at the underlying technologies of iPhone. Many of the initial reviews were quick to point out that iPhone didn’t support MMS – something Apple didn’t even bother fixing in the recent major upgrade to the software. This pattern repeats itself in nearly all areas. Consider that iPhone:
– does not have MMS
– only supports a limited set of multimedia formats
– does not have a forward facing camera
– initially shipped without 3G support
– does not have a unified inbox
– support for camera and Bluetooth is at best utilitarian
– does not have a unified inbox
– shipped without multi-addressing of SMS

The only areas where iPhone software excels are the interface. The use of transparency and animation, the physical size of the screen and UIKit, the fluid multi-touch user interface. iPhone is also backed up with a first class range of services requiring little or no set up before they are used – iTunes, the App Store and (less) mobileMe.

This speaks volumes about how Apple approach their product design and underlines the difference between Apple and Symbian/Nokia. Nokia are fundamentally driven by technology and led by engineers. They drive their products from a list of standards. This approach in turn drives the rest of the handset industry – including Symbian. Apple on the other hand are driven by design and ease of use.

When I see the iPhone I’m reminded of another product that sells surprisingly well in the US; the Sony DCR-DVD108 and it’s predecessors. The DCR-DVD108 is a camcorder that records directly to DVD – unlike the iPhone it is pretty ugly. Like the iPhone it is very easy to use – most of the time. You shoot your video and pop the resulting DVD straight into your DVD player; no tape adapter, no editing on a desktop, just one step. So the iPhone and the DCR-DVD108 both focus on ease of use. They make what 80% of the population want to do quick and easy but abandon the more advanced remainder. For the DCR-DVD108 that means no editing, audio overdubs, colour-correction or title sequences. For the iPhone, no MMS, video conferencing or Bluetooth headphones.

The key here is that US, mass market consumers value convenience and ease of use over pretty-much anything else. Conversely, Japanese consumers are happy to work their way through a poor UI to get at the esoteric functionality they just have to have. I believe that in-general consumers the world over are becoming more like US consumers – and that the amount of functionality in a modern smart-phone increases this tendency.

Symbian’s advantage is also it’s problem
On paper, Symbian OS is much better than the middle-ware and OS of the iPhone. The trouble is that on paper is one thing – in the handset, you just can’t access all that functionality. I assert that the problem is Series 60. It’s not to say that Nokia don’t understand interface design – they went to great efforts to unify the core of their hardware designs and to have S60 software support this. Moving to a Series 60 phone from a Series 40 phone is relatively easy. It is not absolutely easy though. Worse, it’s not easy to find and use all the functionality you paid your N Series tax for. The huge depth of technology in Symbian OS is buried in an ageing and inadequate UI.

It’s a shame because Symbian OS could make a much better iPhone that OS X does. It performs better, has better power management and a robust security model. A Symbian OS iPhone would not have to implement the ridiculous “no background apps” rule nor would Apple have to vet every app quite so closely.

The irony of this is that Psion, the company which developed the foundations for Symbian OS, had enormous focus on UI. David [Wood, EVP Research] himself used to quote Pareto’s 80/20 rule with respect to UI design and functionality – do the 20% of the functionality that 80% of the population want (but spend 100% of the time on it). I.e. focus on making the common uses elegant and easy to use at the expense of more esoteric functionality. “Delightful” was a word you used to hear around Psion when describing what their customers should feel.

Can Maemo show the way?
I’d like to say that Maemo is different. Nokia made a clean start and built a new software stack. Sadly Maemo is also driven from a technology soapbox. This time, it’s not a features arms race, it’s open-source-or-die. The Maemo team did not sit down and say “Let’s build a great UI for an internet tablet” they sat down and said “What can we do with open source” – open source is the religion, not ease of use and making great devices that are delightful to use.

As Symbian becomes the Symbian foundation and transitions to an open source model, I hope that the open source community will take some of the burden of implementing every last codec and piece of middle-ware and the Symbian foundation can focus on UIs and ease of use. Unfortunately, I fear that they will be overcome following Maemo’s open-source religion.

The Opportunity
Nokia are obviously aware of this challenge – they have produced a touch device bearing an uncanny likeness to their new rival and touting an advanced touch UI. In reality, I do not have great hopes for “Touch Series 60”. Or rather, no matter how good this UI is, I do not believe that Nokia will have strong enough product management discipline to leave any of the more esoteric Symbian OS functionality out – or even leave it in but without a UI so that a third party developer can expose it for the 20% who want it.

I’d like to say that there is an opportunity for a new entrant to take the initiative and develop a real competitor to UIKit and a “delightful” set of applications on top of Symbian. Something that uses the great foundations Symbian have built to make phones that are actually better that iPhone. Unfortunately, I doubt this will happen – if anyone fancies a try though, I’d be glad to help out…

– Roger

[Roger has been using phones nearly all his life and making them for nearly on third of it. He has worked at Psion, Symbian, Texas Instruments and Sonopia. He can be contacted on rog at hatbat dot net]

The darker side of Android

[Can an open Android result in a closed phone? Research Director Andreas Constantinou explains why this will not be the exception, but the rule]

Stop signThe G1, the first phone to carry the Android OS has been discussed extensively across the blogosphere. Those expecting an iPhone killer have certainly been disappointed. So have those who expected Google’s first phone to be “truly open” as Google pledged for the Android OS.

The HTC smartphone is locked to the T-Mobile network binding eager fans with a two year contract. T-Mobile won’t allow VoIP applications running on the handset either. Plus you need an GMail account to use the G1, prompting concerns about whether Google is tracking phone usage (neither confirmed nor denied at present). The phone is also pre-packaged with Google services: search, YouTube, GMail, Calendar, Maps and Streetview, as well as access to Google’s Market and Amazon’s mp3 download service.

The source code for Android will be out in Q4 under an Apache 2 license, hopefully shortly after the October 22 launch of the G1. Yet an open source operating system doesn’t mean an open phone.

The darker side of Android
Google’s Android has plenty of unique features to rave about, as we ‘ve covered earlier. But Android also has a ‘dark side’ – aspects which Google doesn’t want to talk about too much. Here’s a short list:

Not a market-ready operating system. While Google provides the source code for the entire application environment to OEMs, it leaves the hardest part of cellular stack integration to the OEM and the hardware platform providers. Stabilisation of 3G stacks is notoriously difficult and involves testing 1000s of corner cases of telephony stack integration (something which is believed to have caused significant delays for Motorola’s L-J platform).

Fragmentation by design. Android uses an Apache 2 license which allows handset OEMs to modify and ship the code without any obligation to share their modifications. At last week’s mobile open source conference in Berlin, Mike Jennings said that the Dalvik virtual machine source code would also be released under APL2. If the virtual machine is open to optimisation changes, this is sure to result in fragmentation by design and interoperability breaks. At the same time it should be noted that software licensed under non-copyleft licenses (e.g. WebKit) is known to resist forking as contributors are incentivised close to the branch where the gravity of contributions are made (Apple’s branch in the case of WebKit). Google offers an API test tool, but clearly what we need is not testing for compliance, but enforcing compliance.

Liability concerns will result in locked handsets. Android source code is promised to ship under APL2. We assume that this is the license under which the Android OS ships to OEMs. Interestingly, APL2 license explicitly disclaims any and all warranties and liabilities. In the world of mobile software, warranties and liabilities are common practice, offering OEMs to ability to pass on liabilities which result from defective software. In plain English, if an OEM needs to recall a few thousand handsets due to a software fault, they need someone to blame. With APL2, Google steers clear of the liability game and passes the burden onto the OEM to self-indemnify or seek third party insurance with expensive premiums. Moreover, OEMs who ship Android phones will not leave any liability holes open; if a third party application interferes with the handset operation, the OEM will be unwilling to pick up the tab. Which means that Android handsets will move access to several APIs off limits to developers. When I asked Mike Jennings about this at last week’s conference he declined to comment, saying he had not been briefed on this issue.

During several months of testing of Android development on the m5 (pre-beta) release, we had uncovered several additional omissions; the emulator left a lot to be wanted (incl. phone call, battery, Bluetooth and other hardware emulation) while the tools for creating UIs were rudimentary.

A key message here is that an open source operating system does not result in open phones. Google’s ‘built it and they will come’ approach does not readily apply to mobile devices for the reasons described earlier.

Clearly, Google has set the expectations too high.

– Andreas

[Update: this article was awarded ‘best post of the week‘ honours at the Carnival of the Mobilists, hosted by Xen Mendelsohn – thanks Xen!]

Capuchin: Sony Ericsson strikes back in the Application Environment…is it a strike? What does it mean for the development platforms fragmentation?

[SonyEricsson is promoting a new Application Environment mixing Java ME and Adobe Flash Lite: Capuchin. Blogger Thomas Menguy tries to describe it and evaluate what “yet a new” development platform means to the industry ].

Sony Ericsson had a nice webinar last Thursday, interesting held through Adobe E-Seminar:

“Flash Lite meets Java ME on Sony Ericsson phones with Project Capuchin”.

At least now we have some information about Capuchin, and I’ll sum it up for our beloved busy executives:

  • A technology that allows developers to make the UI using Flash Lite and code the business logic and access to the platform services with Java (ME).
  • A development environment with PC based tools (Adobe CS plugin for flash and Eclipse plugin for Java), simulators and a specific runtime embedded in SEMC phones.
  • The deployment is done using the well in place Java deployment environment (jar are used, same signature, etc).

Here is first a transcript of the capuchin webcast, then as a conclusion I’ll throw out my thoughts about this and its impact on the industry (if you are still there…).

Project Capuchin Web Cast transcript

Flash  Lite from an SEMC perspective Java ME from and SEMC perspective
Pros

  • Tools
  • Community
  • books, forums, tutorials
Pros

  • Wide platform access: JSR’s
  • Security: MIDP protection
  • Distribution infrastructure using JAR
  • Wide adoption language
Cons

  • Limited system services access
  • No security solution
  • Lack distribution channel
  • memory/cpu consumption
Cons

  • Lack of designer oriented tools
  • no rich UI framework
  • difficult to keep separation between presentation and service layer
  • Designers dependent on programmers in UI dev

 

 

Capuchin is about mixing those two worlds, and enforce UI designers and developers relationship.

Why the Capuchin name : it is a monkey like tamarin…the name of the Adobe Action Script VM.

Here is a high level architecture presentation of Capuchin:

Flash content is embedded into a .jar and can be launched by some Java code, then, thanks to the Capuchin API the Flash Action Script can access the various JSR or any other Java class of the project.

 

Here is below how an accelerometer API may be available in the Flash Action Script of a Capuchin Application:

The Capuchin API works both way: flash to java and java to flash.

What Capuchin is bringing:

Flash development:

  • Extend current limited APIs with the use of JSR
  • Secure Flash application
  • Deploy flash as java games, distribute Flash content through existing java distribution infrastructures

Java Development

  • Clear separation between business code and UI
  • Nice development tools
  • Professional UI tools

How to use Capuchin:

3 main ways to do:

  1. Packaging pure Flash Lite content using jar
  2. Java Midlet using Flash Lite for the UI layer
  3. Java Midlet using Flash Lite for PARTS OF THE UI

Adobe has a nice technology: mxp, format for packaging extensions. Capuchin use mxp to package the APIs that will be mapped into the Action Script.

There is an Eclipse Capuchin Plugin to create those APIs declaration (see above) as they will be usable in the Action Script written in CS3. This tool outputs an XML file which will be used to output Java Classes for the java part to be implemented …. and Action Script classes to be used in CS3.

Everything is then packaged in a .mxp installation package. SEMC will provide some mxp already (Bluetooth , others…)

Demo time:

The webcast then featured a demo:

swf2jar :

Goal here was to show the tool to convert a swf to a jar, swf2jar: very useful for packaging because a flash game today…end up in the image folder when deployed in a SEMC phone :-)….

Calendar component:

Project Capuchin plugin for CS3, with mxp packages. The intent here was to show how to use Java services in a Flash Lite content

There are some “Platform components” in the library:  in the AS editor, it is possible to import for example the package com.sonyericsson.capuchin.calendar.Calendar

… to import the Platform classes,  so it is now possible to use the Calendar class as a normal Action Script, even if it is a Java Service.

 

One word about the toolchain future:

In gray: Not done today:

  • Flash Emulator will be connected to Eclipse to use java services directly and not only stubs
  • UI library: a flash widget library will be developed
  • Connect everything to the existing SEMC phone emulator
  • Work with adobe so that in device central, when a SEMC phone is selected the list of available mxp would be provided.

What will be published soon:

  • First phone : C905, compatible with capuchin APIs
  • Capuchin APIs,Java Classes
  • swf2jar tool
  • Capuchin API generator , eclipse plugin
  • mxp packages with source code
  • capuchin test and video tutorials
  • demos applications

=>check here http://developer.sonyericsson.com

(final: October)

SEMC Capuchin will be present at Adobe MAX in San Francisco and in Italy in December!

Some Q&A with no major questions…mine were not answered:

  • What is the implication of Adobe in this project?
  • What is the implication of Esmertec in this project?
  • Is there a roadmap to have Capuchin on other platform than SEMC ones?

 

Some points about this initiative:

 

  • SEMC has already done a large part of their applications in their feature phones in Java, and they have a strong Java commitment with Esmertec, so on SEMC phones Java is the preferred development method internally….and now with Capuchin, externally as nearly all the platform services are already available in Java.
  • With the point above, and knowing that some part of the SEMC feature phones themes are already in Flash, merging Flash Lite and Java was a natural choice for SEMC

 

  • Flash Lite choice is the only one possible for today mobile phones (CPU/Memory)…but is really not a complete and efficient UI application frameworks, it lacks …widgets! So SEMC plan to develop some new ones, hum wait, Adobe Flex is not about that? Bringing application development to Flash?

 

  • Not sure about the porting of such a technology on other platforms than SEMC … but from my knowledge only another one has made the Java choice: Google Android where all the platform services can be accessed through Java, but I don’t see any incentive for SEMC to port it to Android

 

Conclusion

So we have a new Application Environment, with its own SDK, that will certainly be only available on SEMC platforms….Capuchin one will complete this never ending list:

  • iPhone native/iPhone SDK
  • iPhone Web Apps
  • S60
  • Nokia Qt
  • UIQ (oups, RIP)
  • LIMO
  • Maemo
  • Motorolla WebUI
  • Android
  • J2ME (and all its flavors …)
  • Capuchin
  • Flash Lite
  • Flash/Flex/Air
  • Brew
  • WinMob
  • PalmOS
  • BlackBerry
  • …and so on…

 

Are we still talking about cross platform development? About consolidation and standardization?  NO

The industry is pushing the other way, and really this is NOT AN ISSUE.

Services and applications developers have learnt how to reuse code across platforms, how to architect their code and services so that it is easy to change only the presentation and the adaptation to the platform: after all developing a UI for a 800*480 screen and a 176*220 is just something completely different, and really not a big deal if your UI is uncorrelated from your services; Capuchin helps that, as many other technologies.

All those new Application Environments are bringing to Mobile Platforms  great core value for services deployment :

  • openness
  • great tools, ease of development
  • focus on user experience and UI
  • deployment/packaging/distribution strategies
  • security

And we don’t want a “one size fits all” environment, it is simply not true in an industry where the forms factors, capabilities and designs are so vastly different. Differentiation is key in this market, just open the platforms with nice and open development technologies, it is enough!

One big trend we can foresee also is that the platform vendors have no more software complex, and when you look at the list above, nearly all the initiative are coming from OEM, and not really from pure software companies (notable exceptions: Android and WinMob)….PC based paradigm seems soooo far away!