What's The Opinion of Nokia Developers About the Nokiasoft Partnership?
Linked by Hadrien Grasland on Mon 28th Feb 2011 11:23 UTC, submitted by Joao Luis
PDAs, Cellphones, Wireless "Now that the dust has settled after Stephen Elop's big announcement on the 11th February 2011, many have come to realise that actually Nokia's move towards a a new Ecosystem is not as bad as what they thought. [...] But what does all this mean for the Nokia Developers? When the proposed partnership with Microsoft was announced, many felt betrayed and worried about their future, but after having heard and assisted a number of workshops at the Nokia Developer Day at this years Mobile World Congress in Barcelona, earlier this month, their outlook towards the new ecosystem has taken a 180 degree turn and are now looking at the proposed partnership with a lot more enthusiasm, recognising the potential it will bring them in the coming months."
E-mail Print r 1   75 Comment(s) http://osne.ws/ivt
Thread beginning with comment 464435
To view parent comment, click here.
To read all comments associated with this story, please click here.
saso
Member since:
2007-04-18

Can Not (it is fundamentally the same as Meego). There isn't a major problem with its arch other than the fact that it is old and unmaintained and incompatible with the modern meego specs.For application development it is fine, but as a finished and hardened product, No.

Is there even system wide support for rotation, a modern kernel, recent X?


I agree that it is unmaintained, but "old" is a very relative word. Debian can easily bridge package version gaps far larger than ~1 year.

Then you have people using lower level frameworks that bring issues when using higher level frameworks. Fundamentally things will run on both, but there is breakage between distros especially at lower level userspace.


Please, do provide specific examples. My experience is that I've ported many years old and unmaintained software to newer systems with a mere recompile (if the binary didn't just work out of the box anyway), even between fundamentally different operating systems (Linux, Solaris, Windows, etc.). If you plan ahead and don't tie yourself to too many platform specific features, porting becomes relatively trivial.

There is also a serious issue having two frameworks and telling developers "here start with this, it is old and unmaintained and just wait for the new hotness to come in bits and pieces" or "here use this, we will be replacing it soon so watch out". This has the potential to create huge fragmentation, magnitudes worse than what is seen in android. Ultimately they aren't aiming for an n900 where most of the community are developers, they want a consistent product or none at all.


Well, depends on what you consider to be "soon" and Gtk support can clearly be marked as legacy and/or deprecated, much in the same way Apple had supported Carbon on OSX, even though Cocoa was the right way to do it. Clearly it can be done.

Also I have a particular problem with the "we want customers, not developers" attitude that many companies exhibit. They assume they are in it alone and that they ship a closed and boxed product that you throw away after having used it more or less without modification. This was true for dumb and feature phones, but not at all for smart phones. With smart phones, people don't just want the "out of the box" experience, they download software, modify settings and often do crazy things with their hardware. That's the difference between platform and ecosystem. The aforementioned attitude is exactly what got Nokia into this mess.

Reply Parent Score: 2

_txf_ Member since:
2008-03-17

Please, do provide specific examples.

Init Systems and Package Management Come to mind..

Well, depends on what you consider to be "soon" and Gtk support can clearly be marked as legacy and/or deprecated, much in the same way Apple had supported Carbon on OSX, even though Cocoa was the right way to do it. Clearly it can be done.


The problem is that application developers would have to start out with a gtk api then have Qt apis. So some apps would be using gtk libs and others Qt libs. And then you have both libs loaded on a memory and power constrained device

Also I have a particular problem with the "we want customers, not developers" attitude that many companies exhibit. They assume they are in it alone and that they ship a closed and boxed product that you throw away after having used it more or less without modification. This was true for dumb and feature phones, but not at all for smart phones. With smart phones, people don't just want the "out of the box" experience, they download software, modify settings and often do crazy things with their hardware. That's the difference between platform and ecosystem. The aforementioned attitude is exactly what got Nokia into this mess.


Problem is that to get the best developer output you have to provide them with a sane base to work with. This means no deprecated apis at the start of a products lifetime (that is absolutely insane but it is what you're proposing), no conflicting apis or two apis to do the exact same thing, sensible apis, a sane development environment, decent documentation. Qt has all of those things, keeping gtk in the forefront would have just muddied the waters.

Reply Parent Score: 3

spiderman Member since:
2008-10-23

And then you have both libs loaded on a memory and power constrained device.

Nokia solved that problem on the N900 by providing a swap partition. Android and iOS solve that problem by not multitasking.

Reply Parent Score: 2

Read more of this thread... >