I’m struck by the following comment from Tim Howes in response to my previous blog about the relation between Symbian and Maemo:
What I don’t understand is when Nokia fund the development thrice over (in a poor economic climate too) of detailed code to yield technology that is hard to get right: example Bluetooth. Bluetooth is hard to get right because of its peer-peer application level interoperability.
The Symbian version of this technology has shipped in vast numbers and has “hardened” as a consequence. Should not Nokia be investing effort to port that over to Maemo rather than fund developers to do it all over again?
Can the insurance plan be componentised like good software? Can good software be re-used in different architectures – if it’s good enough for the applications (Qt, PIPS based apps), why isn’t it good enough for “sysem” components?
The question brings to mind some important failure modes in the strategies a device manufacturer (or other mobile industry player) can adopt towards mobile software platforms.
The first failure mode is when a device manufacturer fails to have a strategy towards mobile software platforms. In this case, the adage holds true that a failure to strategise is a strategy to fail. A device manufacturer that simply “follows the wind” – picking platform P1 for device D1 because customer C1 expressed a preference for P1, picking platform P2 for device D2 because customer C2 expressed a preference for P2, etc – is going to find that the effort of interacting successfully with all these different platforms far exceeds their expectations. Mobile software platforms require substantial investment from manufacturers, before the manufacturer can reap commercial rewards from these platforms. (Getting a device ready to demo is one thing. That can be relatively easy. Getting a device approved to ship onto real networks – a device that is sufficiently differentiated to stand out from a crowd of lookalike devices – can take a lot longer.)
The second failure mode is similar to the first one. It’s when a device manufacturer spreads itself too thinly across multiple platforms. In the previous case, the manufacturer ended up working with multiple platforms, without consciously planning that outcome. In this case, the manufacturer knows what they are doing. They reason to themselves as follows:
- We are a highly competent company;
- We can manage to work with (say) three significant mobile software platforms;
- Other companies couldn’t cope with this diversification, but we are different.
But the outcome is the same as the previous case, even though different thinking gets the manufacturer into that predicament. The root failure is, again, a failure to appreciate the scale and complexity of mobile software platforms. These platforms can deliver tremendous value, but require significant ongoing skill and investment to yield that kind of result.
The third failure mode is the one I want to highlight in this posting. It’s when a manufacturer seeks re-use across several different mobile software platforms. The idea is that components (whether at the application or system level) are developed in a platform-agnostic way, so they can fit into each platform equally well.
To be clear, this is a fine goal. Done right, there are big dividends. But my observation is that this strategy is hard to get right. The strategy typically involves some kind of additional “platform independent layer”, that isolates the software in the component from the particular programming interfaces of the underlying platform. However, this additional layer often introduces its own complications:
- It can decrease run-time efficiency: there are more levels of translation involved, and (in some cases) more intermediate copies of data;
- It can obscure the full set of interfaces provided by the more powerful platforms;
- It takes considerable effort to maintain it – effort that would arguably be better deployed to create differentiation in the actual devices.
In other words, these intermediate layers often turn out harder than expected. They consume more resources than expected – more system resources at runtime, and more human resources to create them and maintain them. And they distract the manufacturer from focussing on its own unique value-add.
Of course, there’s a recurring theme here. The theme is that platform software is hard. It’s hard to create platform software in the first place. It takes time to learn how to take best advantage of any particular platform software. And it’s hard to create intermediate platforms.
That’s why it’s important for the industry to pool resources in the creation of first-class mobile software platforms. Rather than manufacturers deploying lots of resources at platform level software, only to end up with devices that look very similar to the crowd, they should deploy these resources on unique differentiators – such as compelling consumer experience, unique services, attractive design themes, and breakthrough device form factors and usage models.
From the previous blog post: “To my mind, it makes perfect sense for phone companies to investigate at least two modern mobile operating systems.”
From this one: “The second failure mode is similar to the first one. It’s when a device manufacturer spreads itself too thinly across multiple platforms.”
Reconcile…?
Hi David,
What you’re saying is basically that device manufacturers must choose a single platform unless they’re prepared for the challenges posed by having to maintain multiple platforms. Which is seldom the case according to you, since you mention “failure modes”. Tell me then why on Earth did all other manufacturers than Apple choose exactly the same model as what you’re criticizing?
Ok, I think I know that your first thought is “again, being compared to iPhone”. I’m fully aware of that the analogy is not perfect, since Apple is concentrating only on a tiny fraction of the mobile industry (though it seems to be the most profitable), thus they’re not facing with the decision of having to choose another platform. Still the question is valid: why do companies choose multiple platforms if the equation is so simple?
Hi Gabor,
Just because nearly every manufacturer follows the same course – spreading resources across multiple operating systems – does not mean that course is the best one to choose.
One thing Apple reminds us all is the value in doing one “insanely great” thing well, rather than seeking “many potentially good” things.
I’m also reminded of the principle of The Hedgehog and the Fox: “The fox knows many things, but the hedgehog knows one big thing.”
Jim Collins, in “Good to great”, throws down an excellent challenge to all organisations regarding “The Hedgehog Concept”. See eg here. If more device manufacturers took this principle to heart, I expect they would attain greater success in their shipments.
// David W.
Hi David,
Thanks for your response! Having followed the link about “The Hedgehog Concept” I have a seemingly simple question (which is the 2nd question in the referred web page): “What drives your economic engine”?
Even I can easily answer the first question (“What you can be the best in the world at”), since you have already shown the world that. It’s pretty obvious what you would answer to the third question (“What you are deeply passionate about”), too. Nevertheless, I’m worried about you answer on question #2: whilst Apple drives its own engine the same doesn’t apply to Symbian (and to the rest of the industry, btw), where the engine is driven by more and more companies due to the nature of being open. And even though I’m not afraid of Symbian being in danger at all, I can see that it will rather be (hopefully very) good than “insanely great”.
Hi Gabor,
>What drives your economic engine?
Or, to quote the Jim Collins question in full,
>All the good-to-great companies attained piercing insight into how to most effectively generate sustained and robust cash flow and profitability. In particular, they discovered the single denominator—profit per x—that had the greatest impact on their economics. (It would be cash flow per x in the social sector.)
Things are a bit different for the Symbian Foundation – and indeed for any other open source foundation – since we are constitutionally non-profit. We don’t exist to maximise profits for shareholders. In fact, we have no shareholders.
Instead, we exist to provide satisfaction to our member organisations. They are looking to achieve various things, through their membership of the foundation community, that they could not achieve (so well) by standing aside. For example, they are looking for independent governance of the software platform they all depend on. And they are looking for management and support of a shared developer ecosystem.
But the Jim Collins question is still pertinent. For the Symbian Foundation, it turns into the following form:
What is the ‘x’ that the Symbian Foundation can do, which will deliver the greatest satisfaction to our member organisations (and thereby ensure they will continue to pay their membership subscriptions)?
Rather than blurt out my own answer to that question, I’ll first wait and see what suggestions people offer here (or elsewhere).
// David W.
Here’s a real world experience of mobile platform failure. Nokia with s60 v3rd FP1 phones and then s60 v3rd FP2 phones. Where even though they are the same underlying OS “S60 v3rd” Nokia seems to be unwilling or not allow users who have FP1 phones upgrade to FP2 phones. On top of that every phone that is released with s60 v3rd seem to all have a different feel to them or different version of it so as a user you end up thinking “hey why do I not have that on my phone or why only that phone? When I have the same OS too”. I guess they want you to buy a whole new phone to get something that in reality you should get the updates on your current phone (imagine if you had to get a whole new computer to run XP SP3 when you only had XP SP2). That essentially divides the OS in two, which doesn’t make sense and as a end users make me feel left behind. Which is a reason I will no longer look at Nokia for future phones unless they change their ways which I doubt that. More support should be given to the OS. I think that’s the idea of symbian foundation right? Will the symbian foundation be the one to distribute updates of the OS to users first hand, not going through a phone a manufacturer that then decides to release it to the users? I only ask that since the foundation is “independent” non-profit org that has members that are from different companies (cellphone manufacturers are a part of it) with their own voting rights.
Hi Lu,
>… every phone that is released with s60 v3rd seem to all have a different feel to them or different version of it so as a user you end up thinking “hey why do I not have that on my phone or why only that phone? When I have the same OS too”.
By itself, that’s not a “platform failure”. A good platform will allow plenty of different implementations of look-and-feel on top of the platform. Different users will prefer different implementations of look-and-feel.
>I guess they want you to buy a whole new phone to get something that in reality you should get the updates on your current phone (imagine if you had to get a whole new computer to run XP SP3 when you only had XP SP2)… Which is a reason I will no longer look at Nokia for future phones unless they change their ways which I doubt that. More support should be given to the OS.
The Symbian platform already supports mobile devices being software upgradeable – and has done from the beginning.
>Will the symbian foundation be the one to distribute updates of the OS to users first hand, not going through a phone a manufacturer that then decides to release it to the users?
Yes, end users will be able to obtain versions of the Symbian platform, from the Symbian Foundation website. However, as explained here, there’s a lot more that goes into an actual device than merely the Symbian platform. In general, if you change the Symbian platform version, you’ll also need to change some of the other files, because of internal (platform API) dependencies.
I’ve covered the subject of software upgrades on phones in more depth here. (Though, since people keep asking questions about it, it’s probably worth a new discussion…)
// David W.
Hi David,
Let me be the devil’s advocate by posing the following question: Isn’t web kit a good example of a successful, cross-platform system component? It is used across S60, OSX, and Android. Would it make sense for the industry (and hence the Symbian Foundation) to create more system component projects, like webkit.org?
Hi Morten,
You’re right, Webkit is a good example to discuss, of a comparatively successful cross-platform system component.
Two points I would make about it are:
1.) Unfortunately, the implementation of webkit isn’t the same on all the device platforms you mentioned. There’s been some fragmentation along the way.
2.) This reinforces my general thesis that these cross-platform system components are hard!
>Would it make sense for the industry (and hence the Symbian Foundation) to create more system component projects, like webkit.org?
I completely agree!
// David W.
>> Would it make sense for the industry (and hence the Symbian
>> Foundation) to create more system component projects, like webkit.org?
> I completely agree!
Very interesting!
Does that mean that the Foundation would consider, for example, sitting down with the developers for other open source OSs and consider joint planning for common components?
Hi David,
>Does that mean that the Foundation would consider, for example, sitting down with the developers for other open source OSs and consider joint planning for common components?
Definitely. “Collaborate before competing”.
Dalvik comes to mind as a potential example. A version of Dalvik that runs on the Symbian platform could open many opportunities.
// David W.
> Definitely. “Collaborate before competing”.
Fascinating.
Aim towards a common platform for web runtime widgets across Symbian, Android, Palm Pre, etc?
Hi David,
I completely agree; it has often perplexed me that it’s taken time for a realisation that there isn’t trememdous relative value (never mind the cost) of re-developing the system layers of an OS. There was much room for innovation in the UI layers, or even just developing some cool apps to build in (too often it seemed that reference to download the cool stuff was given). That innovation often stalled (and still is) while relatively unnecessary duplicate development (with huge ongoing maintenance cost) happened at the lower layers.
One point that is probably worth adding/drawing out – debating the worth of a platform or platformised product, rather than a bag of bits, can be surprisingly (?) hard. Perhaps it isn’t too surprising when all too often, in many walks of life, short termism dominates. Very often there are nods as to the value (and perhaps nods to self-develop yet another platform) – just as long as it doesn’t compromise the needs of the “now” derivative products, or that the “boring” maintenance doesn’t get too much of a burden…
>Dalvik comes to mind as a potential example. A version of Dalvik that runs on the Symbian platform could open many opportunities.
The article Canonical developers aim to make Android apps run on Ubuntu provides more ideas on how this could work. (The comments are worth reading too.)
Is anyone interested in exploring this further?
// David W.
>Dalvik comes to mind as a potential example. A version of Dalvik that runs on the Symbian platform could open many opportunities.
Here are two other posts that explore the same question (thanks to Simon Judge for the links):
*) Is Dalvik the New Java?
*) Will Java have a place in the future of mobile devices?
// David W.
Interesting post and comments. My concern with cross-platform frameworks has always been the affect they can have on end-user experience (and this is true not just for phones but also PCs, game-consoles and possibly other software-driven kit too).
It’s all well and good when you’re working on some behind-the-scenes logic (if you don’t need to re-implement the same algorithms for x different platforms then that’s generally a good thing for developers) but when it comes to the UI side of things I think there’s a temptation for app developers to just go for the lowest common denominator and not design UIs that look and feel right for the target OS.
For example, I use a Mac at home and use the GIMP as my main graphics program. GIMP is built using GTK and is available for Linux, Windows, Mac and probably a whole bunch of other systems too. On Linux in the Gnome desktop environment it fits in with the look and feel of everything else and is great. On Windows it’s a similar story (though the appearance of some UI elements is bit off). On Mac OS X however it’s very different to “proper” OS X apps. It runs inside X Windows so the switching focus between the windows is a bit weird, the look of the buttons and other UI widgets isn’t quite OS X and the menu bar is on the windows as opposed to the top of the screen.
Don’t get me wrong, I still love and use GIMP a lot, but it’s an example of how portability can hurt the UI when not done right. There are other examples like Firefox which do a much better job of fitting in but even they are not perfect.
I believe the same is true for phones. Most cross-platform phone apps I’ve seen tend to just do away with the usual S60 / UIQ / WinMo look and feel and impose their own totally different one. Games can perhaps get away with this, but on other apps it quickly gets tedious. (e.g. standard menu items are not there, softkeys don’t behave the way you’d expect, platform-specific things like the pencil and ‘C’ keys on S60 or the ‘back’ button on UIQ phones don’t behave as they should etc.)
I think an app that uses native APIs and frameworks and follows the target OS’s UI style and interaction guidelines will almost always look and feel better to the end user than one that doesn’t because it’s trying to look/behave in a way that happens to work on X different systems. Of course, the trade-off is increased developer effort for each additional platform they wish to support.
I guess the challenge therefore is to provide developers with the ability to easily mix cross-platform and platform-specific APIs in their apps. Take for example a business card reader app. The algorithms to do processing and OCR on images from the camera ought to be portable. (Basic) access to a camera to show a viewfinder and grab pictures ought to be portable too. So, for both of those I’d expect to have one set of code that you can just compile for different OSes. However, the UI code should be customisable to fit in nicely with different systems so there you may have separate sets of code for each OS. Furthermore you might want to add platform-specific extras. Like on
S60Symbian^N you may want to add an option to the menu within the native contacts app like “Scan biz card” or you may want to link into the image gallery to provide an option to process photos of cards you’ve already taken. AFAIK (happy to be corrected here) iPhone OS does not allow apps to integrate themselves into the native contacts and gallery apps so for the iPhone build you would omit those things (and perhaps add others instead).If Qt, Dalvik ports or anything else can deliver the above great. If they just mean I’ll get Android-looking-and-feeling apps on my Symbian phone (or vice versa) or lazy ports of KDE apps on my Symbian phone then (with my consumer hat on) I won’t be too happy.
> If Qt, Dalvik ports or anything else can deliver the above great. If they
> just mean I’ll get Android-looking-and-feeling apps on my Symbian
> phone (or vice versa) or lazy ports of KDE apps on my Symbian phone
> then (with my consumer hat on) I won’t be too happy.
Interesting. Is it better to have an app with a non-standard look and feel or no app at all?
Qt and Dalvik are great (for C++ and Java) but, risking the danger of repeating myself from above, a common platform for web runtime is what interests me.
Developing WRT widgets is quick and powerful and builds on the extremely wide knowledge of HTML, CSS and Javascript so that potentially millions of web developers become mobile application developers with next to no retraining.
All that would be needed was an agreed specification of support for the technologies I mentioned above and a certain set of supported Javascript objects/APIs (security, contacts, location, etc).
Would the Foundation in principle be interested in sitting down with Google, Apple, RIM, etc to discuss building a specification for such a common platform?
Hi David,
>Would the Foundation in principle be interested in sitting down with Google, Apple, RIM, etc to discuss building a specification for such a common platform?
I don’t want Symbian to re-invent the wheel here. Existing frameworks such as BONDI from OMTP already meet many of the requirements for rich but secure access to phone functionality from web applications.
What I am looking for is a serious offer from someone to contribute a Symbian implementation of BONDI to the Symbian code repositories.
// David W.
David & David,
Let me point out that these technologies (Qt, Dalvik-Java and Web run-time) complement each other, since there are areas where one performs better than the rest. WRT widgets are not the ultimate solution for everything and having Dalvik “on board” would open up a new interesting world.
As for “looking for a company to provide a ready-made BONDI solution”, well, it’s the passive behavior. I know that you can talk only on behalf of SF, which is very-very limited in terms of in-house development, but I tend to agree with the other David that these companies should sit together and come up with a solution common to multiple mobile platforms. Maybe based on BONDI or something else. I know that the power of open source is that you don’t have to do everything yourself, I just wonder how long will you have to wait for a BONDI-compliant solution and what you lose by letting the years pass until someone will finally provide that solution.
Gabor
I’m also frustrated by the seeming complete lack of progress in some of these areas.
In this thread are a couple of examples of things which are “obviously” interesting ideas that have been discussed quite widely around the mobile community: ‘Dalvik VM (and wider Android runtime environment) port to Symbian’ and ‘Common web runtime framework’. As I see it, the Symbian Foundation is the ideal place for these discussions to take place and contributors to be encouraged. We also have the framework to do it. If we think these things are worth discussing then why not propose them to our own Feature and Roadmap council, if there is interest from members then working groups can be created and development plans, dividing up the work appropriately between members agreed in those. If our members aren’t going to do these things then who is? As Gabor says, if we sit around waiting for someone to volunteer to contribute something, the risk is that all of our members are also sitting there waiting for someone else to contribute the same thing.
Isn’t is also our place to get the ball rolling? It seems that in the one case (Dalvik VM port), with appropriate will and funding, an open source port could be started immediately. Its much more likely to happen if interested members can be brought together and agree to share the costs than waiting for someone to volunteer to do it alone and then everyone else benefit.
In the other case (common web runtime) I suspect there will be significant politcs surrounding the solution regarding implementation technology, but at least the Symbian Foundation could be a good place for those discussions to happen.
Just my 2p.
Does this come down to the Foundation having someone whose remit is “common platforms liaison with other mobile platform developers” (or something similar but not so clunky)?
Ie, will someone from Symbian be sitting down with someone from Google, Palm, RIM, etc on a regular basis to discuss these things?