>I thoughts comments on your other blog post are frozen similar to discussion threads on nokia forum. But I am delighted that you took your time and tried to understand developers' needs.

Although I am not able to reply to all the points that are raised in comments to my blog postings, please be assured that I do read all comments carefully, and I have a long list of matters arising which I am engaged in progressing.

I want to keep the good threads of discussion alive, but equally important, I want to use my time and effort to deepen my understanding of what look like key issues, and then to identify and implement solutions. That often takes a lot of time – so please forgive periods of radio silence on my part.

Hi Mark,

>Once the foundation platform is open it should be possible to change anything you need to access (as long as it's done in a way that doesn't negatively impact anyone else) but there will still be an advantage of time for Nokia and other device manufacturers. They can implement their innovations on the next device they release. Other third party software vendors will have to wait for the next platform release to be taken into devices, after they've got their changes to the platform approved/included. Also, the device manufacturers can bundle firmware patches for old devices with their applications if needed.

>I think the only way around this is full patching of device firmware (either MS style "you need to download an update to use this…" or some kind of officially sanctioned patches to bundle with third party applications). Will consumers go for it? It's certainly technically possible already. Will device manufacturers implement it (they'd have to manage the firmware updates)? Is it at all practical?

My own view is that seamless downloading of validated updates to system software, in support of new application features, is going to become more and more prevalent. As you say, the technical issues have largely already been solved. It will come down to smoothing the distribution channel and the user experience. This kind of remote device management will fit nicely alongside Symbian Apps Store functionality.

// dw2-0

>I thoughts comments on your other blog post are frozen similar to discussion threads on nokia forum. But I am delighted that you took your time and tried to understand developers' needs.

Although I am not able to reply to all the points that are raised in comments to my blog postings, please be assured that I do read all comments carefully, and I have a long list of matters arising which I am engaged in progressing.

I want to keep the good threads of discussion alive, but equally important, I want to use my time and effort to deepen my understanding of what look like key issues, and then to identify and implement solutions. That often takes a lot of time – so please forgive periods of radio silence on my part.

Hi Mark,

>Once the foundation platform is open it should be possible to change anything you need to access (as long as it's done in a way that doesn't negatively impact anyone else) but there will still be an advantage of time for Nokia and other device manufacturers. They can implement their innovations on the next device they release. Other third party software vendors will have to wait for the next platform release to be taken into devices, after they've got their changes to the platform approved/included. Also, the device manufacturers can bundle firmware patches for old devices with their applications if needed.

>I think the only way around this is full patching of device firmware (either MS style "you need to download an update to use this…" or some kind of officially sanctioned patches to bundle with third party applications). Will consumers go for it? It's certainly technically possible already. Will device manufacturers implement it (they'd have to manage the firmware updates)? Is it at all practical?

My own view is that seamless downloading of validated updates to system software, in support of new application features, is going to become more and more prevalent. As you say, the technical issues have largely already been solved. It will come down to smoothing the distribution channel and the user experience. This kind of remote device management will fit nicely alongside Symbian Apps Store functionality.

// dw2-0

You are absolutely correct of course. The development teams in Nokia will have to adjust to a much more open mode of working.

Hopefully the shame factor will prevent too many quick hacks getting into the foundation code. This sort of area we’re discussing never would have got anywhere near Symbian (the OS team as you put it) though. A quick change to the sysapp is all that’s required for permanent key routing to a specific application.

The really important thing will be how much is guaranteed compatible for a Symbian Foundation phone, which is one of the issues David is describing above. A sysapp is likely to be part of the platform but there’s nothing to stop device manufacturers shipping a modified version of it in the firmware. It is a quick and easy way to make device specific modifications for things like slide or fold detection and extra hardware keys like a camera or music button.

I have high hopes for the Symbian Foundation but I don’t think we’re likely to see quite the level playing field that you’re asking for – it would be too much of a burden for the Nokia development teams.

Whatever happens it will be much better than iPhone, where your application would just get barred from the store for competing with an Apple application. Now that’s anti-competitive!

@Rick
There is no server behind CMdaAudioPlayerUtility, the architecture is plug-in based. There is/was a vendor ID check in the low-level audio server (beneath DevSound) which was, as I see it, security goof and Nokia released the Audio Proxy Server as a workaround until an appropriate API could be delivered.

I honestly believe that at least 90% of the things that people get wound up about result from the fact that Nokia are focused on delivering products with the required functionality on time. The “platform” aspects have been a bit of an afterthought, at least until recently. It’s not that they don’t care or didn’t want to build a developer platform, it’s just a case of limited resource and other business priorities.

They test devices for BC on all the published APIs but developers always want to do more. Hence open source! This isn’t going to fix the problem overnight but it will make everything more transparent.

Personally I’d much rather Nokia build great products that ship hundreds of millions of units which I can target with applications than be completely open and let developers change everything (the IMHO empty promise from Android) but not ship many devices. If I wanted the latter I’d write apps for Openmoko.

Mark

You are absolutely correct of course. The development teams in Nokia will have to adjust to a much more open mode of working.

Hopefully the shame factor will prevent too many quick hacks getting into the foundation code. This sort of area we’re discussing never would have got anywhere near Symbian (the OS team as you put it) though. A quick change to the sysapp is all that’s required for permanent key routing to a specific application.

The really important thing will be how much is guaranteed compatible for a Symbian Foundation phone, which is one of the issues David is describing above. A sysapp is likely to be part of the platform but there’s nothing to stop device manufacturers shipping a modified version of it in the firmware. It is a quick and easy way to make device specific modifications for things like slide or fold detection and extra hardware keys like a camera or music button.

I have high hopes for the Symbian Foundation but I don’t think we’re likely to see quite the level playing field that you’re asking for – it would be too much of a burden for the Nokia development teams.

Whatever happens it will be much better than iPhone, where your application would just get barred from the store for competing with an Apple application. Now that’s anti-competitive!

@Rick
There is no server behind CMdaAudioPlayerUtility, the architecture is plug-in based. There is/was a vendor ID check in the low-level audio server (beneath DevSound) which was, as I see it, security goof and Nokia released the Audio Proxy Server as a workaround until an appropriate API could be delivered.

I honestly believe that at least 90% of the things that people get wound up about result from the fact that Nokia are focused on delivering products with the required functionality on time. The “platform” aspects have been a bit of an afterthought, at least until recently. It’s not that they don’t care or didn’t want to build a developer platform, it’s just a case of limited resource and other business priorities.

They test devices for BC on all the published APIs but developers always want to do more. Hence open source! This isn’t going to fix the problem overnight but it will make everything more transparent.

Personally I’d much rather Nokia build great products that ship hundreds of millions of units which I can target with applications than be completely open and let developers change everything (the IMHO empty promise from Android) but not ship many devices. If I wanted the latter I’d write apps for Openmoko.

Mark

I thoughts comments on your other blog post are frozen similar to discussion threads on nokia forum. But I am delighted that you took your precious time and tried to understand developers' needs.

Strength of open platforms is that The sky is the limit for implementing your ideas and community can also benefit from developer's work if they develop new APIs. Ofcourse Symbian has limit somewhere in developing new APIs, but developers can help in that and make platform much stronger much faster.

@Pault@Wilcox
Pault really hit the right issue and there need to be some concrete steps to rebuild the faith. There are other examples in the list I am touching one more to illustrate Pault's comment in more detail. OS provides CMDAudioPlayerUtility to play audio but Nokia has inserted its own VendorID in the server (which is part of OS) and restricted it for 3rd party developers.

>>Parts of the source code will be released, in a staged manner, at various phases during 2009<< && >> the new bias will be, "release the code, unless there's a very strong specific reason not to do so"<<

Best promise from Symbian so far, I must admit.

Thanks Again. Looking forward to a better tomorrow with Symbian.

I thoughts comments on your other blog post are frozen similar to discussion threads on nokia forum. But I am delighted that you took your precious time and tried to understand developers' needs.

Strength of open platforms is that The sky is the limit for implementing your ideas and community can also benefit from developer's work if they develop new APIs. Ofcourse Symbian has limit somewhere in developing new APIs, but developers can help in that and make platform much stronger much faster.

@Pault@Wilcox
Pault really hit the right issue and there need to be some concrete steps to rebuild the faith. There are other examples in the list I am touching one more to illustrate Pault's comment in more detail. OS provides CMDAudioPlayerUtility to play audio but Nokia has inserted its own VendorID in the server (which is part of OS) and restricted it for 3rd party developers.

>>Parts of the source code will be released, in a staged manner, at various phases during 2009<< && >> the new bias will be, "release the code, unless there's a very strong specific reason not to do so"<<

Best promise from Symbian so far, I must admit.

Thanks Again. Looking forward to a better tomorrow with Symbian.

The point being is that the applications team would need to go to the OS team who would then have to provide an open API as this is going into public facing code, otherwise the fallout from having hard coded hacks in public source code would be very negative for all concerned. The OS team would also be incentivized to produce both timely and good quality code so the apps team could roll out their application.

It could have been IMHO easy to setup PS keys to handle the headset features and expose these keys out of the remote control API, still no use crying over spilt milk as the saying goes…

The point being is that the applications team would need to go to the OS team who would then have to provide an open API as this is going into public facing code, otherwise the fallout from having hard coded hacks in public source code would be very negative for all concerned. The OS team would also be incentivized to produce both timely and good quality code so the apps team could roll out their application.

It could have been IMHO easy to setup PS keys to handle the headset features and expose these keys out of the remote control API, still no use crying over spilt milk as the saying goes…

I have to start by saying I agree that Nokia have to play fair or it isn’t going to work. People will take their toys and play elsewhere.

But that’s the solution in cases like this: take your innovation and implement it on another platform – if you can. Microsoft gets sued because they have an established monopoly and they abuse it. I think regulators will let market forces work out who’s allowed to do what in the mobile space for a few years yet.

The chances are (and I don’t know for sure in this case) that the headset buttons are hard-coded to the built-in music player and there is no way to register to recieve them in another application (I do know for sure of other cases that work like this). That’s why you can’t get an API, rather than any deliberately anti-competitive behaviour.

Once the foundation platform is open it should be possible to change anything you need to access (as long as it’s done in a way that doesn’t negatively impact anyone else) but there will still be an advantage of time for Nokia and other device manufacturers. They can implement their innovations on the next device they release. Other third party software vendors will have to wait for the next platform release to be taken into devices, after they’ve got their changes to the platform approved/included. Also, the device manufacturers can bundle firmware patches for old devices with their applications if needed.

I think the only way around this is full patching of device firmware (either MS style “you need to download an update to use this…” or some kind of officially sanctioned patches to bundle with third party applications). Will consumers go for it? It’s certainly technically possible already. Will device manufacturers implement it (they’d have to manage the firmware updates)? Is it at all practical?

To some extent we have to accept that smartphones aren’t quite PCs yet and live with the limitations. With the foundation you should at least be able to get them fixed in the next version and even contribute the code to do it (or pay someone else to) if you need to speed up the process.

Mark

I have to start by saying I agree that Nokia have to play fair or it isn’t going to work. People will take their toys and play elsewhere.

But that’s the solution in cases like this: take your innovation and implement it on another platform – if you can. Microsoft gets sued because they have an established monopoly and they abuse it. I think regulators will let market forces work out who’s allowed to do what in the mobile space for a few years yet.

The chances are (and I don’t know for sure in this case) that the headset buttons are hard-coded to the built-in music player and there is no way to register to recieve them in another application (I do know for sure of other cases that work like this). That’s why you can’t get an API, rather than any deliberately anti-competitive behaviour.

Once the foundation platform is open it should be possible to change anything you need to access (as long as it’s done in a way that doesn’t negatively impact anyone else) but there will still be an advantage of time for Nokia and other device manufacturers. They can implement their innovations on the next device they release. Other third party software vendors will have to wait for the next platform release to be taken into devices, after they’ve got their changes to the platform approved/included. Also, the device manufacturers can bundle firmware patches for old devices with their applications if needed.

I think the only way around this is full patching of device firmware (either MS style “you need to download an update to use this…” or some kind of officially sanctioned patches to bundle with third party applications). Will consumers go for it? It’s certainly technically possible already. Will device manufacturers implement it (they’d have to manage the firmware updates)? Is it at all practical?

To some extent we have to accept that smartphones aren’t quite PCs yet and live with the limitations. With the foundation you should at least be able to get them fixed in the next version and even contribute the code to do it (or pay someone else to) if you need to speed up the process.

Mark