Last time I wrote (rather lengthily) about the N900’s hardware. But a smartphone’s hardware is only half the story. And as a software developer, I am naturally more inclined to be interested in the software. So here’s the second part of my N900 postmortem (sorry it took so long).
Image may be NSFW.
Clik here to view.
The Maemo 5 Operating System
The N900 hardware isn’t anything special when compared with other smartphones of the same form factor (that is, full QWERTY slider). What sets it apart from the rest is the software that it runs: the Maemo 5 operating system. Maemo gives the N900 a unique character, in both good and bad ways. But first a short walk down memory lane. Maemo 5, as the number implies, is not the first version of the OS that came from Nokia. The N900 itself is a product of an iteration of a line of devices that started with the Nokia 770 (no, not “N770”), Nokia’s first “Internet Tablet” in 2005, followed by the N800 and the N810 (and N810W). What these older siblings of the N900 have in common is that none of them are phones. They are Linux-powered pocket computers intended for mobile Internet use, as the name of the series suggests. Internet connection is primarily through Wi-Fi, though I’m not certain if tethering over Bluetooth is possible. This is the identity that the N900 inherited, with some additional features. If I were to describe the N900 in a single sentence, I would say something like this:
The N900 is a Linux-powered mini/pocket computer with telephony capabilities.
Why do I find this statement important? In my opinion, this sentence explains the uniqueness, power, quirks and warts of the N900.
Linux (Desktop) in my pocket
As a Linux geek (and yes, I admit it), this probably the most significant feature of the Maemo OS for me. This is not to say that there have not been other Linux-based devices or even Linux-based phones in the past, but, as far as I know, this is the first time that one has been intentionally targeted at the mass market (so that sadly excludes OpenMoko-based devices). Some will definitely argue that Android is also Linux-based and is also mass marketed, and they are right. However, Maemo has one significant difference: From the Linux kernel right up to the user interface, the Maemo software stack is almost the same stack that you have on your regular Linux desktop. Well, almost. There are some differences, of course, that have to be made because of the different architecture (ARM) or device constraints. I think the implications of this is quiet huge. For software developers, everything they’re familiar with is already there: the kernel, D-Bus, OpenGL ES, X11, GTK+, Qt, and more. Also as a side effect, some libraries are easily portable or are already there, like SDL. Even the choice of languages i not limited: native C or C++, Python, Perl, Ruby, or even Java. For the end user, this also means that some of their favorite or familiar apps are also available on Maemo: Evince, Xournal, Pidgin, X-Chat, and even game engines such as ScummVM, just to name a few. There have even been a sort of minimal kdelibs port used by FreOffice, a Nokia-sponsored document viewer based on the KOffice libraries. Why did Nokia and the Maemo team choose this path? Probably to take advantage of existing mindshare and knowledge base. Aside from taking into account the difference in form factor and input methods or special Maemo-specific API, existing developers didn’t need to learn a new language or new platform to write apps for Maemo. Linux users also didn’t need to say goodbye to their old apps in order to use the N900. This is all fine and dandy on paper and would have been great if executed properly. Unfortunately, as I will mention a few times later, this also probably became one of Maemo’s biggest defects.
A Hildonic Experience
But first, perhaps a detour into the exciting (to me) area of user interfaces. I didn’t actually get to experience developing anything that directly touched or used the user interface-specific API, preferring to let Qt handle that, so I will mostly be describing an end-user perspective. While Maemo stack is similar to a regular Linux desktop, the graphical user interface definitely has to be different considering the smaller form factor and (primarily) touchscreen-based input method compared to a regular desktop or laptop. And so Hildon was born. Hildon is an application framework that delivers a set of extensions to GTK+ to provide a finger-friendly interface to Maemo. It also provides a homescreen, a framework for widgets for that homescreen, a notification area, task switching, a control panel, etc. It basically provides a GTK+-based desktop environment for mobile platforms such as Maemo, kind of what GNOME is to regular desktops. The “finger-friendly” aspect is an important improvement of Hildon in Maemo 5, the version used in the N900, over the previous Maemo iterations. While touch-oriented, the previous Nokia Internet Tablets were definitely not finger-friendly. In some instances, a stylus was absolutely necessary to navigate some apps, which was somewhat OK, given the use case for those devices back then. But since the N900 was going to be a phone as well, that had to improve. And in some cases it did. Buttons were larger and easier to hit with a finger. Menus were simplified and no longer looked or behaved like regular multi-level drop-down menus. And in some instances, configuration dialogs were also simplified and made easier to navigate.
Sadly, this was not always the case. And this is where the aforementioned wart of Maemo comes in. As mentioned earlier, being a full Linux desktop stack made it easier to port familiar desktop apps to Maemo. The disadvantage is that, while is some cases the software does adapt the Hildon-specific interface conventions and widgets, in a lot of cases the app looks and behaves exactly like its desktop version. This makes using the app somewhat cumbersome and makes the Maemo experience quite inconsistent. My favorite culprit here is X-Chat. The menu is a multi-level drop-down menu, which is also hard to hit with a finger. The configuration dialog box is loaded wth options all crammed up in a small space. The default chat text is barely readable without squinting. To sum it up: X-Chat wasn’t of course developed with a handheld device and finger navigation in mind and the direct port clearly shows this. Unfortunately, there are other apps like this. The familiarity of a Linux stack may have given the impression to developers that they do not need to take into account the differences in hardware and interface targets.
To Rotate or Not To Rotate
That’s not to say that Maemo itself doesn’t have its own inconsistencies. To me, the most glaring involves the accelerometer-driven auto-rotation in the default apps. Here, I think, it would be good to remember my earlier premise of what the N900 really is: a pocket computer with phone features. Something it inherited from its predecessors, Maemo’s default orientation is exactly that of a pocket computer or tablet: in landscape. Unfortunately, except for a very select few default apps (the Phone app, namely) all the default Maemo 5 applications were stuck in landscape. It was as if Nokia was saying that this is how the device is primarily used and this is how it should only be used. Which is, in my opinion, utter nonsense. I can’t find any logical or practical reason why I should not be able to read my messages or view my contacts in portrait. I am not sure if third-party developers were given access to the rotation API from the beginning, but that is beyond the point. The default apps are the apps that the user will first experience. It makes sense to put your best foot forward in them. Nokia did listen a bit, and in the PR 1.2 update added auto-rotation to the browser app. Later community updates (which I will mention in a while) also added the option to force the rotation of some, not all, apps. But this is only a workaround and not a solution, and an inconsistent one at that. In some apps that do auto-rotate, once text input is required, the screen is forced back to a landscape orientation when it reveals the virtual keyboard (because there is also no portrait virtual keyboard). The experience is very jarring and could have probably been avoided if Maemo went the opposite direction: enable auto-rotation by default and only optionally default an app to landscape mode where it makes sense. Fortunately, at least for some of the insanities in the OS, the Maemo community has bravely stepped up to take the future into their hands.
Open Source Community At Its Best
Image may be NSFW.
Clik here to view.
FOSS fans have probably heard again and again how a piece of software, if open sourced, can be taken up by a community once official support from its corporate or financial sponsor has ceased. While this is true theoretically, in practice, not all open source software survive, especially when the size and complexity requires a dedicated team to maintain it. Except probably for Blender (blender3d.org), I have not yet seen such a success story until the Maemo Community SSU or Seamless Software Updates. SSU is practically another way of saying over-the-air (OTA) updates to the the core Maemo OS. When Nokia made it known that they were no longer going to issue updates and fixes to Maemo 5 (because they have switched their focus to the N9 and its OS, MeeGo Harmattan), the community started working on a way that they could provide those fixes, and some improvements, to the users, not only of Maemo 5, but also Maemo 4 (the OS used in the N800 and N810). Improvements include the forced auto-rotation mentioned earlier, a different rotation animation style (actual rotation instead of the default “flipping” animation), alternate task manager layouts, etc. And of course, continuous bug fixes for core parts of Maemo.
What makes the Maemo CSSU truly impressive for me is the amount of work the community had to go through to deliver these updates. It wasn’t simply a matter of inheriting and maintaining an existing codebase, but also included some negotiation with Nokia and other parties regarding the not-so-open parts of the OS. Nokia should probably also be applauded and thanked for having helped in making the CSSU a reality. This was definitely a huge job, so kudos to the Maemo community.
(A sad note for me, some of the features, notably the rotation animation, blur, and task manager columns no longer work for me, and I have no idea why).
Embarrassment of (App) Riches
Before I get into the app development topic, I’d like to take another detour into what I perceive is the app situation on Maemo. There are two ways to search and get apps on Maemo 5. One is the App Manager, something that is familiar to users of previous Maemo versions, as well as Linux users who have experience with tools like Synaptic or YaST. Since the N900 is the first device in the Maemo line that Nokia was actively marketing, Nokia wanted to also cater to other users who have more experience with something like an app store, so there is also Ovi (now Nokia) Store. If one only looks at the catalog in Ovi Store, one would think that there is a huge lack of apps for the N900. Nothing could be further from the truth. Browsing the app manager, and enabling some repositories, yields hundreds of apps available to the user, some of which, as mentioned earlier, are the ported versions of familiar desktop apps. Unfortunately, this isn’t always a good thing.
The biggest problem to me is the multiplicity/duplication of apps. There are sometimes too many versions or choices for a particular task, and not all of them good. And thanks probably to Nokia’s long process to get into Ovi Store, very few of the good apps get into that store, skewing statistics and perceptions of the Maemo platform. Granted, this is somewhat also a problem in the Android market now, but thanks to other factors (marketing, word of mouth, etc.), the good ones are really able to stand out.
Another problem is the lack of big commercial apps. While there will be endless debates on the “morality” of these proprietary apps on an endless factor, I doubt no one will contest that a mobile platform backed up by big names would have helped increase the interest about the platform. Maemo does have Angry Birds, Documents To Go, and some others, but notably lacking are official apps for Facebook, Twitter, Evernote, and Dropbox . Not to mention some games. What kind of irks me even more about the situation is that the N900 is a very capable device. Case in point: there have been published ways to run graphics-intensive games on the N900 that were released for WebOS.
All this is obviously moot now that Maemo is commercially a dead end. But it still makes one think what could have been.
The Developer Story
Now that the end user aspects are over, I jump to focus on the programming side of things. I must shamefully admit that I have not explored all the possible paths to be taken when developing an app for Maemo. So instead of an in-depth review, this will mostly be a recounting of my experiences in developing Flash Strobe for the N900 (shameless plug, hehe). Maemo practically offers developers the same languages, libraries, and tools available to the Linux desktop. However, the primary languages for application development are C, C++, and Python, all making use of the Hildon framework and by extension, GTK+. While GTK+ is the core upon which Maemo is built, ever since Nokia acquired Trolltech, Qt has caught up quite quickly. Qt nicely saves the developer from having to worry about the platform-specific details in Maemo unless absolutely necessary.
Choosing a language and toolkit is easy, considering mobile platforms usually have a “recommended” set of choices. Choosing the tools to develop with, particularly the development environment, is another beast entirely. One can ultimately use the text editor + compiler route (and in fact, to some extent, this is what it will all come down to), but, especially in mobile app development, an IDE can be a big timesaver. Back then, if I remember correctly, the Qt SDK was still in its infancy, and Qt Creator, the IDE itself, wasn’t particularly easy to setup for Maemo development. In fact, if I am correct, even wth today’s version of the Qt SDK, you are going to be limited if you need to access things beyond what Qt provides, such as headers and libraries that directly control various aspects of the hardware.
And this was exactly the situation I found myself in when developing Flash Strobe. The app is practically a light strobe that makes use of the N900’s dual LED flash. Access to this was not yet available through the QtMobility modules at that time (I don’t know if they are now). Luckily, the interface was exposed through Video4Linux (v4l2) and accessible through a few ioctl() calls. However, it would not be possible to easily compile this from Qt Creator since the necessary calls are not supported on the desktop, for which the IDE is configured. Enter the Maemo SDK and Scratchbox. Scratchbox is basically an environment and set of tools for cross-compiling, primarily for the ARMEL architecture. This is where all compiled Maemo apps end up, because this is where they are also packaged into .deb files for distribution and installation. My experience with .deb packaging back in 2006 wasn’t exactly thrilling (granted I don’t have any RPM packaging experience to date) so something that shielded me from this part of the process would have been nice back then. I’m not sure if things have improved now that the Qt SDK has matured and has a Maemo target already setup. It might be worth revisiting, for old times’ sake.
My point in this little rant of mine is that the development path wasn’t exactly smooth and seamless. For Qt apps, you had to switch to different tools once you went beyond what Qt provided. You would actually have to go out of Qt Creator to perform some of those tasks. It took some time before the Qt SDK would be good enough and provide an all-in-one tool. Hopefully all of this has improved by now. I’d be willing to retract my statements once I’ve tried it out again.
Wrapping Up
To sum things up regarding the software side of the N900:
The Good
- A powerful “full” Linux desktop in a pocket-sized package
- Favorite Linux apps available
- Familiar ground for Linux developers
- Open source, of course
The Bad
- Inconsistent user experience
- Haphazardly ported desktop apps
- Lack of big (commercial) titles on the platform
Like in the hardware part, despite all the warts, I still love Maemo and the N900. I would recommend it to any geek, especially given how hackable it is (it is capable of running Mer and Nitdroid). Would I recommend it to regular smartphone users? Probably not. The absence of popular apps alone is enough to discourage them. The inconsistent UI would probably irk them. But for anyone interested in a decent device for programming and hacking, definitely get this. Maybe until you get your hands on an N950 maybe. :)
Post Postmortem
The hardest part about a postmortem is looking back and seeing what could have been, the potential that was never realized, and the knowledge that it will all never come to pass. As far as Nokia is concerned, the N900, as well as its more commercially successful but equally ill-fated younger brother, the N9, is a finished story. There are still a handful of people working on improving the core of Maemo 5, but who knows until when and up to what they can change. Some developers ad users have moved on, some to MeeGo Harmattan and eventually to Mer. Some have probably even moved to Android. The N900 and Maemo will probably be just some footnote in history, and some might even regard it as an example of Nokia’s failures. But it will always be a part of history that I am proud to have held in my hands.