"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."

Can you please point me to some concrete objections to Maemo's architecture?

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 said no such thing. What I did say was that the framework stacks should be sufficiently similar. To illustrate my point: Gtk, Qt and a whole bunch of other frameworks (libraries) run just fine on both Fedora and Debian (and nearly any other distro, for that matter). Obviously not everything could be ported, e.g. software that messes around with distro-specific bits of the OS. However, well written software should not be that difficult to run nearly unmodified in either environment.

There is the current Qt mobility and Multimedia framework which abstracts things away. Power considerations, space considerations that are magnitudes worse in mobile environments. 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.

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.

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.

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.