Erm, his point is, and it's been mentioned before, your appalling grammer.

A question mark "?" is all the punctuation you need at the end of a sentence ...

You can just look at the current state of meego to learn about its openess. Many people are alredy porting it to n900, to n8x0. to various beagleboards, to the google one, to various other dev boards ...

While only time will tell if these projects will have success. But a fact is that there is happening much more in public than happended with maemo5 (which was imho never ported to anything but the beaglebaord and even that stopped working after maemo5 alpha release).

Just get involved if you worry about all this.

I think 'a' instead of 'the' reference device is more suited. There's really no real alternatives to a handset reference device on ARM side that's out right now.

As well as price level will continually drop, making it an ideal developer platform for MeeGo as well.

We're collecting wood for making a bonfire instead of pissing ourselves to keep warm in MeeGo for N900 - the hardware adaptation has to be able to be maintained over a long time.

If you're wondering on what exactly N900 hardware specific has to be maintained:

ARM port will be maintained for a long time in MeeGo. It isn't going away tomorrow.

Besides the ARM port, we then have kickstart files specific to N900. These have very little different from what Aava kickstart has - so very little maintenance there, just adjust some text once in a while.

Then we have the blobs and such. I can't find exactly where, but the main principle is that hardware vendors (TI, Nokia (HW!), Intel) are expected to contribute these things to MeeGo directly. Be it redistributable blobs or open code. When contributing, these companies should keep them maintained as it affects their own customers' ability to build a product using MeeGo for their hardware (not only Nokia as customer).

Currently we have SGX libraries (TI/ImgTec), BT firmware (not sure if it's TI or Broadcom), BME (Nokia).

And then we have the remainder of the hardware adaptation: bits and pieces in Ofono (Things to turn on the modem, not exactly rocket science. As well as our scripts, http://meego.gitorious.org/meego-device-adaptation

Now, it doesn't exactly take a PhD to maintain what is truely N900 specific. It's a really small hardware adaptation when taking away what's shared with other devices.

However, let's say that the blobs were maintained - how many paid man-months remaining do you hope to be done, as a customer, for N900 to be maintained in MeeGo?

.. and how many man-months can the community deliver?

The more we work together on this, the more paid resources exist for the really important things. The more capable you get now, the more able you are to be putting in man-months for N900 hardware adaptation maintenance and keep it working, yourself.

On a sidenote, did you know that we've released a new weekly image on http://tablets-dev.nokia.com/meego-codedrop.php yesterday? And it performs a lot better? Video at http://youtu.be/DO6884Xzj1c

We're also moving quite well ahead in terms of fixing things:

Now we're gettng somewhere. It has been my opinion since the beginning of Mer, that everything should have been bottom up. First get an updated kernel running in Diablo, then replace libc, ..., etc. Dual booting or kexecing was never going to be a bridge for me. It's chroot, or LD_LIBRARY_PATH or nothing. I know you're leaving Maemo completely behind, but if you were to build one kernel that runs well in both Maemo 5 and MeeGo, they will come.

Don't you understand?

You do not need to follow a question mark or exclamation mark with a full stop/period.

Why do you continue this offence on good grammar practice?

The technical problem is that newer kernels remove interfaces Maemo 5 needs to run properly. And well, Maemo 5 is closed source and it's a wrong attitude to let closed source block kernel upgrades.

And there's also the Netbook, Connected TV and IVI implementations. A lot of work going into MeeGo, as far as I know, none of it closed-source yet.

How about a Maemo 5 diff file?

Let's recap this story from an end user point of view.

On the MeeGo & open source software part:

- When it comes to apps, if they rely on the official MeeGo API (basically Web Runtime & Qt) they should run seamlessly across versions or they could be easily updatable even automatically through the MeeGo community OBS.

- When it comes to the UX, if it's sitting entirely on top of Qt then the evolution path is also clear. Graphics performance might become a problem at some point but there are possible compromises.

- When it comes to the OS & middleware, the bottleneck is the hardware adaptation and its way forward. Your situation will depend on the hardware architecture of your device. In the ARM side http://www.linaro.org/ should be helpful if the project succeeds.

On the vendor & commercial side:

- When it comes to 3rd party apps, the MeeGo SDK and OBS infrastructure should make it easy for them to provide updates even for the "legacy" platforms. Most of these commercial developers rely on number of users using their apps, so probably they have an interest in getting the biggest userbase possible if that brings more revenue.

- When it comes to vendors apps I can only speak on behalf of Nokia, reminding the fair play pact allowing the community to play around in Nokia binaries as long as they stay in Nokia hardware. It's not my job to comment on official Nokia updates and releases of closed components.

- Same goes for UX/OS vendor customizations. The advantage for end users in the MeeGo context is the choice among different vendors. If Vendor X left you unhappy for whatever reason then you can go for Vendor Y or Z and still get most of the MeeGo 3rd party apps and user experience you are familiar with. Hopefully this intra-MeeGo competition will lead to a better base platform and better end products.

It is clear that MeeGo vendors will understand that either this game works well or end user will jump to other platforms.

So we still don't know if we'll have access to Ovi services, which I know is what most end users will be interested in, well, that and continued flash support.

On a semi-related note, I noticed some mapping features in the new Qt Mobility APIs is that any indication on Nokias' future plans to open up Ovi maps a bit more to 3rd party developers and MeeGo?