Read-only archive of the All About Symbian forum (2001–2013) · About this archive

The Risk of opening Symbian

29 replies · 5,558 views · Started 12 February 2010

Symbian is now open source, which will no doubt attract new developers with new ideas. Any manufacturer can freely use and change Symbian in their devices. It's an exciting future - or is it? David Gilson discusses the potential downside of Symbian being open source, in a powerful editorial that needs to be taken to heart by Symbian and its partners.

Read on in the full article.

I agree with you 100%. Even now S60 on top of Symbian isn't as unified as it once was; there is a big difference even between the E Series and N Series that should not exist beyond physical attributes. What was once a standard button for S60 (the pencil/edit key), has now been removed from all newer handsets. And why? Not only is cut and paste now a pain to perform, but it just added something more on that long options list that is also includes the redundant "show open application" that should be handle by the (Menu/Task Manager) key only... Anyway, before I get off topic again, LOL. I am all for the new Symbian Foundation's strategy to move the OS forward, I just hope that a sense of uniformity and consistency is kept at all time. This will not only alleviate developers coding execution, but it will also highlight the value of Symbian as an open source OS against closed OS like the iPhone's Mac OS X.

That's good news! I wanna see a Symbian variant with interface like Android with a Palm Pre multitasking. Any problem with that??

Oh my god!!!! Now everyone will fork they own ver. of Symbian and Symbian will become the most popular OS for feature-phones. Every app will work on just one dumbphone. /sarcasm
Symbian is currently pretty much already non-unified. You have 5-th edition, 3rd edition. E-series, N-series...
So, what should Symbian do? Roll-back and close everything so it wouldn't fork?
Yes, forking is a problem, but Symbian now has pretty strong competition and it don't have any other choices. What's better, to fork Symbian or to not use it at all?

yea have to agree love thie idea of open source but don;t want a hundred and one different distros. ideally want the flexibility of open source but the polish and usability of say the iphone as altho it lacks some things it looks and feels easy to use

3rd edition to 5th edition cannot be described as a fork - they're merely different versions. This happens all the time in software. Yes the iPhone has 1 version that apps are compatible for, making it all very simple - but let's see how long Apple can maintain this for. The iPhone is a mear 2 and a half years old, which I think you'll find is still shorter than the distance between S60 3rd edition and 5th edition.

nice article. but do i agree with this? not necessarily. Over at LaymanHack.com i have replied to this article with some of my own opinions. Mainly, i feel comparing Linux for desktops to Symbian was unfair. Check out the post.

iphone is not going to last in this form. i mean, look at 3gs vs 3g. and think about next versions: there will soon be applications that requires a specific version of iphone. so, i prefer an open platform.

Couple of points here:
- Linux hasn't forked. Those are all distributions - but same Linux kernel, same KDE, same Gnome. Just different ways of packaging. You'd expect Nokia, Samsung, Sony Ericsson to retain their own packaging so no problem here
- Forking generally only occurs when maintainers won't listen and even then it will fold back in e.g. gcc. Other cases that might fork are MySQL and OpenOffice because they don't always take a patch. But if they do fork then one will probably quickly become dominant.

So overall the threat of forking helps people keep on their toes and actually makes open source much better.

This whole article is based on a licensing mis-understanding:

"Being released under the Eclipse Public Licence (EPL), anyone can take the source code, do anything they like with it, and not contribute any code back to the Symbian Foundation."

This is wrong!

The EPL is a weak copyleft license. If anyone changes any of the platform code then they have to release the source code to those changes. What they can do is add extra components or replace components and keep the code for those closed.

In addition to this, Symbian will have a compatibility program such that if OEMs don't maintain binary compatibility for the public APIs then they can't use the Symbian name (i.e. they can't claim it's a Symbian device if it isn't compatible).

An OEM can create their own UI, but they have to keep Qt compatibility (Symbian^4 onwards) for example, so all the apps that are built on Qt will work across all devices.

This is in contrast to Android, which has a permissive license (Apache) and no compatibility promise, for which the original statement would be correct.

Hope that helps clear it up.

Not that all of that doesn't prevent someone forking Symbian and us not wanting to take the changes back, but it does make it very much less likely. Even the GPL hasn't stopped Google forking the Linux kernel, so it could happen.

The thing I hope for the most is that the future default Symbian music player will be able to play ogg vorbis files (which is a open & patent-free music format).

this would make the sanzhai (fake brand) china phone to raise to a new bar.

In the past we'll see fake nokia brand phone with very bad looking OS, in the future the fake nokia fone will have symbian OS.

mikescandy wrote:iphone is not going to last in this form. i mean, look at 3gs vs 3g. and think about next versions: there will soon be applications that requires a specific version of iphone. so, i prefer an open platform.

in a way, this has already happened - the iPad is essentially just an iPod touch. yet it has a separate version of the "iPhone OS".

imcdnzl wrote:Couple of points here:
- Linux hasn't forked. Those are all distributions - but same Linux kernel, same KDE, same Gnome. Just different ways of packaging. You'd expect Nokia, Samsung, Sony Ericsson to retain their own packaging so no problem here
- Forking generally only occurs when maintainers won't listen and even then it will fold back in e.g. gcc. Other cases that might fork are MySQL and OpenOffice because they don't always take a patch. But if they do fork then one will probably quickly become dominant.

So overall the threat of forking helps people keep on their toes and actually makes open source much better.


while i agree that using the term "fork" was not correct in this article, the whole idea of mind-share is still an issue that is quite relevant here. a perfect example of how Symbian has followed a similar path to how Android is at the moment is by looking at it's heritage - EPOC.

EPOC32 started out with Psion and although there were different devices by different manufacturers running EPOC32, the only difference between the software running on the devices was maybe an icon theme and the odd application (the Phone app on the Ericsson MC218 springs to mind).

Then Symbian happened. And we get three different variants of Symbian, those being Quartz (UIQ), Crystal (Series80), and Sapphire (Series60). The whole point of Symbian at this point was to have a generic UI. This obviously didn't happen. While they all share a common underlying "kernel", they all have quite different paradigms in terms of the user interacting with the software.

My own stance on all of this is: Symbian has always worn different faces, from the point of view of the general customer. This development of the operating system being open source will not change that, except for there being a possibly larger choice.

Unregistered wrote:this would make the sanzhai (fake brand) china phone to raise to a new bar.

In the past we'll see fake nokia brand phone with very bad looking OS, in the future the fake nokia fone will have symbian OS.

Possibly but unlikely. Do you think they will put symbian on hardware that can run it decently.

Anyone is entitled to take Symbian and put it on whatever they want. As Mark Wilcox said though, if that version doesn't pass a compatability test then they are not entitled to call it Symbian.

"Not that all of that doesn't prevent someone forking Symbian and us not wanting to take the changes back, but it does make it very much less likely. Even the GPL hasn't stopped Google forking the Linux kernel, so it could happen."

Yes, I think this was the kind of thing that David had in mind. David? Any response to all this?

"EPOC32 started out with Psion and although there were different devices by different manufacturers running EPOC32, the only difference between the software running on the devices was maybe an icon theme and the odd application (the Phone app on the Ericsson MC218 springs to mind).

Then Symbian happened. And we get three different variants of Symbian, those being Quartz (UIQ), Crystal (Series80), and Sapphire (Series60). The whole point of Symbian at this point was to have a generic UI. This obviously didn't happen. While they all share a common underlying "kernel", they all have quite different paradigms in terms of the user interacting with the software."

I think that it was always Psion's intention with EPOC that the OS and UI layer were completely separate, with the idea that licensees could design their own UIs if they so wished; I think the only devices which ever actually did this were the Geofox and Ericsson R380, neither of which were particularly successful.

As an example, I managed to write a generic password program (Passwords, available from Freepoc) which was written in OPL and ran on both UIQ and S80. So although the UI layers were fundamentally different, it was possible to write a program which could detect what type of device it was running on and dynamically adapt to the screen-size, touch-screen, keyboard (or lack thereof) etc.

The big problem seems to be the fact that many apps (notably Nokia's own apps) are not only OS/UI specific but device specific, which seems to be totally unnecessary, and must be enough to put many (potential) developers off...

I have updated the artilce to use fragment rather than fork as that's probably more technically accurate.

I think EPL gives its own set of challenges here in that it encourages closed differentiation. This is unavoidable, but there needs to be awareness of it. I'm sure we will get some differentation that adds extra APIs (unique hardware etc etc). And the operator may even play a role here potentially.

Hopefully the certification program will solve a lot of these problems. But the proof is in the pudding - we be interested to learn more about Symbian's plans for this when the time comes.

Look at Android - most consumers would not know the difference between a 'with strings' Android device and one without. How do you measure compatibility - basic platform stuff or including 3rd party applications?

There's also the issue rise of service layers - like Ovi. We've already seen the issue around people trying to install Nokia certified files on there devices and it not working... But why can't I use Ovi Maps on my Sony Ericsson Symbian phone...

I think forking, versioning and packaging are being mixed up here.

There will always be an element of customisation by device manufacturers. Whether it's stuff like adding or customising apps and themes for differentiation or necessary things like adding drivers and base-port code optimised for their particular hardware and peripherals.

I think what is important though is that compatibility for 3rd party software (be it apps or lower-level plug-ins) is maintained. That is normally the case though - a Symbian^3 app should be able to run on any Symbian^3 device for instance (as should any Symbian^1 or Symbian^2 app). Typically you'd expect the app to continue working on Symbian^4, ^5 etc. devices. However Symbian^4's switch to the new Qt-based API will most likely break compatibility for apps - but that's a very special case though (and I'm convinced it's for the greater good) and will not happen often.

This is just normal versioning though. It's no different to what you see on PCs (Windows2000 -> XP -> Vista -> 7) or Macs (Mac OS 9, OS X, OS X 10.2, 10.3, 10.4 etc) and has nothing to do with forking.

Linux is a bit more complicated though. Windows and Mac OS X are sold a single product that combines the low-level OS kernel, libraries, middleware etc. with a UI and a selection of apps. To most people, the combination of all that stuff is "the OS". Linux (strictly speaking) is just a kernel. To get a full-blown desktop environment you need to add a load of stuff on top. For many of the required bits and pieces there are several competing projects and/or products. What distros like Ubuntu, RedHat etc. do is take a bunch of these pieces, put them together and package it all up nicely. To the end user the distros may effectively seem like different OSes but this is still not forking. It's just different combinations of stuff.

(Pre-foundation Symbian OS was somewhat similar: Symbian OS was kernel and middleware without a UI. S60 was Symbian OS + a UI. UIQ was Symbian OS + a different UI. Similarly for MOAP, Series90, Series80 etc.. Now that S60 + Symbian OS have been combined into the "Symbian Platform" I guess it'll be closer to the Windows or Mac OS X model in future)

Forking is when people working on a software project can't agree on how to progress it and therefore each take a copy of the code and continue developing it their way. If the differences are big enough the forks will drift apart and end up as completely separate projects. (In some cases though they can reconcile their differences and merge the forks back together)

If that happened across the whole of Symbian, that would undoubtedly suck. However, the chances of that are minimal. Software, especially big software like an operating system isn't just one massive blob of code - it's typically broken down into distinct modules. Often those modules will be isolated from each other such that they can (mostly) be developed (or even replaced) independently.

In the case of Symbian, the breakdown is done at several levels: layers, packages, collections and components (see the recent System Model video on the Symbian Blog if you want to know more). There are rules and restrictions on how these elements interact with one another.

If anything, I would have thought that forking at the component or perhaps even package level is more likely. It's the package owners' job to try and avoid this, but even if it did come to, say, a package forking it wouldn't necessarily be disastrous because it should be fairly well insulated from the rest of the OS.

So, let me get this straight: I won't advocate/pledge my allegiance to 'open source' just to remain cool and fashionable on these pages. I like finished products, in neat packages, as long as I can pay for them. That's why I am writing this on Windows 7 and couldn't be happier in the process: to me, MS made a product and put a price tag on it, and I chose to pay that price, so MS aren't evil expecting to charge on something they made, and that's that.

That said, I did move recently to Maemo (i.e. Nokia N900) to have a taste of user-generated content and truly open platform. My conclusions, as an average, non-geek user, may not resonate with the 'techy-geek' crowd, but here they are:

1) The main strength of Maemo is what Nokia built into it. If it had been broken, or inconvenient to use, I wouldn't have bothered with it. Whether Nokia charge for this or not (they DO charge for the hardware after all, and it is not hard to imagine that they are also setting off their Maemo R&D somewhere in those 500 odd USD), is irrelevant in this case. Good software is good, whether it is open source or closed.

2) I have great, great respect for the Maemo community, who have weathered a sudden increase in userbase and expectations, and are coping with it. It is heartening to see so many people coding software voluntarily, and working for the REAL good of humanity (no kidding here)

3) That said, the community is not paid programmers. So, inevitably, every software that becomes available for Maemo is a work in progress, and will forever remain so. As an end user, that's irritating to me; I am accustomed to a corporate overlord looking after my hardware and software needs, and paying people to do so, so in the end you tend to get a finished product that is streamlined and easy to use.

Make no mistake, despite Maemo being open source, I PAID to get on the bandwagon, and I paid as much as I would for a top-line Symbian or Android or WM handset. In the end, I am entitled to expect the same quality of Apps as I get on those platforms, but sadly, that is not the case.

oscillik wrote:Then Symbian happened. And we get three different variants of Symbian, those being Quartz (UIQ), Crystal (Series80), and Sapphire (Series60).

Series 60/S60 was Pearl, not Sapphire.

Hello everyone,
Thanks for reading the editorial and leaving such interesting comments. I thought I should come in and make a response/defence.

I'm glad Rafe came in and changed my wording from fork to fragmentation.

Particularly I wanted to respond to this post:

Mark Wilcox wrote:This whole article is based on a licensing mis-understanding:

"Being released under the Eclipse Public Licence (EPL), anyone can take the source code, do anything they like with it, and not contribute any code back to the Symbian Foundation."

This is wrong!

The EPL is a weak copyleft license. If anyone changes any of the platform code then they have to release the source code to those changes. What they can do is add extra components or replace components and keep the code for those closed.

I would say that the point in bold is the critical point here, and is how I understood the licence. The fact that anybody can keep anything closed opens the door to fragmentation.

Mark Wilcox wrote:

In addition to this, Symbian will have a compatibility program such that if OEMs don't maintain binary compatibility for the public APIs then they can't use the Symbian name (i.e. they can't claim it's a Symbian device if it isn't compatible).

An OEM can create their own UI, but they have to keep Qt compatibility (Symbian^4 onwards) for example, so all the apps that are built on Qt will work across all devices.

This is in contrast to Android, which has a permissive license (Apache) and no compatibility promise, for which the original statement would be correct.

Hope that helps clear it up.

Not that all of that doesn't prevent someone forking Symbian and us not wanting to take the changes back, but it does make it very much less likely. Even the GPL hasn't stopped Google forking the Linux kernel, so it could happen.

It does of course help that there will be compatibility checks and that apps will work across all variants.

However, I don't think that this completely helps the problem I discussed. It's all about consumer perception, and confusion. Any brand differentiators could lead people to hesitate and ask which should I buy? It all depends how great these differences actually are.

Also, I don't think that Symbian has done the wrong thing by going open. It was a brave and bold move, and for what it's worth, I think it was the right thing to do. My message to Symbian is simply - be careful, and I wish you well.

@Rafe:

As others have noted in the comment thread, the EPL license does have strong copyleft clause, which should discourage forks.

Note that the EPL has a weak copyleft clause, the GPL has a strong copyleft clause.

@David:
I take your point, but would claim that your argument has nothing to do with license choice, or open source. For example any Linux-based platform can have very similar fragmentation, since there's no restriction on the licensing used for user-space programs, and kernel modules can be replaced. At the same time, proprietary platforms also have differentiation/fragmentation of exactly the same kind. For example look at the different UIs and hardware features that have shipped with Windows Mobile devices, or Symbian before it went open.

The only platforms that avoid this are single vendor platforms. If you have multiple vendors using the same platform, then they will want to differentiate from one another. One man's differentiation is another man's fragmentation.

What Symbian is working hard on is ensuring that the fragmentation doesn't impact application developers (unless they choose to use features which we don't provide compatibility promises for).

It's worth noting that the people impacted by the confusion you mention are limited to the small minority who know about the platform running under the hood but don't understand anything about the rest of the way the industry works.

e.g. Why can't I have Ovi services on my Satio? Of course they would run, but why would Nokia provide services to SEMC customers?

Most consumers are completely oblivious to the platform and expect Nokia services to run on Nokia devices etc. Of course the Symbian Foundation can help to educate the tech-savvy consumers, but perhaps the best way for us to do that is through existing communities, like the one here at AAS.

Unregistered wrote:Series 60/S60 was Pearl, not Sapphire.

i can use wikipedia too, obviously better than you:

"Only Sapphire came to market, evolving into the Pearl DFRD and finally the Nokia Series 60 UI"

henceforth, Sapphire was actually S60

Mark Wilcox wrote:@Rafe:
but perhaps the best way for us to do that is through existing communities, like the one here at AAS.

you just talked youself into doing a guest publication on AAS to educate us more on his subject 😊 :icon14:

Mark Wilcox wrote:@Rafe:

Note that the EPL has a weak copyleft clause, the GPL has a strong copyleft clause.

Arggh. Sorry about that. It's right in my head, but it didn't translate to my fingers (now corrected).

Ensuring compatibilities for developers is a worthy goal and I think this should be sucessful for the immediate and generally forseeable future. Within the caveats of being the platform / public APIs rather than any manufacturers differentiation ones.

But also worth noting that, generally, some of this is about perceptions. Yhese can be very strong in the consumer mindset regardless of accuracy (e.g. the Symbian is dead theme from last year).

@talhamid

I'm sorry, but you (as many others) have mistaken open source being free with "free as in beer". I personally pay for , and enjoy the services of Mandriva Linux. Yes, I am "paying" for my open source software, kind of like the same way you are paying for maemo.

Open source is "free as in speech". By this I mean the source code is freely available, for anyone to use. The beauty of this arrangement is whilst I'm paying for services through Mandriva (as you did with your one time payment to M$ for Win7) I can freely chose to go other places for the service, if I'm unhappy. This is because the software in it self is free (as in speech), hence I can get the same programs etc. with Ubuntu or similar.

But the thing is I like Mandriva's choice in packaging. I like their design and they have the right combination between bleeding edge and stable software for me. If they fail me I can always switch.

What you get for shelling out money to M$ is what is called vendor lock in. You can use the OS on one computer, run apps on it, but if something happens that makes you want to switch then you in reality can't. You have paid to make yourself dependent on 1 proprietary platform.

What Nokia has done with Maemo, and are doing with Symbian is nothing short of brilliant. They concentrate on the hardware and then create a community to help maintain and develop the software. This will hopefully soon include other companies that plan to make a little $$ on these truly open platforms. After all, the only place real value is generated from software is when it is implemented.

Unregistered wrote:
What you get for shelling out money to M$ is what is called vendor lock in. You can use the OS on one computer, run apps on it, but if something happens that makes you want to switch then you in reality can't. You have paid to make yourself dependent on 1 proprietary platform.

That makes no sense. If I have paid for Windows then I am not free to go off and get a Mac, or install Linux if I want to?

I just paid for a Snow Leopard upgrade, so I am probably going to jail.