I wasn't too concerned with a detailed hardware roadmap - but the occasional product leak and knowledge that things aren't dead is a definite pro in stimulating the community.

Myself - I haven't been here in such a long time and there are various reasons for that:

1) life and the PhD took over...

2) I bought into Android...

3) Navman/tech/etc bailed on the long term licence I had and never updated their software...

4) Canola/Carman saw fewer and fewer "ooh that's new and lovely" updates...though I think that's mainly because they have a polished product that needs little update.

5) Netbooks arrived at a cost that became cheaper than the N8x0...

6) And the main one related to the above: I came to the realization that the tiny tablet was more difficult to use for the purposes I (and the community) wanted to use it for and I felt that we "as a community" failed to realise that - it isn't a computer/netbook and development ought to have moved that way:

a) This means Hildon should be "rethought". The Canola team have the right idea. Apps needed big shiny buttons and fluid screen transitions. The awkward stylus needed to be destroyed, menus ought to disappear, etc...

I started thinking - what if my N810 booted straight into a Canola type widget-based frontend. What if developers had an easy method to create the same style GUIs as Canola. In fact - how would the platform change if developers were forced into using a Canola style gui?

b) The platform's benefits are the beautifully high resolution, yet tiny screen and the Linux base.

c) As a result of the above, we need to leverage existing Linux apps but in a way that is transparent to development and usage. It really ought to be "recompile and it works" - and not by releasing an entire rootable distro (though that was lots of fun, thanks Penguinbait ) - and when I say "works"; I mean in the "tablet Canola sense" above.



7) Back in the hey-day, my main concern was the difficulty in setting up the sdk, understanding voodoo magic like setting up DBus entries in the menus, and gaining access to the hardware. It all felt do-able; but it seemed excessively difficult.


8) I was also a little disappointed that we had (what I felt was) a crippled OMAP since I heard buzzwords like OpenGL ES and Jazelle. Little did I know that there were hard limits imposed by design.



I hope this didn't become one of those *****y "ooh this is all wrong" posts. Some of it may be constructive criticism, but I'm writing stream of conciousness at 5AM in the morning so forgive me.



9) Update: Nearly forgot: Some level of community camaraderie and support with setting up successful projects by leveraging talents in each community "sector". The hardware gurus should stick together, the porting gurus should stick together, the GUI and HCI gurus should stick together, the code gurus should stick together, the help-file documentation gurus should stick together, and so on.


Maemo garage entries would require an (almost) compulsory registration of "teams" from each sector in all aspects of development. If a developer was keen to do everything themselves, then he'd have to register himself in each "sector". (Think of it as the end-credits in the film.)


That way, each project participant could be granted recognition and feedback through "ratings" by the community for their talents. Future garage projects would fight over the best of the best; and other gurus within each field could see what's working well and what isn't through the rating system. This may work to up the standards of any and all apps released in garage space. :-)


Programs maintained actively this way would be the only ones to appear on the main repositories.