The risk of opening Symbian
Published by David Gilson at 18:41 GMT, February 11th 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.
Before I begin, I will state two things for the record. First, I was a Psion user back in the day, and so I want to see Symbian do well. Second, I'm an ardent supporter of open source software, and have been exclusively using Linux as my desktop operating system since March 2009.
I took a step back to think when I saw the news about Symbian completing its transition to open source. 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. On first impressions, this is a positive move for Symbian. Whenever developers find an OS bug, they can get in there and fix it themselves, if they are so inclined. Maybe contributing such fixes back, as long as the Symbian Foundation is seen to be efficient at committing patches. Also, new blood will be brought into the developer community, so that future incarnations of Symbian should be much more contemporary and enjoyable to use. A more disingenuous interpretation would be to say that this is Nokia and Symbian tacitly admitting that they have lost their edge with design and need the public to come in and blow away the cobwebs. Nevertheless, we all hope the end result will be the same - a more invigorated and fast moving ecosystem.
Furthermore, by having such a pervasive licence, the factor of market share is surely going to come into play. More manufacturers could now be encouraged to dip a toe into the Symbian world, which means more Symbian handset sales will be totted up when the analysts write their quarterly reports. Of course, this is just the potential, we have yet to see how it will play out. However, as more manufacturers choose to use Symbian, the better the chances are that they will in turn be paying employees to work on developing the platform, so everybody benefits ... don't they?
This is where my concern creeps in. Everyone is now free to use and adapt Symbian however they want, which means we could have a broad spectrum of Symbian variants on the market. This is generally referred to as platform fragmentation. This isn't a symptom of the EPL licence, as the same would apply even if Symbian had chosen one of the more widely known GPL licences (and probably more so given the license terms). The fragmentation issue is not new, nor is it limited to the open source world. For example, the closed source Symbian world has S60 3rd edition and S60 5th edition. Trying to tell a non-techie user that they can't run such and such an application because their phone is a 3rd edition handset rather than a 5th edition handset is probably going to meet with confusion at best, and at worst frustration and disenchantment.
Moving into the open(ish) source world and we see the same problem with Android. There are in fact (according to Engadget) three versions of Android, not to mention custom front-ends, such as HTC's "Sense" and Motorola's "Blur". To some potential buyers, this might not be an issue, they'll take anything as long as it has a touch-screen and whizzy interface. Although to others, it could cause confusion and make them hesitant to spend their money, with the perennial question, which should I choose? Moreover some of these front ends are causing problems for third party application compatibility.
Moving beyond the mobile world, I believe this fragmentation and wide degree of choice is half the problem of why the Linux desktop hasn't taken off. We can cast aside the arguments of Linux is too technical for ordinary people to use. Modern day Linux is just as easy to use as Windows, and the fact that it is behind Android and Maemo shows that it can be very user friendly. No, the real hands-on technical difficulties with Linux come from hardware compatibility issues, which is the other 50% of Linux's problems. I digress however, the 50% that is relevant to this discussion is that of mind-share. If you want to get Linux you don't just make the decision and say I'll go to Linux's website and download Linux. No, you have to choose which distribution you want: Debian, Fedora, Ubuntu, Open Suse, etc. Then, you even need to choose which desktop environment we want to use, e.g. GNOME, KDE, XFCE, etc. It is all of this choice, that I'd rather have than not have, which effectively dilutes mind-share, and makes uninitiated users not understand what is what.
In contrast, consider the iPhone. As objectionable as I find their closed and restrictive environment, at least you know what you're getting when you buy one. Quite simply, there is only one iPhone OS. Although it is worth noting that the current state of affairs with iPhone OS may not continue forever.
Which brings me back to the opening of Symbian. The open sourcing of the platform will encourage more companies to use it. I sincerely hope that we don't see various manufacturers fragmenting the platform, and thus creating a veritable zoo of Symbian variants. Surely, it is better for everyone if contributors and manufacturers alike stick to contributing to a common set of code, and handsets are proudly announced as being a Symbian phone. The alternative is that Symbian only gets contributions from Nokia and a loyal community of developers, while other manufacturers go off spending money on their own closed version of Symbian. Which would again leave consumers confused as to whether they should go for a pure Symbian phone, or to try finding out who makes the best variant of Symbian!
In closing, I hope that any manufacturers reading this will take it as a plea for common sense. Let's have the best of both open and closed worlds, a single strong Symbian that we all contribute to and benefit from.
David Gilson for All About Symbian, 12th February 2010.
You can find me on my blog, and as @davidgilson on Twitter.
Update: Rafe's comments
I've updated this editorial to use 'fragmentation' rather than 'fork' in the meat of the discussion. As others have noted in the comment thread, the EPL license does have weak copyleft clause, which should discourage forks. However the same license encourages manufacturers to differentiate on top of Symbian. Symbian are planning a device certification program, which will require binary compatibility with the public APIs. The entire set up of the Symbian Foundation is predicated on encouraging openness and co-operation between those using and contributing to the platform. How well this will work in practise remains to be seen and, as such, fragmentation remains a very much a valid concern.
Clearly there is a balance to be drawn between differentiation on top of the platform and maintaining platform compatibility across devices. A good example are the current Symbian^1 devices from Nokia (N97 mini) and Sony Ericsson Satio, which have different homescreens and media players, but are compatible with each other as far as third party applications are concerned.
Read the comment thread for more, there are some great insights.
Categories: Comment
Platforms: General
Feature Discussion
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?
- 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.
"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.
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.
|
Originally Posted by mikescandy
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.
|
|
Originally Posted by imcdnzl
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. |
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.
|
Originally Posted by Unregistered
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. |
Yes, I think this was the kind of thing that David had in mind. David? Any response to all this?
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 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...
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.
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.
|
Originally Posted by oscillik
Then Symbian happened. And we get three different variants of Symbian, those being Quartz (UIQ), Crystal (Series80), and Sapphire (Series60).
|
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:
|
Originally Posted by Mark Wilcox
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. |
|
Originally Posted by Mark Wilcox
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. |
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.
| As others have noted in the comment thread, the EPL license does have strong copyleft clause, which should discourage forks. |
@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.
|
Originally Posted by Unregistered
Series 60/S60 was Pearl, not Sapphire.
|
"Only Sapphire came to market, evolving into the Pearl DFRD and finally the Nokia Series 60 UI"
henceforth, Sapphire was actually S60
|
Originally Posted by Mark Wilcox
@Rafe:
but perhaps the best way for us to do that is through existing communities, like the one here at AAS. |