UPDATE: I want to make clear that Chris, who authored the post below, is a developer not an employee of Symbian. The views he articulates are interesting though controversial. From my point of view as editor of the blog they are interesting because Chris is relatively new to Symbian and committed to using it in his business. I think that provides us with a perspective we should engage with. From time to time we run perspectives from members of the eco-system.
“I wanted to take a step back from the technical posts that I’ve submitted recently to ask a higher-level question about Symbian and where it’s headed. Basically my confusion boils down to this: Should the Symbian Foundation’s priority be creating a next generation mobile platform or an infrastructure for constructing mobile platforms and devices?
Haydn touched upon this issue last week by referencing what I call “platforms” as “Type 1” propositions and “infrastructure” as “Type 2“. This distinction is quite important because the audiences for platforms and infrastructures are quite different and entail different strategies in the operating system and the brand projection (see also the comments sections on the blog here and here).
In terms of platform marketing, Symbian application developers and device manufacturers have failed to describe for whom a Symbian platform is the optimal choice. By failing to define the platform’s end-user audience, Symbian is often cast as as the open phone platform for the budget-conscious given its popularity on cheaper mobile phones. Symbian currently enjoys an advantage in that it’s the cheapest platform that hosts an application ecosystem, but that advantage erodes daily as competing platforms continue to drop in price.
For example, in the United States, a consumer can purchase an iPhone 3G for $99 from Apple or a Motorola CLIQ for $149 from T-Mobile. Nokia phones can be had for less, but even on their highest end Symbian devices, Espoo has failed to create a viable competitor for the iPhone and Android experiences. That Nokia has failed in this respect is only my subjective opinion (others will disagree), but it is drawn from my experience using all three platforms, including Nokia’s XpressMusic 5800 and N97 – two phones that were each more expensive than either my iPhone 3GS or Motorola Droid.
If Symbian is to remain a viable smartphone platform, we need to address for whom the platform is an optimal match and why someone would select it over the alternatives. While I doubt that we will see free iPhones any time soon, Google’s aggressive use of “less than free” business models will soon render cost a moot point.
However, if we adopt an alternative perspective and decide that Symbian is not a platform on its own, but rather is infrastructure for building platforms, we have to ask again: Who is the Symbian audience?
In the infrastructure scenario, the audiences are device manufacturers and software developers collaborating to create experiences and services for end-users. In the infrastructure case, rather than ask which end-users does the platform appeal to, we need to ask how can Symbian become a tool for those creating services and experiences for their users. The service/experience creator becomes responsible for creating a suitable product for the end-user.
From my (admittedly brief) tenure as a Symbian software developer, I do not believe that the Symbian platform can scale “up” from the perspective of software development. The overall configuration of the platform is a product of its history running on smaller devices and tightly constrained environments. While the recent port of the Qt framework alleviates this problem significantly, I still shudder when I think about the engineering effort that would be required to build a Symbian equivalent that approximates Apple’s iPad & the newest iteration of iWork.
However, I do not believe that this is necessarily a problem for Symbian as infrastructure. The recent attention paid to tablets and slates implicitly assumes that “more is better”. However, as someone committed to building the next generation of ubiquitous technologies, I believe that while there is a place for tablets and “fat” mobile devices, there are many more opportunities for slim efficient devices that are largely invisible to their users.
For example, in the realm of home automation, I am plagued with controllers and switches running one-off operating systems that crash regularly and rarely expose anything resembling a programmable interface. A power-line controller running Symbian would be a gift from heaven. A small portable and programmable GPS transmitter (such as the “spider-tracers” found in comic books) could serve as the basis for tracking family vehicles and other belongings. Or how, about a coffee maker that sends me an instant message (or alerts my Symbian-equipped alarm clock) when the brew is finished? Usability guru Don Norman suggests that
On one hand, Symbian’s legacy limits the extent to which it can scale “up” and compete with newer mobile platforms designed for more resource-rich computing environments. On the other, I believe that there is much more potential in distributing electronic capabilities to everyday objects and Symbian’s history and current state make it ideal to serve as the foundation for intelligent distributed systems. (For a great example of one of these systems in action, see Fogarty, Au & Hudson 2006).
Symbian is efficient, affordable, and robust – all qualities that are required for these kinds of technologies. The major obstacle is not technical, but psychological. By solely focusing on the mobile phone fight, other opportunities for making arguably larger impacts remain unseen.
It should be pretty clear (at this point) that in the medium to long term, I think that Symbian will fail to compete as a smartphone platform. It’s not the only mobile operating system trying to scale up nor is it the only open-source platform seeking a place in our pockets. I believe that reconceptualizing and reframing the Symbian project as a means to push more intelligent computing to more devices in our environment (both visible and invisible) plays to the strengths of the platform while claiming territory that is being ignored in the modern marketplace.
I suspect that to scale up and meaningfully compete with the likes of Apple and Google would require a full rearchitecting and reimplementation of the Symbian platform. (I recall something similar in the early history of the open-source Mozilla project and eventual emergence of Firefox). Alternatively, to pursue an infrastructure strategy, the Foundation would need to engage non-traditional (i.e. non-phone) device manufacturers and tweak the existing system to allow it to run on non-phone reference platforms similar to Arduino and Gumstix. The second approach seems like a more tractable project from my perspective.
I’m not going to pretend that mine should be the last word on this issue. As stated above, I’m a relatively new member of the Symbian community and I imagine that there are plenty who can make a stronger case for Symbian as platform than I do. However I do believe that a debate about who Symbian’s core audience are and how Symbian can best serve them will result in a more focused project that will create something distinct and special.
Financial disclosure: I own shares in both NOK and AAPL. (Yes, my portfolio is currently suing itself…)
@Chris,
The topic raised here is interesting, but i do not have enough technical and inside knowledge of symbian to comment on the theme of this topic.
But i would like to point out one thing that you mentioned, which most of the Americans get confused and probably fail to understand about the pricing dynamics. (May be i am wrong). But when you say that Nokia 5800 and N97 are each more expensive than iphone 3GS and droid is wrong accd. to me. I am a numbers guy. So i will just compare with an example of Nokia 5800 and iphone 3gs in US with AT&T data.
Price Contract Total price after 2 yrs
(includes voice+data)
iphone 3GS 199(16gb) 2 yr 199+(40*24 voice)+
(30*24 data) = 1879 min.
Nokia 5800: 300 max Unlocked 300+(40*24 voice)+
(15*24 data) = 1519 max.
Price difference: 1879-1519 = 360 (price of one more Nokia 5800 or an N97 mini (during deals).
Above is just the base price comparison. IF you add the price of the apps that you sometimes need to buy for iphone to make it do the functions which are included in Nokia by default or available in free apps, the total price difference may increase even slightly, plus the number and price of accessories that one needs to buy for iphone and Nokia is quite different. So overall, from my point of view, the total price difference would be around $500 over 2 yrs.
This is what most of the Nokia users think when buying Nokia against iphone and you will see that proof in countless forums online.
Now, i know that this was not the main point of the above post, i would have avoided writing this had it been some regular user, but since this was mentioned by the founder of a software company, but with dues respect, i was little disappointed that even software developers and tech enthusiasts like most of the people in US don’t quite get the pricing dynamics and strategies.
“Nokia’s XpressMusic 5800 and N97 – two phones that were each more expensive than either my iPhone 3GS or Motorola Droid.”
This is a bit uninformed. On Amazon US the N97 is $512, the 5800 is $259, the Droid is $499 and the iPhone doesn’t sell there but is easily $600 in countries where you can buy it without a subsidy.
I’m sorry, why is this blog post here? It looks all sorts of bad and stupid when the official blog of the Symbian Foundation is saying that Symbian can’t actually do what it is intended to do.
This post really needs to be removed, post haste.
Hi cdavies – I don’t agree that it is saying that. It’s asking how broad Symbian’s ambitions should be. It takes a realistic look at the competitive dynamics of the industry, narrowly defined, and identifies broader opportunities, though vaguely so one might argue. It’s the role of the blog to explore a range of perspectives. Why do you feel this more we should remove a perspective that is challenging but rich?
Challenging would be identifying an area where improvement is needed and saying what we need to do. This is downright defeatist.
It’s also all incredibly stupid. But I guess “rich” is the new code word for stupid now. Wouldn’t want to hurt anyone’s feelings, eh?
@Chris, the world really is in trouble when an intelligent and educated individual such as yourself can claim that a 5800 is more expensive than an iPhone 3GS? Did you forget to include the network tariff and contract lock in? Try purchasing both without and contract and compare the real prices!
I’d also be very interested to know in what way you believe that Symbian can’t easily scale? How hard would it be to build a UI for an iPad-like device with Qt (should anyone want to do such a thing)?
Of course Symbian can scale and compete towards the high-end. The good news is that it can scale down to the sorts of platforms you’re interested in too, and since it’s open source, there’s no reason it can’t do both if there are sufficient community members with those interests.
Hi Cdvies aagain – there are no codewords and I hope that the debate that’s now begun will lead to some interesting thinking around Symbian. I would throw the question back at you – how do you do open if you don’t allow diverse opinion?
What the hell is so great about diverse opinion? We don’t need people who don’t think Symbian can win. They can go and whine about it on their own damn blogs.
Realism is a great thing. It’s not all steak and onions, something that I’m not only prepared to admit but that I say on enough occasions that I’m pretty sure it must get tiresome for everyone else. However, there’s a difference between saying that everything isn’t great so we need to redouble our efforts to fix the problems, and saying everything isn’t great so we should give up.
What we need are people with a focus on improving Symbian. People who find the problems and have the skill to fix them. Not people who don’t know what they’re talking about and who’s first instinct is to throw in the towel.
“It should be pretty clear (at this point) that in the medium to long term, I think that Symbian will fail to compete as a smartphone platform.”
“I suspect that to scale up and meaningfully compete with the likes of Apple and Google would require a full rearchitecting and reimplementation of the Symbian platform.”
Such sweeping statements. If you hadn’t written the blog posts on your development and demonstrated that you’re clearly an intelligent and reasonable person (your maths aside) then I’d call you a troll.
What is your medium term? It needs to be about 10 years (nearly the entire life of the Symbian platform at this point) for that first statement to make any sense. I don’t see any reason why this might happen – the only possibility may be Nokia ending up putting Maemo on even the cheapest phones (~£100). It took Symbian 10 years to get there so why should Maemo get there faster?
And that assumes that Symbian really does need to be completely re-architectured as you say. Really, what is your basis for this? If you can prove it then I’d like to see that article. And I mean prove it, rather than using the ‘Symbian is designed for constrained devices and therefore is not suitable for anything more powerfu’ argument.
Excellent post, independently from the cost battle, in my opinion one of the main fronts in Symbian as mobile platform is quality image.
Justified or not, even armed with the highest technology and specs packages, frequently Symbian phones are perceived as not software reliable related phones with frequent crashes, limited performance, continuous software updates, bad memory management, errors in data synchronization or even in poor battery life.
This is really a hot topic and leading to intense debate in many different fronts. and having a serious look into the platform internals and knowing something about the platform evolution history what it was and what is today ( don’t forget that current Symbian is a mix of S60 evolution to speedup touch phones in the market and the Symbian kernel flavor plus the add-on of 3rd party user experiences beyond the OS kernel itself ) should be enough to realize that before solving the platform technology and architecture fragmentation don’t think there is enough to compete with other solid solutions.
Technology fragmentation itself is also impacting in the second front that is the effort in the platform integration to create Symbian devices.
In many cases I’ve seen references to how difficult is to develop apps for S60 but also I would like to recall a survey from device manufactures and technology providers about how currently big is the effort to integrate a Symbian device vs Linux or Android.
However at the same time, amazingly this fragmentation it could be the best strength in the second proposal “infrastructure”. The Symbian ecosystem is so rich that going to an open collaborative environment as similar as the mobile industry was before Apple or Google jumped into the scene, plus the enforcement of the open source world can push forward Symbian into key areas in the next mobile devices battle:
Innovation and user experiences, that is probably will be the space where mobile and embedded devices converge.
While I think this is an interesting area of discussion, I’m not sure this belongs on the official Symbian blog. Clearly Symbian has the capability to move outside its phone origins and connected embedded systems has a lot of potential. However a major focus remains phones… and I think the argument that Symbian will fail as a smartphone platform is incorrect (leaving aside defintion problems). I’m not really sure why Chris feels the platform wont scale (though I’m not a technical expert). Moreover every platform has its own issues and I think the architectural / ability to scale issues faced by Symbian’s competitors are probably more fundamental. There is a debate to be had about the gap between smartphones and laptops/computers (Moblin, Maemo, etc.) and Symbian’s potential / role here, but for the forseeable future that’s going to a much, much small segment than phones.
But more to the point this is the official Symbian Blog. Think what impression this post gives to someoneone coming to Symbian for the first time! People will assume it is ‘official’ and the Symbian Foundation does not believe it can be a smartphone platform. I know this is not the intention, but it is perception that matters.
I appreciate it is hard to balance the demands of being open / having a wider conversation and the need to present a message / mage (PR), but in this instance this sort of discussion would be better placed in the forums and / or an individual blog.
For what it’s worth, I think this is the most interesting entry I’ve ever read on this blog. I’ve been reading it casually for a while and many posts seem just to be toeing the line, and so aren’t terribly interesting (to me).
I think I’d be inclined to agree with Chris; it’d be fascinating to see Symbian is some non-phone devices, and to see how well it would work. There’s clearly an interesting discussion to be had about it anyway!
Hey, nobodies disgreeing that Symbian could have a place in other hardware categories. The problem is the argument made that Symbian is not suitable to be a smartphone OS, not to mention the fact that the author lets himself down by making incorrect assertions about the pricing of smartphones.
I don’t see a problem with the blog, i don,t even see that much criticism, more questions.
Technology has been shifting from geeks and tech people for a long time now to the overall audience, people who don’t care about what technology is behind it.
People care for status, brand recognition and ease of use, and surely symbian (nokia) can play ball if they do it right.
If people buy a tablet (pad) for instance what do they see as important, what operating system it has ?
Yes and no, as long as it’s easy to use it doesn’t matter, why apple may succeed where windows tablets never did.
I guess symbian could be used for more platforms why not, they have to make sure it’s easy to use and follow the new technology, nothing new here.
And people who bring hardware on the market have to make it cool in a way.
Use symbian as a brand…, i don’t know, maybe
A diverse viewpoint is valuable if you have want to take account of diverse views about where the future lies. Makes business sense to do that.
Chris is quite clearly saying that Symbian could improve if it reinterpreted its identity – it is doing that anyway isn’t it, so arguably it’s a matter of where to head for completion.
OK, let me try and put this another way. When people have worked so hard, and largely succeeded, in quashing the whole “Symbian is dead” thing in the trade press why on earth would you think it would be anything other than a PR disaster to print it on the official Symbian blog?
Also, in what universe do you think it is a helpful suggestion that Symbian should shift it’s focus from smartphones?
This whole “diverse opinions” thing reminds me of nothing so much as tack creationists use. Don’t let openness get in the way of telling people they’re wrong when they are definitely wrong, and don’t feel you need to give a platform to people who are very definitely wrong.
I think it’s a great post and clearly there are people who agree with me like there are people who agree with you. It’s a long haul to call this a Symbian is dead post.
In that case, let me add: In what universe do you think that opining that Symbian can’t compete as a smartphone platform is not in actuality the same as saying Symbian is dead?
@Haydn, it’s an interesting post, and I wouldn’t have a problem with it at all if it wasn’t on “the official mouthpiece of Symbian” without a big disclaimer across the top saying it’s the personal opinion of an application developer who’s relatively new to Symbian. That’s clear enough if you read the whole post carefully, and follow the link to the previous technical posts, but otherwise it just looks bad and could easily be taken out of context elsewhere in the media.
With all due respect to Chris, this post demonstrates an extremely shallow understanding of the platform, that appears to come primarily from reading about it in the tech media, rather than looking at real technical details.
I agree with the cabal against this post.
How is this constructive criticism? I’m all for discusing our weaknesses, but this post is so immensely uninformed that it can’t provide decent discussion material.
Can we stay away from such posts in the future?
HI,
Ok, my 2p on the matter.
I think @Chris is expressing his personal opinion here, and I am not too sure that he has backed it up with actual data.
i.e. I am not sure what the “Android can scale up but Symbian can’t ” is really based on.
It would be great in order to enable a constructive discussion to have clear examples of areas for improvement and how they compare with competitors.
Otherwise this conversation risk becoming a “panto” – “oh yes it is… oh, no is not…”
I think what’s worst about this thread now is not the contoversial post itself (which perhaps should have a disclaimer), but the response to it. Instead of making a good counter-argument, the reaction (from some) has just been ‘get rid of it’; this just appears unprofessional. Much of the discussion here should probably have been kept internal – it doesn’t reflect well on the foundation from where I’m sitting.
I’m sorry Haydn, but it reads like a typical silicon valley blogger to me. The author admits to a limited understanding, and some of his comments make clear that he has no real idea of even the OS architecture, let alone any of the more complex issues. The post explicitly says that Symbian is not able to be a smartphone platform in the undefined medium term. That’s about as close as it’s possible to get to a death bed croak without a priest.
I’d like to point out that Symbian Ltd. spent over ten years producing a platform for others to build their own platforms out of. One of the major benefits for device manufacturers of donating S60 etc. to the Foundation was to unify the competing platforms to produce a single complete offering.
IMHO the entire existence of the Foundation is predicated on providing a whole smartphone platform – at least for device vendors. If volunteers or outside effort wish to maintain a Symbian distribution targeted for non-smartphone devices, then that would be great and one of the very tangible and visible benefits of open source. Perhaps in a few years that will become the primary reason to use Symbian – who can say – however it should not be the focus of the foundation.
Anyway – someone with basic knowledge of the system could take a Symbian PDK release and make a small system out of it. Base ROMs are already pretty minimal, support many many things, and could even be reduced if necessary. The beauty of open sourcing Symbian is that this can even be an official distribution of the foundation and maintained by enthusiastic volunteers, with very little impact on those users who wish to see a fully capable smartphone OS.
Personally I don’t see a space as described here which Symbian fits into. At the very small end you have the no-os devices with a few hundred KB of ROM and very small amounts of SRAM. Then you have the rtos-only devices which can run up to a megabyte or two. Then you have the linux devices which ship now with 2MB ROMs and similar amounts of RAM.
Almost all SOCs one might use for a standalone computing device come with a linux base port already (because it’s incremental, easy and well understood). Symbian will always be a secondary target for SOC manufacturers since they can hit so many of their customers with open source linux base ports. Of course that’s a personal view and I don’t expect anyone else to share it.
If you wish to consider alternative form factors and internet enabled devices built with Symbian such as internet radios, eBook readers, in-car entertainment, set top boxes etc. then I do see space there, but again it needs someone interested in actually productising that to make it happen. IMHO there are no technical reasons why you couldn’t make it work – and work really well with the kernel, comms and MM architecture of Symbian^2 onwards – but who will try?
@All: Since my pricing argument seems to be the thing drawing the most fire at the moment, please let me address that. I am acutely aware that the final cost of a device is not only a a function of the hardware vendor’s price, but the subsidies and monthly costs of the service provider as well. Frankly, I think that the rest of the world has a better system for allocating mobile service, and I look forward to the day that American carriers join the rest of you.
That said, my cost argument is premised on three assumptions that I should have made more explicit:
1. Despite the promise of GSM device portability in the US, specific phone models are locked to individual carriers. The iPhone’s 3G functions do not work on T-Mobile (the N97 & XpressMusic 5800, and the Droid is locked to Verizon’s CDMA network. Consequently, in the US, there’s no way to price shop between carriers while keeping the phone constant.
2. In terms of the difference between the plans themselves, I am currently spending approx. $70/mo. on the Nokia phones and approx. $87.50 for each of 2 iPhones on my account (AT&T). After taxes and fees, the Motorola Droid costs costs about $95 / month.
Consequently, the price differential between Nokia devices and the iPhone is $17.50/mo. while it’s $25/mo. for the Droid. Over the standard 2-year contract, the total cost of the iPhone and Droid plans. However, these plans also include visual voicemail (a feature unavailable for my Nokia devices), for which Verizon charges about $3/mo. If we assume that this cost is comparable in my iPhone plans, the monthly differences drop down to $14.50/month and $22/month. The final costs of the feature phone subsidies are $348 (iPhone) and $528 (Droid) over the standard 24 month contract.
3. In terms device costs (before taxes), I paid $150 for the Droid (Amazon.com, 12/09), $300 for the XpressMusic 5800 (Nokia Store, 09/09), $525 for the N97 (Nokia Store, 10/09), and $200 for the iPhone (08/09). Applying the additional plan costs, the final costs of the devices (for me) came out to be:
iPhone: $548
Droid: $678
XpressMusic 5800: $300
N97: $525
(Feel free to step in if my math is off somewhere.)
This is for my specific configuration, so these numbers probably vary wildly for others. Now, if we are making a blind total cost of ownership argument (as everyone seems to be doing) and we stop here, my assertion above about the costs of the devices are FLAT WRONG. (I am happy to admit that.)
However, these phones do not sit idly on my shelves racking up wireless minutes. I use these do do paid work. I have three important tools that I need for work on the go: a usable & responsive e-mail client, and modern decent web browser, and an SSH terminal.
The iPhone and Droid e-mail clients provide a very usable (read and write) experience when it comes to multiple e-mail accounts (the Droid’s is slightly better). The Nokia e-mail client does not. The iPhone and Droid web browsers are far ahead of Nokia’s in terms of responsiveness and usability (the iPhone’s is slightly better). The iPhone provides a barely-acceptable SSH experience, while the Droid excels in that regard. (I have not looked at the N97 in this respect, but I’m happy to assume that there is wonderful SSH client there.) In the end (in my experience), the iPhone and Droid platforms permit me to do billable work on the go, while the Nokia phones have failed in this case.
The largest price differences are between the XpressMusic 5800 ($300) and the Droid ($678) – almost $400. I can unequivocally state that since owning an iPhone and Droid, I have billed much more than that for work done on the go.
In terms of the total costs of ownership, IN MY CASE, the iPhones and Droid have already paid for themselves on the basis that I was able to cram billable hours where I would have been unable using Nokia’s shipping devices. And as a software developer, I don’t fault the Nokia’s hardware for the functionality gap (their phones look great on paper), but rather the software ecosystem that has thus far failed to produce comparable applications to what I used daily on the iPhone, and now the Droid.
Now, as someone who has spent the majority of the last four months deep in developing my own Symbian application, I have no problems putting my neck on the line and stating outright that there are many aspects in which the the Symbian platform lags that of the iPhone and Android equivalents. Some of these will be addressed as the transition to open source wraps up. I place better centralized documentation in this camp. Some of the deficiencies will be addressed by third parties. Qt is a wonderful example of this as is the upcoming contribution of a standard camera API.
If I could assume that Apple and Google would sit still while Symbian caught up, I would be much more optimistic in terms of its ability to be a contender. However, as the last months have demonstrated, the Android & iPhone platforms are being iterated at a quicker rate, while the Symbian platform is lurching along in jumps and fits. The main point that I was trying to make when drafting this post was to ask whether it continues to make sense playing along in others’ game or whether now’s a good time for the Symbian community to take a step back and think in broader terms in order to come up with a strategy that results in a larger impact in the long term.
Thanks for the comments and I’ll do my best to keep up with them. Due to time zone differences, most of you have a 6 hour head start.
The discussion here is quite sad – but appropriate to the situation in which Symbian is today. It is not easy to overlook a mood about Symbian, it is not easy to overlook the difference in attitude among developers towards their platforms. Not a small number of developers describe Symbian as pain, nightmare compared with the Iphone development. It would be interesting to find a statistic from the last three years describing relation between number of publisher ID’s and number of installed applications and compare these numbers between Symbian and Iphone platforms. Imagine a situation when in a company you can choose from development on two/three platforms: Symbian, Iphone, Android. Which one would you choose to develop on? I doubt Symbian is the choice unless you want to program coffee makers – anyway the Symbian homepage looks like you can develop for everything except mobile phones. I hope this platform will get back on its feet.
actnow – I think that’s the kind of commentary that we need to move beyond. Chris is making an important point about infrastructure and the wider opportunities that the future holds. The fact is here on this blog you can disagree with that and engage him in debate about it.
Chris K- I don’t think the price of phones is the big issue here. I think the fact that you posit platform against infrastructure as exclusive alternatives is the problem. You need to explain that view more I think.
Chris R – we rarely get so many comments in such a short space of time so Chris has clearly touched a raw nerve. In the end are you not finding common ground here though – Symbian will become more of an infrastructure over time for multiple device forms? By the way – that is teh debate I hoped would happen here.
@Chris Karr, there are a few important points to note here:
1) The Symbian platform is currently undergoing a massive overhaul. You are comparing a 2+ year-old Symbian offering (software wise) with the latest and greatest from Apple and Google. It’s unfortunate that this overhaul is taking so long, but that’s where we are. Qt isn’t just being added as a optional extra runtime as you’ve used it so far, the whole user and developer experience is being re-worked.
2) Once the Symbian Foundation starts making releases that are taken into use by OEMs, there’ll be one every 6 months according to the published plans. I don’t see that as significantly slower than Apple or Google are iterating, plus it has been argued many times that for the most part, Apple and Google’s offerings haven’t changed that much from the original releases (more of case for Android evolving here, but it started from a very low base). Indeed, many folks in Europe and Asia see these updates as adding features which have been in Symbian for 5+ years.
3) You have correctly identified a couple of weaknesses of the current application suite – the browser is not great (although have you tried Opera or Skyfire as a replacement?) and the email solution needs more work (that said there is a much better experience on some non-touch Symbian devices like the E72). However, I don’t see how either of these have anything to do with the underlying platform and its ability to scale?
I agree with you on centralized documentation – it is an area where the legacy is an issue, Qt will help A LOT, and we have people working very hard on it.
Thanks for making the effort to defend your position so thoroughly, it really helps to understand where the comments are coming from.
P.S. Nokia have just submitted a proposal for the new Qt based browser if you’re interested to take a look, I don’t think there are any UI details yet though.
Mark – why don’t you come in and write a post that articulates your position more fully?
I agree largely with Mark’s post. Not much to add on that front.
I would like to thank Chris K for coming back and continuing the dialogue, this blog has consistently provided open and frank discussion and that’s important. It is often misrepresented in the outside press as Symbian Foundation not knowing where it’s going – and I believe frustration in this regard is behind a lot of the negative response here.
I’ve thought for a long time how suitable the underlying Symbian OS is for devices other than smartphones – especially those like my sat nav which are essentially based upon the same hardware that goes into smartphones.
I do see an opportunity there for some nice products, but they need a good USP, and I have to acknowledge that my background in Symbian engineering may be leading me to see Symbian as a viable platform choice while others have different history and don’t know the OS as well.
It’s certainly possible that Symbian will expand to cover other types of devices, but I would argue that the only way for that to happen is for someone to actually make a product. The foundation is unlikely to match the requirements of such a move without the guidance coming from productising the platform.
On a slightly different note, there is a considerable difference in the various perceptions of Symbian which appears to me to be a product of two opposing views of the OS.
I and others like me who maybe have worked on developing mobile OS’ for a long time look at Symbian as an OS with a collection of UI toolkits and apps on top. This gives us a certain perception of the platform, and mostly we conclude that the OS is good and a renewed UI and collection of applications can fix many of the apparent issues. The more time you spend working with real products, the more you realise that the apparent shinyness of new code will only last until the bugs have been fixed.
From the opposite end, a lot of bloggers and commenters seem to look at the visible parts and conclude that the entire platform is out of date. For such an influential bunch, their minimal examination of the stuff they talk about surprises me. I disagree with them, but I do recognise where that viewpoint comes from. I don’t believe there is a lot that we can do to counteract that viewpoint apart from home that S^3 & S^4 are as good as possible.
@Mark Wilcox: Regarding Qt, I think that can and does scale wonderfully to tablet devices. My question is whether the underlying Symbian technology can scale to those devices in such a way that it allows Qt to shine.
Let me elaborate on this point. First of all, I will be the first to admit that I am not intimate with the internals of the Symbian OS and my experience is drawn from my time as an application developer using external APIs available via a standard signing certificate. Consequently, the conjectures that I make in the original post are drawn by what I see is reflected in the API.
When programming on the Symbian platform, there are two drastically different worlds: Qt and Symbian OS proper.
When I am programming in Qt-land, life is good. Clear documentation is available at doc.trolltech.com and I can readily answer just about any question that I have in that location. Third-party Qt code (such as QXmpp) works well and I don’t have to worry about too many surprises or landmines when writing Qt code.
When I need to drop down into Symbian-land, life is difficult. Good documentation is unavailable and spread haphazardly on forums, wikis, and other websites. I have spent far too much time puzzling through the online resources. Too often, when I do find what I’m looking for, the documentation insufficient or the end results are not what is expected.
Case in point – for my current application, I need a way to send a system-wide user notification where the user can click a softkey and return them to my application to complete a task. I need dynamic labels on the notification and ideally the ability to show a custom icon (e.g. show our globe icon when prompting the user for their location). In Qt land, I would use a QMessageBox of some flavor, but given that the Qt equivalents didn’t work when non-Qt apps were front and center, I had to drop down to using CAknNoteDialog and its subclasses. Note that getting to the point where I could identify CAknNoteDialog as the class I needed was a small project in itself.
After getting around the issue of converting Qt strings to Symbian strings, I had a basic notifier working that did most of what I needed, except for the custom icon and and the dynamically specified softkey labels. I struggled with trying to use the SVG resources in my Qt project as the icon, and ultimately gave up. My current understanding is that the icons that can be used must be part of a set that is shipped with the device. When I tried to customize the softkeys, I found it easy to use an existing key schema (“Ok/Cancel”, “Options/Exit”, etc.) but I was unable to get the notification server to use my custom labels. They would flash briefly, then return to one of the existing preset schemas.
Implementing notifications via QMessage box took me 20 minutes and other than its unavailability when other apps were front and center, I was happy with the results. My foray into Symbian world and its quirks lasted well over 6 hours and at the end, I didn’t have anything to show for the work. (For the curious, I fell back to using my existing RNotifier implementation.) Finding the relevant documentation and navigating the esoteric Symbian API was small project itself. Once I nailed down what I needed to do, the results that I received were not what I wanted.
Now, it is probably unfair of me to draw the conclusion that the platform will not scale higher on the basis of this single incident. However, what I experienced in transitioning from Qt to Symbian has been the rule rather than the exception. Now, the internals of the system may consist of the best operating system ever created. Unfortunately, the API does not reflect this reality.
Compared to Qt, developing in straight Symbian is an order of magnitude more time intensive and frustrating. If the Qt guys can completely hide this complexity such that touching straight Symbian code is rare, I will happily withdraw my scalability assertion. Until that point, however, there is a limit to the scope and size of application that can built in a reasonable amount of time on the Symbian platform.
I welcome any counter examples that refute this point. I would like to see applications that expose the same level of features and usability such as OmniFocus (iPhone), NewsRob (Android), Flixter (iPhone/Android) and Yelp (iPhone/Android) (for example).
Hi Chris R – I think you’ve summed up some important issues. People who know Symbian know how great it is. Could you compile your comments into a post?
@Chris Karr, the intention for the Symbian platform’s future, with things like Orbit and Qt Mobility is that it becomes extremely rare that you ever have to touch native Symbian C++ code as an application developer. The native Avkon dialogs that you’ve struggled with are being thrown out, along with the rest of that entire UI framework. It is notorious for being inflexible and I wouldn’t argue with your assessment of it compared to Qt at all. How good the new APIs are remains to be seen. Fingers firmly crossed here.
@Haydn – when I can make an independent assessment of what Nokia delivers for Symbian^4, maybe. I may have shifted my focus to another area by then though. In general I think we’re better off talking about it when there is actually something to show, rather than promoting the virtues of some as yet unseen future UI. Nokia can promote it if they want, they can at least see how it’s going.
Hi Mark. I’ve just re-read Chris’s post and feel with the benefit of hindsight it is what he acknowledges it to be – and often so. A guy fairly new to Symbian who sees a broad range of opportunities outside the core mobile market that is Symbian’s bread and butter. I am disappointed we didn’t get onto that – such is debate. But would like to draw us back to that and thought you might be the one to pen a post.
So you are a new(ish) developer. Why come to Symbian? Don’t we need to articulate that as often as possible and in as many places as possible?
@Mark Wilcox: Regarding your second post on the evolution of the platform… I’ll admit that my experiences are based upon shipping hardware and software. I’ll be very interested to see the next iterations of the platform where Qt is a core component. I can only write about what I and my customers can get our hands on, unfortunately.
@Haydn: Regarding the platform vs. infrastructure exclusivity: At the end of the day, Symbian will have to decide who its primary audience is. If Symbian elects to remain primarily a smartphone operating system that is racing with Google and Apple, I don’t know if the attention and enthusiasm will be available for the work needed to pursue non-smartphone deployments.
The converse is true – if Symbian focuses on creating a great embedded OS, will it (the Symbian Foundation) have the psychological resources to try and keep up with Apple and Google as well? It may very well be that both approaches are achievable, but when it comes down to a hard decision with the smartphone guys on one side and the infrastructure guys on the other – who will prevail? That’s the core question that I’ve tried to ask in this post.
@Mark Wilcox: I eagerly await the new Qt-based platform and would pay to be a beta tester if you need them.
>> So you are a new(ish) developer. Why come to Symbian? Don’t we need to articulate that as often as possible and in as many places as possible?
IMHO, no. We’d be much better off getting our house in order before inviting people in, otherwise they might take one look, walk out and never come back – such are first impressions. Of course there are areas where our house already is in pretty good order and we could focus much more strongly on those until the rest is ready.
>> A guy fairly new to Symbian who sees a broad range of opportunities outside the core mobile market that is Symbian’s bread and butter. I am disappointed we didn’t get onto that – such is debate.
If the original post had excluded the bits about Symbian not being suited to the market it currently leads and devices costing more than those of competitors, it may have prompted some more useful debate about its key point on ubiquitous computing platforms and the suitability (or otherwise) of Symbian for them.
I don’t think he said it is not suitable. But clearly a developer with no real background in the OS feels something strongly enough to express it here. I believe in reaching out to that.
@Chris Karr, It’s all open source (or will be shortly) there’ll be no need to pay to test it – on the contrary your input will be highly valued.
Since the platform is open source, the Symbian Foundation staff (who only manage the platform, not develop it) need only devote a relatively small amount of time and energy to budding communities working with the code on non-core activities until they grow into real products. Personally I’m very keen to encourage experimentation with different hardware and will help wherever I can.
I don’t have much to add to this fiasco, but I’ll say one thing that I also said to Mark in private:
“I’m sure that if Symbian and Nokia felt that there was no future in the Symbian OS or S60, they wouldn’t have gone to all of the hassle involved in opening it up.”
…and leave things at that.
Tyson I’m at a loss to know how a discussion among rational adults can be a fiasco
Sorry Haydn, I guess that was too strong of a word, and I hope that you or the author of the post didn’t take offense.
I discovered this blog post through cdavies’s interpretation of the article and comments in his Twitter stream, which biassed my views on it to an extent.
I’ll probably re-evaluate this stuff tomorrow, and might be able to provide a better perspective then.
The initial premise of the article sounds correct, Symbian looks a lot more like infrastructure than a platform. Wasn’t this the original intention though? It was the licensees who would provide the platform.
However [the licensees] really didn’t make a particularly good job of presenting a coherent platform.
What’s the difference? Apple market their OS well for a start. Remember the fanfare when Nokia announced S60 v5? Neither do I, and in any case the platform gets lost in the boutique feature phone marketing that all present and ex-Symbian licensees do.
What about Android? For all intensive purposes it will be defined by the suite of Google powered apps on the platform, although I think that Android is set up to fracture in similar fashion to how Symbian was at the outset.
As far as the reference to ‘scalability’, I’m afraid I think this statement is unjustified. You appear to have problems with the way a particular framework is implemented and presented. I don’t think it is then inevitable that the whole OS is fundamentally flawed.
Tyson – thanks. Look forward to hearing it. I too got dragged into that sense that this was all doom. Chris’s post is not what it has been painted to be.
Tl – great to see your response
About the last comment i would say that the scalability issue is could not be totally unjustified.
Depends where “scalability” word means here, by instance porting the Symbian OS from hardware to hardware or from mobile phone to a tablet PC yes the platform can be named scalable and it can behave same well in different kind of software and concept devices but still we should be careful here as some of the frameworks behaves different on different hardware and also if the time that takes is worth the activity.
If scalability refers about the code itself and how the platform is really implemented, how easy is create a vertical funcional set of components, adding or removing features to the S60 that requires changes along different packages, modify applications, manage device configurations and or make platform integration work, then i agree the platform is not fully scalable and i can name at least some frameworks where clearly is not or give a lot of examples of current devices behaving as not scalable but i guess this is not the place.
I miss one important talks on this conversation and is the device makers point of view and the people who makes differentiation software for user experiences ( not only the ones who wait to create apps and sell those in a apple store )
Visible or not there are lot of things going on to solve the scalability issues ( QT and Orbit is one of those and even SHAI ) together many other things to make the platform more competitive and attractive but before seeing those delivered, integrated and showed in a commercial device, i think is normal some skepticism in people outside of the Symbian world.
so i guess it is better to accept some criticism, put in practice those lessons learns and make a sanity check instead to go into a fan boy war flames.
Emilio, the problem here is that I don’t think we can learn anything from the “lessons” in this blog post, since they’re largely wrong.
We have many lessons to learn, but can we please vet our lectures before we do so?
And since we seem to be updating the post, can we just draw a line through most of the material since the author seems to have withdrawn most of his arguments?
I only disagree in the context of his article. I didn’t see how he could leap to a point of view that Symbian OS had such a problem requiring some sort of uneconomic redesign – that means it only should look downscale – which as someone else pointed out this isn’t even practical.
If you want to talk how the design or lack of in Symbian OS sub-systems is fit for purpose intrinsically or vs other OS’s that is a separate discussion imo.
Some additional thoughts and reactions to the comments here.
I should have been much clearer on what I meant by “scalable”. In drafting this blog post, I tried to keep things on the shorter side, and I feel that with respect to scalability, I should have elaborated more. (I originally meant the software platform as a whole, not the OS in particular.)
I was probably premature in declaring that I didn’t feel that the platform would scale as devices become more fully featured and less phones than mobile computers. I am not a fan of the “one device to rule them all” mentality and I think that different devices and platforms should have different niches in a user’s personal computing ecosystem.
I’m a bigger fan of the XM5800 over the N97 precisely because it doesn’t try to be something bigger than it is. It’s a darn good music device that doubles as a good phone. You can look at that device and think, “Gee, this designed is for music lovers”. Unfortunately, while the XM5800 excels at music, it didn’t meet my other needs, and thus it failed to become a key piece of my personal gadget toolbox.
One last word on “scaling up”: it seems clear to me that Apple and Google are running with the “bigger is better” mentality that has pervaded the personal computer industry as long as I can remember. New platform release typically entail more powerful and newer hardware. My original reason for writing this blog post was to question that conventional wisdom. In my questioning whether Symbian could scale up (a secondary point), I obscured my primary point: *should* Symbian make it a goal to scale up into tablets, netbooks, and “superphones”?
Let me be clear on this point – my original goal in writing this post was not to try and convince readers that Symbian should be rewritten to compete with Android netbooks and Apple’s iPad, but rather the opposite: Symbian should try and reach out to the non-traditional niches that are just as vital, but less visible, in our daily lives. As I stated in the original post, Symbian is a robust, efficient, and affordable platform for mobile computing. Let’s take some of those strengths and begin applying them to devices other than mobile phones. GIven the state of some of the embedded platforms that I deal with regularly, there’s a lot of room to do some good.
Regarding the cost issue, I apologize that I painted with a brush that was wider than I thought it was. If there’s one thing that you take away from my clumsy comments on the subject, let it be that what we should be optimizing for is not affordability, but value.
By this, I mean that we should be focused on the needs of our users and deliver the experience that maximizes the return on their device and service investment. In *my particular situation*, the value proposition failed to materialize in the Nokia devices because I have a particular set of requirements that those phones did not meet. An iPhone meets those needs, as does the Droid.
However, I fully recognize that the farmer in Africa has a different situation and a Droid or iPhone is an awful fit for their context. The thing that needs to be crystal clear when we discuss this technology is who our users are, and not necessarily the other guy’s device that we are chasing after. iPhone vs. Android vs. Symbian is a great horserace, but we can’t lose sight of our users. I apologize if this post indulged in that horserace mentality.
Finally, thank you for taking the time out of your day to read and respond to my thoughts. I admire the passion that there is for this platform and I look forward to using this technology as a tool for meeting the needs of my users.
(For what it’s worth – one final thought on scalability – I’m not so sure that the iPhone OS has scaled up to the tablet form factor well, either. The iWork port is impressive, but it has a long way to go before I see myself seriously using it. I was very disappointed that Apple scaled the iPhone OS *up* instead of scaling Mac OS X *down*.)
I know I’m late to the party here, but I’ll throw in my 2c (Aussie) anyway.
I think Chris Karr’s analysis is correct so long as it is constrained to the S60 framework. Chris, unsurprisingly given his background (recent Symbian developer, developing only high-level apps) confuses S60 with Symbian. This is clear from his more detailed responses, as well.
So, reframing the debate that way, we can see things a bit differently:
- S60 is NOT scalable
- S60 IS (very) poorly documented
- S60′s scalability has nothing to do with Symbian’s scalability, as ER5 (which ran on the original NetBook, remember) proves
- S60′s imminent demise completely removes its scalability constraints from the debate over Symbian’s scalability
- Standardising on S60 for Symbian (as opposed to UIQ 3 or even S90) has costs that need to be acknowledged, and these costs are ongoing given the delay until S^4
- Is there anything Symbian can do to reduce these costs that is worth doing, given the limited lifespan of the S60 framework?
From my perspective, as an ISV (a true ISV, not a mixed ISV/Service provider), S60 has become a bit of a mess for Symbian. Why?
- Chris’s points about poor doc and inflexibility are spot on, so S60 makes my job harder
- The limited lifetime of S60 makes my potential return on that hard(er) work less
- Symbian/Nokia have not provided a proper framework for supporting QT apps (8MB of extra libraries that the user needs to get on their phone somehow?)
All of these things are fixable:
- Improve the doc.
- Provide S60 backward compatibility on S^4 phones — if Symbian is serious about their platform this is a non-negotiable
- Get the QT libraries onto S^1 devices somehow so I don’t have to
Just some thoughts.
Hi Sebastian. Largely wrong? Chris is an apps developer committed to the Symbian platform. How can we not listen to his point of view. If Symbian is successful with its objectives in February and 2010 it will be inviting many many more apps developers into the door. If he has misconceptions then I would suggest so do many other apps developers and I think it is incumbent on us to welcome their views. If you don’t you make Symbian look like a club that doesn’t want the new boys. Chris is not a bash Symbian bigot but someone who has committed his business to Symbian. I think we need to embrace people who are prepared in his position to express those views and we are certainly learning something about the different perspectives in our community from the exchanges Let’s get used to having inexperienced Symbian developers around.
@Haydn, thanks for the vote of confidence. To be perfectly honest, this has been a very educational experience (in a good way) and I appreciate the feedback and education from folks like Sebastian.
In terms of my business, Symbian is one of several platforms that I develop for. In addition to Symbian, I’m currently writing software for the Mac, Android, iPhone and Linux platforms. Symbian’s part of my overall toolset, but it’s not the only one.
And “inexperienced” – guilty as charged. However, despite my short time with the platform, it’s enabled me to do things that were impossible on other devices. I look forward to seeing what else is doable.
Three quick comments:
1) Having this kind of post is a very good thing if it’s making people stand up and yell “Symbian’s not dead!” – a bit of passion around here certainly can’t hurt.
2) Some greater clarity on where Symbian is going as an organisation (see my previous post on metrics which, to date, has elicited no official response from the Symbian management) must be a good thing as it is no end of frustrating seeing it trying to be everything to everyone (as I often hear from Symbian employees).
3) If I were Symbian I would actually be more worried about Maemo than either Apple or Android. Lots of people talk up the iPhone but it’s fairly unknown outside of the US. Likewise Android is very impressive but is already having fragmentation issues. One of the big issues for Symbian is that Nokia, by far the biggest user of the OS, now fully supports two open source mobile operating systems. As CPU power and memory gets cheaper the reasons to use a resource-tuned OS (Symbian) vs a standard Linux OS with an already existing huge community behind it (meaning Linux not Maemo specifically) become significantly fewer. Especially when you look at home many people it takes to write / debug Symbian within Nokia vs the equivalent number of developers working on Maemo…
I’d say that we’re getting better as far as the fragmentation story is concerned, at least compared to Android and the various proprietary UI variants and frameworks that have appeared as of late on that platform (e.g. MotoBlur, Sony Ericsson’s proprietary stuff, and HTC’s SenseUI).
[...] This post was mentioned on Twitter by Glyn Moody, Brian Phipps, Anirudh Sharma, Anirudh Sharma, Symbian Foundation and others. Symbian Foundation said: #Symbian’s identity: Platform or Infrastructure? http://ow.ly/12tyx [...]
As a long-time commercial third party Symbian developer (started developing apps in ’98 and selling apps in 2000), let me add a eurocent or two as well.
The difference between infrastructure and platform is important, because third-party programmers program for a platform, not an infrastructure. If Symbian now sees itself as a platform provider, that’s good, but there are still a couple of things missing.
The main thing here is that Symbian must have a clear vision about their third party developer interaction, and the intent to execute that vision. How stable are our API’s going to be, how good is our documentation going to be, how easy is it going to be to program on our platform?
If Symbian thinks that third party developers are going to contribute documentation and tools, then I urge you to reconsider because that is not going to happen. Reason is simple, it takes time and third party developers do not have that time. Period.
Some of your competitors are much better integrated, with Apple as the best example and Samsung as the second best.
Apple manages the the platform beatifully, has good docs and tools, it keeps the operators of our back with a proper 70-30 percent split.
Samsung has great potential too, their API is (I am told) very well designed and a joy to program for, and Samsung should be able to keep the operators at bay.
If Symbian wants to compete it needs all that too, but it can only do the platform programming bit well, because Symbian doesn’t do devices.
All the programming bits however are within Symbian’s reach and Symbian should strive to deliver the best programming experience there is.
Good points as always Sander.
>> If Symbian thinks that third party developers are going to contribute documentation and tools, then I urge you to reconsider because that is not going to happen.
Taken to an extreme this is obviously false. You may not be planning to contribute docs and code, but the Forum Nokia wiki and several 3rd party open source tools would suggest otherwise. However, it would be extremely foolish to rely on this to cover any important tools or docs. Rather we would hope that developers will “contribute to” tools and docs – i.e. help to fix or improve them where it’s worth their while doing so (often better than maintaining your own version if you need a specific enhancement to make your life easier). Correcting docs where you find an error can save others time, and if everyone does the same it’ll save you LOTS of time overall.
>> Samsung has great potential too, their API is (I am told) very well designed and a joy to program for, and Samsung should be able to keep the operators at bay.
Samsung has great potential in the mobile market but I’ve never before seen anyone argue it is for their software! What API are you talking about? If you mean the new Bada, I’ll say nothing other than please go and look at it yourself before singing its praises in public.
>> All the programming bits however are within Symbian’s reach and Symbian should strive to deliver the best programming experience there is.
Well, actually a lot of them may well belong to Nokia still (via Qt, which is not contributed, just “made available”) but in general I agree completely.