The UIQ Evangelist

I wonder about the reason for ending up with an “Open platform” (and probably overshoot the target completely, expecting much more than is reasonable).

part VIII, “The ‘Open platform’ paradigm”.

What we have been looking at throughout this series (apart from how much it’s possible to slag off against Sony Ericsson without descending into pure namecalling) is really the duality on different levels between need for provider control, and the demand for a carefully customized and versatile product.

And while there are different solutions to answer those types of demands - in the mobile business the choice seems to outlined by the following extemes. One: to make the APIs used in internal development public (after everyone gives up making sense of the documentation when they try to improve the software). Two: releasing a special set of APIs, particularly written for a limited set of functions. Typically to ensure that development of programs will be quick, as well as for security reasons every mobile operator is interested in (from having to do with protecting interface code from abuse, to ensuring few returns due to user- installed programs. Three: make all the improvements internally, and release new functions as they happen to be finished. And four: create a framework, and sell licensed tools to third parties who wish to develop for the platform.

Currently, it appears that “Open platform” is defined as being somewhere in between those four options. For example, Symbian released their usable apis to the public, and will provide their close partners with the source code necessary to create certain other functions. Which means that some functionality on the phones will forever be closed off to independent developers, and those who would have the resources to start building from the source- code will rather choose a more flexible platform.

^{Dali says: ach, my head hurts just thinking about it.}

Another fine example of this approach is the iPhone, which comes with a software developer kit that exists in a preconfigured environment, that cannot access typical system- functions, will not be able to use VOIP, various other data- services, or multitask.
From the manual:

Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits.

Either company also have their own brand of distribution control (although content control is something only Apple claims so far).

In other words, “Open platform” might mean a great deal of different things - apart from the obvious.

All right - so there are a lot of limitations on the platform - on any mobile platform. So what, there’s always some limitations, right? It’s not open source either. Live with it, and so on. Well - the question is what the extent of the limitations are, and why this brand of closed approach was chosen (apart from hiding ugly coding practices, of course). Since for the most part, these companies do not maintain their apis, provide them in a very conscious fashion (except when limiting their usefulness), or attempt to work with developers to fix holes in the existing framework.

And as failing to do this, very obviously, will not actually create the environment where developers will work to create their own programs to expand the usefulness of their gadgets - while at the same time promoting the platform and it’s owner - this puts into question the entire scheme. Imagine, for example, if someone wanted to write a program for UIQ that could use the in- built proprietary syncronisation algoritm process (*breathe*) of the open SyncML standard to sync only part of the calendar (..say, the non- private bits) - this is simply physically impossible to do, without also sitting on the source- code. Which, if you did, very likely wouldn’t do you much good anyway, since you’d likely have to reprogram the entire api - and who knows what other unexpected problems that might cause.

That is not to say, of course, that some limitations are not useful - for example limiting a program from being able to write to other program- areas, or preventing direct access to ram, is something that shouldn’t be and isn’t necessary. But what about trying to improve the framework package, and actually provide and maintain a flexible api framework for the device’s various functions? And ensure that opening up parts of the source code can be safely done, while consciously protecting particular code segments that should be protected (instead of locking the functionality they are supposed to carry)?

The answer of course, is that this natural and logical progression for expanding the platform was never intended in the first place. In fact, we should be quite happy with being given any opportunity to develop as independents at all, when we promote their platform for free. And so the “Open platform” becomes one with very limited functionality, and many difficulties when trying to exploit it for something useful - in other words, a gimmick.

next: part IX, “Feature phones vs. expandable devices”.

Categories: Comments, Operating Systems, Uncategorized
Tags: Development, OS, upgrades