The mobile world has been thrown into turmoil by the iPhone, and everyone is scrambling to get onto the touch-and-app-store bandwagon and to innovate their way ahead.
These are interesting times. For example, thanks to a remarkable move by Nokia, Symbian is now going to be made Open Source over the next year or so, joining Linux as one of the big two Open Source mobile operating systems.
There has recently been some discussion at CTIA about what should be the focus of the newly-formed Symbian Foundation - steward of this complex operating system and its S60 wrappers. Should it jump on the iPhone bandwagon?
I believe that the Symbian Foundation should in fact use Linux, not the iPhone, as its reference standard when setting priorities... ...
The mobile world has been thrown into turmoil by the iPhone, and everyone is scrambling to get onto the touch-and-app-store bandwagon and to innovate their way ahead.
These are interesting times. For example, thanks to a remarkable move by Nokia, Symbian is now going to be made Open Source over the next year or so, joining Linux as one of the big two Open Source mobile operating systems.
There has recently been some discussion at CTIA about what should be the focus of the newly-formed Symbian Foundation - steward of this complex operating system and its S60 wrappers. Should it jump on the iPhone bandwagon?
I believe that the Symbian Foundation should in fact use Linux, not the iPhone, as its reference standard when setting priorities...
Porting from Linux to Symbian
I'm writing an application called Cilux for the Linux-based Maemo platform, and loving it. I use classic Linux tools like gcc, vim, make and git.
Now, soon I'm hoping to trade in my disappointing Xperia X1 for a beautiful new Omnia HD, which is based on Symbian and S60 v5.
So naturally I want to port Cilux to the Omnia HD; and thence to the Sony Ericsson Idou.
I've written Cilux to have a strict boundary between its functions and the underlying operating system through an abstraction API. I've done it for Win32, and it was ugly, but not too bad. So it's only the Symbian implementation of that API that I'll need to code up in order to port Cilux to my new phone.
Symbian Pain
But there is much evidence that it's going to be a pain compared to the Linux, and even the Win32 port. There is an article on Simon Judge's Mobile Phone Development blog comparing coding pain, where Symbian comes out looking rather hard. There's a poll on the Fleasome site which says much the same. And an article on Wap Review calls Symbian native development 'notoriously difficult'.
What I want is to develop my Symbian port in my comfortable Ubuntu environment, using all my familiar Linux tools. What I want is to have standard C operating system APIs. I want to have full access to the latest available hardware. I hope I won't have to rely on Samsung to provide drivers for the OpenGL ES 2.0 API into the OMAP3 chip, meaning a possible re-port for Sony Ericsson's device.
Also, here's a recent article referring to Symbian's instability in the face of multiple, badly-behaved applications. I want Symbian to be as reliable as Linux. I certainly don't want a repeat of my experiences with Windows Mobile.
Linux and its common libraries and tools is the reference standard by which I'll inevitably judge my Symbian porting and running experience.
Less Innovation, Less Fragmentation
Linux is a workhorse. Its development is largely about being robust and keeping up with hardware advances, rather than innovation. The community nature of Linux development tends to work against dramatic innovation and discourage fragmentation.
You can get 3D interfaces, you can get VMs for Linux to run Flash and Java, you can run Javascript in browsers - but apart from base Firefox, these are not the priority of those that put together distributions. You won't find much in the way of trendy app stores in the Linux world - instead, enjoy the luxury of Debian package management, which allows stable distributions of tested code, whose interdependencies are all taken care of.
The Moblin mobile Linux distro has been handed over by Intel to the Linux Foundation. But its potential to meet the innovative visions Intel had for its Moorestown chips is now unlikely to be realised, because the Linux community simply has different skills and priorities. Without the kind of input a commercial enterprise can deliver in areas like style and information architecture, Moblin will be just another mobile Linux distro.
Two other mobile Linux distros - the rhyming pair Maemo and LiMo - have been criticised by industry-watchers Vision Mobile for being too, well, boring. Vision Mobile hope that Maemo's Open Source culture won't drag Symbian down and that both Symbian and LiMo will jump on the iPhone bandwagon.
But a mix of dull reliability and adaptability is Linux's strength. It comes partly from the cross-pollination of the various collaboration groups. For example, I now forsee some Maemo/Moblin collaboration on the horizon, especially since they share the Clutter UI toolkit.
Symbian's Competition is Linux
In contrast to Vision Mobile, I believe that the Symbian Foundation would do well to copy the Linux model while opening up Symbian and S60.
Symbian/S60 are now competing with Linux and its ecosystem. The Symbian Foundation thus needs to learn a few lessons of a well-behaved Open Source operating system and basic application environment.
It should start with understanding the ways of an Open Source community. Of course it'll take more than a jolly logo and 'branding' - however sincere in intent - to achieve that culture shift, especially with such a weight of Symbian and S60 developers still working for Nokia.
How Symbian Can Support Innovation
The Symbian Foundation should support innovation in mobile by being the most responsive provider of a stable mobile OS and full range of packages and drivers that are easy to program over, using Linux as the standard to aspire to.
The Symbian Foundation should focus on things like ease of writing and porting applications, and stability of the operating system in the face of poorly-written code. They must give developers a wide range of easy ways to make solid Symbian or S60 applications that exploit the hardware and give full access to device functions.
Like Linux, the Symbian Foundation should keep its operating system up-to-date with hardware advances - fully supporting capacitive touchscreens, accelerometers, GPS, OpenGL ES 2.0 chips, etc.
They should bring dependency-managed, tested package delivery. They should stay the provider of the 'Symbian distro' of choice, by leveraging their control over the Symbian modules and over Symbian Signed, thus preventing fragmentation.
Not Competing with the iPhone
Linux, in the form of LiMo, Maemo or Moblin, is unlikely to compete with the iPhone, or other 'convergence devices', by itself.
Likewise, Symbian is no longer competing with the iPhone, or its old enemy, Microsoft's Windows Mobile. These are full-stack, closed systems under a single central control that is entirely market-driven. The core is opaque, the innovation is entangled in opaque priorities and roadmaps; the future of your precious software and startup is uncertain.
But when Linux or Symbian is taken by a third party and used to deliver a full package of innovation over the top, then they could create great, competitive products.
Android and Palm WebOS are two good examples of Linux-based platforms where the fun stuff, the user experience, happens away from the kernel in runtime environments or VMs - Java and Javascript respectively - and in online services.
The Symbian Foundation should resist the temptation to commit resources to Symbian-approved and promoted VMs or runtimes for Java, Flash, Javascript, etc. They should resist the temptation to develop Symbian Widgets or 3D user experiences. They should resist the temptation to develop a "Symbian App Store", or a "Symbian Cloud Services".
Building on Symbian
They should leave all these innovations to Nokia, Samsung and Sony Ericsson, who are focused on their markets - and learning fast.
Looking at Nokia's 5800 and N97 in the brilliant light of Samsung's Omnia HD and the Sony Ericsson Idou leaves one wondering what Nokia will do next to leapfrog the others using the same platform, hopefully on better chips than the Freescales.
Handing over the reins of S60 downwards, even if not the development, will leave Nokia free to refocus from a techie company to a Mobile 2.0 innovator - to really get their teeth into bringing us a "delightful" user experience, based around Ovi and the work of Nokia Labs. Perhaps with an emphasis on Flash and Web Runtime.
Although, having said that, there should be no concern about Ovi unleashing a large number of well-tested native S60 apps onto a stable Symbian distribution. And native apps fetched from Nokia Ovi should run on compatible Samsung devices without alteration - and vice-versa.
Strong Future
Not so trendy for Symbian Foundation, but at least this will ensure Symbian has a strong future, in an environment where Linux is increasingly showing its strengths.
There is actually already plenty of evidence that Symbian is going in the right direction. For example, the Open-C APIs are intended to help those porting from standard environments, and there are some improvements to the coding idioms. There are plans to improve Symbian Signed and the code modularity. Finally, the recent endorsement by Symbian of an OMAP3-based dev kit presumably means they'll also be bringing out the OpenGL ES 2.0 drivers and APIs.
For me, a more Linux-like Symbian 'distro' and tools will make porting Cilux from Maemo something to look forward to...
Mobile Monday London met last night to discuss the Mobile Web and Widgets. It was an engaging and thought-provoking evening.
Your intrepid reporter was there and, in spite of the crashing of his sad, clunky old Windows Mobile Xperia X1, losing all his notes, he brings you this hot report from right out of his memory (somewhat steamed up by subsequent socialising, but reclarified by Google).
After that, I give an explanation of why I believe that Widgets are not the solution to what Mobile 2.0 needs... ...
Mobile Monday London met last night to discuss the Mobile Web and Widgets. It was an engaging and thought-provoking evening.
Your intrepid reporter was there and, in spite of the crashing of his sad, clunky old Windows Mobile Xperia X1, losing all his notes, he brings you this hot report from right out of his memory (somewhat steamed up by subsequent socialising, but reclarified by Google).
After that, I give an explanation of why I believe that Widgets are not the solution to what Mobile 2.0 needs...
GSMA ONE
First up was Kevin Smith from Vodafone to tell us about the GSMA ONE Web API (also via here). ONE means 'Open Network Enablers'. It seems quite similar to the Web21C initiative by BT, led by my good friend Paul Downey, but which was unfortunately set aside in favour of Ribbit.
You can send an SMS, get a user's location and access billing and connection info. All through a scary STREST interface.
Scary because it looks like you can send a text using a GET... The documentation here [PDF] does suggest using POST, but even so, the design fundamentally wants Resource-Orientation in place of Service Orientation:
The message appears to be tacked on to the URL as an argument. There are references to 'soapUI', endpoints, etc. An SMS message doesn't appear to have its own URL, just an internal message ID. There are 'exceptions thrown', all with a 400 code, even for internal platform and integration faults. And so-on - in classic STREST style!
Still, nothing that can't be fixed with a little help from a REST dude, or a read of "RESTful Web Services".
OMTP BONDI and Ikivo
Next, Nick Allot told us all about OMTP BONDI, which is an attempt to ameliorate fragmentation in the mobile Web and widget space - the one which allows access to parts of the phone not normally reached in a browser: PIM, SMS, camera, GPS, etc.
Their big thing is security: take widgets out of the safety of the browser and give them access to the phone via APIs, and you have a potential security nightmare.
Seems BONDI will let you do most Mobile 2.0 native-like applets, such as LBS, photo-sharing, etc. There's a reference implementation for sad, clunky old Windows Mobile, and both Opera and LiMo are jumping aboard, too.
BONDI aims to be W3C compatible where possible. Not HTML5, mind, but rather a works-now, fit-for-purpose solution to the fragmentation problem, that includes widgets and may later converge with HTML5. There's an excellent discussion about this on WAP Review.
This was followed by a talk by Samuel Sweet from Ikivo. It seems that, starting with their successful Samsung T*Omnia widget interface, Ikivo have been overcome with standards love, and are going BONDI as well as W3C compliant, especially with SVG as a rendering technology.
Firefox for Mobile
Christian Sejersen of Mozilla gave a good intro to what is currently called Fennec - Alpha 2, but will soon be renamed the more grown-up 'Firefox'. It's got the same code in it after all: and APIs such as camera and location that get added to the common codebase will be accessible via both mobile and desktop.
Looks very swishy and touchy and in sync with the times. Available now on Maemo (and Moblin) and soon on sad, clunky old Windows Mobile. Then later this year on Symbian. Codebase is C, so no Java or Javascript phones supported, of course. Or closed walled-garden proprietary locked-down phones like, um, the iPhone. It seems that the add-on community is already fixing up their plugins for this mobile version without even being prompted. No news on the Prism widget-alike system, to compete with BONDI or Opera. It's "still in the labs"...
Panel
Then the panel session started, with the best questions from the excellent host, Dan Appelquist of Vodafone, and some good ones from the audience.
There was much elaboration and clarification on the presentations (thus included above instead), and an interesting conversation around monetisation: how do widgets make money? Three suggestions: adverts, selling widgets on an app(let) store and micro-payments. Graham Thomas of T-Mobile appeared to be happy just to get more Internet traffic for now..
There was also confirmation from Graham that Web'n'Walk 4.0 will major on widgets, but he didn't say what flavour. More hot journalism uncovers this confirmation [PDF] (page 29) that it's still going to be tied in with Opera.
The outstanding revelation of the evening (sorry Ikivo!) came when someone told us that the Palm Pre's widget system is not only proprietary, but uses tables for layout! The horror! Lots of tutting and W3C-like smugness around the room.
Following Open W3C Standards can still break the Web
The goal of all this standard widget aspiration, apart from the obvious motivation of being able to compete with the iPhone, is to allow everyone to write widgets, and for those widgets to work on all our phones.
However, just because everyone does what the W3C thinks they should do doesn't mean you automatically get interoperability. Most importantly, doing what the W3C wants doesn't mean you won't break the Web!
The W3C, don't forget, also brings you 'Web' Services - those mis-named standards responsible for much Web-breaking, including inspiring a whole generation of Web-breakers with their STREST interfaces.
Interoperability on the Web is about state transfer, content types, URLs, hypertext. No amount of API and widget standardisation will give classic Web interoperability as long as they ignore these Web basics.
A widget is an applet is an application. It's a closed structure whose data interoperability has to be hard coded each time, and whose imperative Javascript naturally wants to make function calls back on the server - probably through HTTP.
And you run either this application or that, each having its own way of pushing or pulling data around, or even the same data presented in much the same way all over again.
In the Web you run one browser application and everything is mashed within - data interoperability.
The U-Web gives us the best of both worlds
Admittedly, the basic Web isn't good enough by itself when seeking an architecture for Mobile 2.0's essential personalisation, interactivity and usability.
But that doesn't mean that we should throw away the Web's hard-won advantages of interoperability and scalability, that we perhaps take too much for granted.
Enter the U-Web! The U-Web "puts the Web back into Web 2.0 and Mobile 2.0".
It takes the best of the Web's one-way static document publishing model, and extends it to a two-way dynamic data exchange model, while keeping the interoperability and scalability of the Web.
Instead of working on widget standards that break the Web, let's standardise a fully Web-compatible Mobile 2.0 architecture that delivers the same rich, personal functionality, but adds back the seamless mashability of ever-changing people and their ever-changing stuff. Oh, and promises scalability and rapid, easy development.
I've kicked off the project with the U-Web proposal - perhaps you'd like to jump in and help? Email me (see left bar) or leave a comment.