The problem with Nokia n900 is not the device it self but Nokia's mentality. What do I mean by that? Well Nokia always has some big plans ahead that it can never fulfill, example the Nokia N-Gage the handheld game system should have been as revolutionary as Nokia said it was but instead sold only 3 million with losses from piracy. Another example the Nokia n97 wasn't that thing supposed to be the cream of the crop Nokia's flagship that thing you would spend 700 bucks on instead it was slow, buggy, and had crap hardware and Nokia loosed many customers and the Nokia n97 was abandoned very quickly in favor of the Nokia n900. The Nokia n900 was proclaimed to be the greatest thing Nokia pulled out of there ***** in years and Linux nerds and Nokia nerds shouted for joy only to have that joy killed by Meego and the fact that Nokia has made a device that is barely a year old into a legacy device living off of community support. If I remember exactly some stupid words like "to ensure the best user experience". No to Meego if Nokia expects Meego to succeed then Nokia needs to develop it properly not release a half baked os like they did on the n900 and n97. So in conclusion Nokia has had many good ideas just what they need to do is spend for time and effort to developing those ideas and to make sure they are executed well.

railroadmaster, your thoughts are appreciated but please try to frame them in the spirit of the rest of the thread so that we don't get distracted, thanks.

Sorry about that .

Well put it this way Nokia n900 had its ups and downs. I will have to go through the depression of knowing Maemo is dead oh well. While Meego looks promising and Nokia n900 and Nokia n810/n800 ports coming soon we will miss Maemo rest in peace. Also I hope this isn't as bad as when Symbian Uiq died, dang it I'm still waiting for Uiq 4.0 to come out. Death of Sony Ericsson kseries was sad. Does this mean the death of Nokia Internet Tablets because that is very sad.

I like idea of Maemo, but the idea is not the same is it in real life. and i even don't talk about improvements and the feeling that it's not developed any more(and it it's not release yet as i see it) , but even serious bugs that reported over and over and you even don't know if they would be fixed. i can't expect phone starting to play music suddenly in the middle of meeting. or other small but important and unpleasing things. As well i don't think support suddenly should stop, as for example port of new flash. also all that cool and crazy stuff nokia showed on youtube videos and never released in public (shazam, roller coast that actually was even announced not once) and you don't get any answer why. you can't buy something if you don't know it's future.

I don't think that is what Gazza was referring to. At the moment you flash (or OTA upgrade) your N900 to the latest Maemo firmware. This contains all the updates for all the applications supplied by default. This means that, for example, a small bug in the music player app that alone would take an hour to fix, test and release, instead has to wait our for a month or two while a mass of other components are also tested. Gazza is pointing toward Nokia using the Deb (or RPM in Meego) repositories to release updates for components as they are available - not necessarily part of the firmware or a 6 monthly release. This stems from fact that when you're using a desktop system you see these bug fixes and features arriving daily (on Ubuntu at least). By all means, yes, it makes sense to "synchronise" every 6 months for an official release, but don't hold back on releasing bug fixes as they are available.

Google are currently doing this with Android for version 3.0 (minimise the firmware, make their applications available separately) so that they can deliver fixes and features in their applications faster than the hardware vendors can test and release new firmware updates (if they bother at all).

This might be nice for the user, but is a maintenance nightmare.
Nearly every bugreport lacks the version information. In the big-lump-of-enforced-upgrade mode you need a lot less QA manpower to track problems.

Nokia's contributions to other open source products aren't what interests me. I'd imagine Nokia would have to make them public for obvious reasons...

Rather, I'm talking about the majority of Nokia's code, code that Nokians have written from the ground-up.

The Phone UI application and its corresponding library (/usr/bin/librtcom-call-ui.so) are closed. Say what you will about Android but I can see the source to their phone application right now, in their Git repository. No, I'm not interested in the possible MeeGo version; I'd like to see Fremantle's version.

It seems that for almost every open source Nokia project, there's a closed source one utilising it.

libhildonfm2 - OSSO File Manager
MAFW - Media Player

(Oh, Nokia have much more open source code than this; don't take the above as my count of Nokia's open code)

And for the open source Control Panel, well, most of Nokia's applets are closed...

We have the Hildon widgets, fully open source, but then we have the HildonTimeZoneChooser (note in that link that it is me defining the [guessed] function signatures. I don't even want to mention how many closed source libraries I'm linking that to), used in the (closed-source) Clock application and closed-source Date & Time applet. Not only is this time zone chooser put in a separate library, but it's closed source and no -dev package was produced so that it could be used by other applications.

Talking of not seeing any headers, we're stuck with the libconic library whilst Nokia get to use the much better libconnui library in their applications. For one, it features use of the much better ICD2 D-Bus API instead of the ICD D-Bus API utilization found in libconic.

And even Hildon Desktop and the Hildon Application Manager have moved down a step in openness: They now depend on closed source components.

The two applets (Memory/LED Patterns Notifications) I mentioned are trivial, there's no point in opening them but they're examples of the simple stuff that Nokia will release as closed source right away.

It's funny, heh. On Maemo, I have the freedom to replace any file but the many files I would like to replace are closed source Nokia components. On Android, it's possible for somebody to actually modify many things (like the Phone UI, but not programs relating to Google's services - same as Nokia, all Ovi stuff is closed understandably), but not have the freedom by default to be able to SFTP in and replace the file.

A other misstep is in my opinion the removement of features and functions in the firmware updates without asking the community before and after this without explanation why it was removed or the willing to reimplement it.

Example:
https://bugs.maemo.org/show_bug.cgi?id=10318 (marked as enhancement while it was there before in PR1.1 - hence definitively a bug from users view)

https://bugs.maemo.org/show_bug.cgi?id=10332 (marked as WONTFIX, finale statement, without explanation, excuse or a sourcecode to reimplement it ourselves)

As if it is sad enought to wait for the next major update (we have still no hotfixes) to get back what we had and bought. There is not even a timescale!

Nobody said it was easy At the same time, it can require *more* QA manpower to test the hundreds of changes that can build up over several months of development, with an increased chance of regressions. Different methodologies of development and release - basically, Waterfall vs Agile - each having their pros and cons. I'm happy to take this conversation into a different thread or by PM to leave this one on topic