The Maemo Community Council elections - Why you should care

The maemo.org community is something of a rare bird in the mobile environment - a self-organizing community centered around Nokia's tablet line, with a very strong infrastructure and unique spot where users, developers and hackers come together resulting in a lot of synergy and powerful base compared to the niche aspect of Maemo. One of the most peculiar aspects of it is the Community Council, a representative body that deals with all things Maemo. What it can do, why should you care and, most importantly, why should you vote *TODAY* if you are a community member with enough karma ? Read on to find out ! I also hope this to shed a little light and be a short introduction of the inner workings of maemo.org to people NOT familiar with the intricate community workings of maemo.org . 

The Community Council was formed two years ago as a representative body, with a role to "represent the Maemo community's best interests to Nokia, and to act as a community conduit for Nokia-generated information." This role has recently been expanded, as Nokia has transferred control of maemo.org to the community (=the Council as a representative body). This gives it a fairly complete control over all things that happen in maemo.org, a lot of which many users are not even aware of:

• the rules that define criteria for software in extras and related repositories
• determining forum policies
• overseeing collection of documentation/wikis/howtos
• ability to issue tasks to maemo.org staff (you DO care if the forums or Extras breaks down or is difficult to use, right ?)
• disseminate important information through the Council blog
• help coordinate community events (Summits/Conferences/meetups)
• help with grassroots efforts (competitions, hackfests, anything Maemo)
• formalize concerns and issues and pass them to Nokia
• define goals/strategies for the future of maemo.org
• really, anything maemo.org related
• in fact, anything community related goes - it it's cool, support it !

So yes - if you would like more of the things above, or you have a peeve you'd like changed - the Council is the body whose attention you need. Generally - if you have an idea relating to Maemo, and you don't know who to turn to, the council is the address (with a notable exception - the Council is not Nokia Care, Nokia has proper customer care channels, the Council focuses on community aspects).

Even with fairly complete control over the maemo.org realm, I cannot emphasize enough the facilitation character of the Council when it comes to Nokia. Nokia does not obey the Council - but certainly does listen to it as it represents the most vibrant and passionate base of it's users.

I've listed a short (far from complete !) list of what the Council can do - but there are things, often sources for confusion, of what it CANNOT do. Can the Council guarantee that a particular firmware will be made available to your device ? No - it's not a community call. Can the Council force Nokia to include/exclude components from firmwares ? No - it's not a community call. 

Some of you Maemo device owners will stop (or already stopped with tldr ;) ) reading as they don't really care about this maemo.org stuff (something I doubt, as Extras, a central part of it, is the main source of applications).

However, if even if all this community-talk jibberish means nothing to you and and you define the bottom line as Apps Apps and Apps (with Flash), you should pay attention. The Community Council is in the unique position to make a strategy for the future of the community. It *does* direct the work of maemo.org people and will be pivotal in determining for example what software will be available from MeeGo repositories, or just how difficult it will be for MeeGo/Harmattan developers to support the Extras repository. They can (and IMO should !) also be the voice of the Maemo community inside MeeGo - MeeGo doesn't have a council, and if you have an itch, it won't get resolved unless you or your representatives do it.

All this brings us to the bottom line - in my opinion, the Council matters, but only to the extent of the abilities of people in there. In a worst case scenario, the people you elect to it do nothing - that's the same as if it didn't exist. However, YOU, the community member have the power to elect people who ARE capable of affecting the future of maemo.org and all the people and device it touches on, be that apps, events or other. Today is the last day of the community elections for the next term, so if you care the tinyest bit about Maemo, MeeGo, maemo.org or your Maemo device - use that voting token and make a difference.

Flash versioning gone wrong, or, should the abusers be abused ?

A painful fact is that Flash 10.1 is not currently available for the Nokia N900 (well, at least painful for N900 owners). If we look at the bigger picture, applications (like my version-forging TweakFlashVer) uncover a few non-N900 specific problems with the way things are done in Flash land.

TweakFlashVer is an awful hack - it just makes the Flash plugin report a faked version string (much like browsers in the old times forged their agent strings). Seasoned Flash developers are naturally very displeased with such an approach, as the plugin itself does not gain any additional functionality or acceleration, it's still the same Flash it was prior to the intervention. I can hear you ask - well, what good is it, then ?

And here is the problem - cludgy as it is, it DOES work, as seen on the N900, Facebook videos work again and many sites came back to life. How is that possible ? Sadly, often the real requirements of the content presented by Flash do NOT match the requested version in the loader/web page. But why do people declare wrong versions and make lives of their own users miserable ? Because Flash is doing it wrong in the first place, and then it gets abused by webmasters and flash devs further (making TweakFlashVer an abuse of an abuse). What are the reasons for this abuse in the first place ?

• Using version detection as an upgrade mechanism. The assumption is that if someone does not have the latest version, it is simply because they simply have never been nudged into upgrading it. The developers doing this think they are making users a favor since they will be upgrading to a version which is faster, safe, but are forgetting that different platforms have different upgrade cycles, and that latest version might not be available just yet.
• Using the wrong loader. This can be caused by copy-pasting flash loader code from other projects or on-line tutorials, without matching the version requirements in the loader with the actual content. In other words - plain sloppiness.

Both of these, however, only go to show that Flash is doing it wrong in the first place, for the following reasons

• The queries should be for *features*, not versions. This important as we will be seeing Flash players with different preferred feature sets. For example, a platform with hardware video acceleration might prefer a different codec to a platform that has no such thing (currently this role is done - again, in a wrong way - by checking for Flash Lite). Not to mention the pipe dream that one day Flash becomes a real Open industry standard with multiple content player plugins, which would obviously have different, partially overlapping feature sets.
• The version requirement should not be a statically coded thing in HTML that is unrelated to the actual content. If there is (any) Flash version available,  the versioning requirement/handshake should be done *inside* Flash.
• If possible, the server should present multiple versions. Sure, Flash 10 has new features, but there is no fallback, meaning there is no systematic way of saying 'hey, give me a Flash 9 version of that content'. As it is now, the server acts as a bouncer, asks 'whatcha got' and the client says 'errr.. 9.0.260 ?' and then the server just says "you're too old for this" and slams the door.

The question in the end thus remains. There is no doubt TweakFlashVer is a super-hacky solution to frankenstein Flash in order to allow users to access the content they want, but the Flash powers that be will have to come up with two solutions before this approach becomes widespread and turns from a hack into a modus operandi of abandoned Flash platforms, like Maemo 5 and 64-bit Linux:

• A system that can address the sloppiness of it's users and their (mis)use of HTML loaders
• Change the upgrade-upgrade-upgrade mantra. Sooner or later the range of devices that will (try to) run Flash will get so wide that a version number will not guarantee anything, and the Open Screen Project changed nothing in that aspect - users of particular platform are still at the mercy of Adobe and/or their vendor if they will get Flash player in a firmware without any guarantee that a sloppy coder won't render their device obsolete in a couple of months.

Much Ado(be) over noth(tml5)ing ?

By now the Apple - Adobe war is in full swing and the the sides in this conflict are stating that they hold the key to the technologies for the ultimate user experience. But let us just take a peek behind the big words and statements and see what exactly is on offer here.

First, let's set up the initial positions - with the processor power and resolution of mobile devices increasing at a breakneck pace, a rich web experience has become very important to companies wanting to sell the latest & greatest gadgets. Apple has clearly pledged itself to supporting HTML5 for the rich user experience on it's platform, while Adobe (obviously) claims that 'full Flash', on mobile devices is the answer to that problem. The important thing to notice here is that both technologies are in essence desktop technologies that are expended to fit the use-case of mobile devices.

So far, most of the Apple vs Adobe dispute has been on the level of announcements, open letters, endless speculation on gadget forums, but now, the first tangibles are showing up. For a long time, full Flash (at least for 9.x) was an exclusive for Maemo devices, but with the Open Screen Project Adobe promised to bring Flash to the masses, primarily to Android, whom Adobe sees as the prime opponent to the iPhone platform. It sounds a bit like a rebound affair, as Adobe tried really hard staying within Apple's walled garden, but in the end, it became clear that it was not welcome (whether the end of the affair was more to technical or business reasons, I leave up to you to decide on).

What happened happened, Android is the newfound love for Flash, even overtaking the ultimate-flash-experience incumbent, Maemo, and promised to be included with FroYo, aka Android 2.2, with some people already testing the beta on the Nexus One. So Android gets Flash 10.1, everything gets peachy and super-hardware-accelerated, right ? Well, as usual with major shifts in technology, it's not that simple. Let's see what EXACTLY is the Flash 10.1 promise on mobile devices and if actually is what you expect from it (don't worry, I'll talk a bit about HTML5 later, too).

First of all, it's important to understand how Flash works. Just having a 10.1 in your version string will not make everything super fast and instant. Yes, Flash 10(.1) brings a plethora of generic improvements, but 'AS engine improvements' and similar just don't sound as good as 'hardware accelerated'. Does it matter, if we're getting both anyway, you ask ? Well it does, as there might be a whole lot less hardware acceleration than you think. Mobile devices are far more diverse, and peope take a lot for granted when coming from desktop environments, especially when it comes to drivers.

Phones and drivers ? What is this guy talking about ? Well, if you take a look at what the Adobe beta test page, you'll notice that there are minimum hardware requirements, software requirements, etc. I can already hear - but my device is getting FroYo, so why should I care ? Think about it this way - does the fact that your computer is getting a new OS automatically mean all the new cool games will run on it, too (and well, while we are at it) ? To take things into further perspective, notice that even the FroYo beta does not have all that hardware accel snazz - a very notable point is for example is that it does not yet have hardware enabled h264. Sure, you say, but it will come with the stable release, right ? Certainly, but are you sure that your hardware actually supports hardware functionality required for it ? Flash will fall back to the trusty software decoder (just as it does now), but the important lesson here is that Flash (like HTML5 for that matter) can only leverage hardware functionality already present. Even having h264 support on the chip or chipset manufacturer does not guarantee hardware acceleration as such hardware requires the proper drivers and middleware, and, more importantly, that the content is encoded in a profile and resolution that is supported. Before you rush off to dig in some hardware spec chart, let me say that 'most' chips support 'most' popular codecs, but that the landscape is nowhere as nearly uniform as in the X86 world - ARM chips get customized quite a bit by the actual manufacturer, so saying 'Cortex A8' does not give you anything, you have to be more specific than that. This is especially true with HD content, which is practically unmanageable without dedicated hardware support (the real question as to why you would want to play back high-end HD apart from maybe as a video out to a TV or projector is a different matter altogether).

Let us return to the story about Flash though. The already mentioned requirements page tells us about interesting things - like minimum processor speed for a given screen resolution, or operating system. For example, it says that a minimum for VGA (640x480) displays is a 550 MHz Cortex A8 (up from last year’s ARM11 requirement), and for a 800x480 resolution, an 800MHz variant is required. Surprise, surprise ! The first resolution/processor combination covers very few devices (sounds very much like the Palm Pre, but PalmOS is not on the supported list, so who knows) ? The second group is, however, more interesting. WVGA (800x480) Cortex A8 based devices ? Well, we have plenty of those by now, but curiously quite a lot of them fall just a little bit short of the requirements. For example, the Motorola Droid/Milestone only clocks it's OMAP3 to 600MHz, and the Nokia N900, another OMAP3 600MHz device misses out on the supported OS list altogether even in it’s MeeGo incarnation (even though Maemo, MeeGo’s predecessor was THE platform to go to if you needed full flash in your pocket). At this point, the notion is that all devices that Flash 10 has been demonstrated on last year are rumoured NOT get it (HTC Hero, the Nokia N900, etc). The real question thus becomes, how rigid and/or selective these requirements will be. The Droid has been promised FroYo but it's unclear whether it will NOT include Flash 10.1. What ?

This brings us to the next point - why said Flash HAS to be part of any Android build starting with 2.2 ? Supports and contains are neighbouring but vastly different terms. Will the official 2.2 Droid build it perhaps include a custom build or good ole Flash Lite instead ? Or will there a special exception be made ? Will it be available only on a hacked ROM (Milestone needs not apply) ? As you can see, Flash and it's performance is not exactly a given on any platform. Another example for this from the requirements table is the mention of Symbian S60. If you think this means your good ole S60 Nokia will suddenly get a new life, you might be expecting too much. How many Cortex A8 VGA (or, rather nHD) touting S60 phones do you know about ? Nokia doesn't make any and even with Samsung and other manufacturers included, the list of devices is real short and mostly obscure. Which brings us to the - yes, you guessed it - next point.

One of the key difference the Open Screen Project, and the latest Flash releases within it tried to address is the problem of fragmentation. A million versions of flash were a pain to upgrade, especially with the diverse hardware base mobile devices give. So one of the ideas was to be able to make Flash updatable so the content and support would not get bogged down by supporting everything they have release in the past 5 years. Cool, but there is a catch - first, who will provide the initial update to the new flash platform which will then be able to update itself ? Correct, you will have to receive it via a firmware upgrade, and considering Flash 10.1 is for most platforms still months away, until it gets released, then productized and finally pushed to end users, it will be a huge commitment for manufacturers of then-legacy devices, and I not at all sure how many of them will actually commit to it. Second - the story does not end with your device and Adobe. How will your manufacturer deal with out-of-order updates to core software ? The provider you are using can also say a word or two and/or prevent the upgrade (will the upgrade checks be filtered ? Will they cost money ? Will they ultimately require a 'go ahead' ?). A lot of uncertainty there, too.

You might be thinking I'm writing all this for pitching HTML5 and saying how it will solve all these problems - well, it won't. In fact, it will have to face exactly the same problems (just having a video tag and a HTML5 compliant browser alone sure won't make your video accelerated, ditto for fancy canvas operations). Another issue is the famous codec question (whether h264 is really free and set to be a real standard). In many ways, that reminds me of the GIF/PNG feud (for those not familiar with the matter, GIF was the widespread, but patent encumbered format, while PNG was the Free, but with limited support from major players of the time - namely Internet Explorer). Having a standard is one thing, having a standard that everybody supports and does that in a reasonable way is entirely different. On top of this, those who dissmiss Adobe often neglect that the time until HTML5 matures (which will certainly take a a year-or-two-or-three) will not be met idly - Adobe will be wanting to provide added value to the web more than ever and they will certainly be looking to find things not covered by or inherently problematic under HTML5 - we are now just at a point where the small hops of Flash and the giant jump of HTML5 happen to be in a fairly similar area.

All in all - don't worry about what device you choose, as there are no guarantees about anything at this point it's almost impossible to tell what exactly will you get with *proper* Flash 10.1 or HTML5, and whether either will be included in the ever-awaited next firmware update, or how the web itself will use and embrace these technologies - both will be staying with us for a long time, and actual ’unavailability’ will be determined by the technologies and version requirements of specific sites, not the devices themselves.

Operation Qt Shuffle

I know you all like (cough) my long winded and analytical articles, but we'll take a short break from that to allow for a service announcement concerning our busy Qt developers, Maemo 5 and your evergreen favourite update, PR1.2. 

If you're an end user, the short version is - the doors are open for more (and prettier) apps, plus we have a bridge that will make it easy to backport MeeGo apps to Maemo 5. If you're a developer and/or are interested in the gritty details, read on:

[Maemo community council hat]

One of the big changes PR1.2 brought us is official Qt support in the form of Q4.6 in the Nokia SDK and repositories. This change affects all applications depending on Qt currently in extras-devel. We had some talks with Qt/Nokia folks about Qt-related repository changes in Maemo 5 (triggered by aforementioned PR1.2 and potentially again later on by updates to Qt or related components). Here is the short summary:

1. remove qt4-maemo5 (4.6) after PR1.2
2. upload Qt 4.7 snapshots as qt4-experimental to extras-devel afterwards
3. as soon as 4.6 QtMobility is released, get those packages to the nokia-apps repository
4. remove 4.6 QtMobility from extras-devel
5. maybe upload new QtMobility packages to extras-devel, but only for qt4-experimental (4.7) and with 'experimental' in the package name
6. maintainers of bindings and extensions to Qt are encouraged to follow the same nomenclature in their package names (i.e. using experimental in the name if depending on qt4-experimental)
7. use a Provides/Replaces/etc libqt4-maemo5 clause in the qt4-experimental packages (Qt4.7 packages should be binary compatible with the current 4.6 ones) so the packages can be deprecated peacefully
8. QML/declarative will be released as part of Qt4.7 (so qt4-experimental only, no 4.6.2/PR1.2 support)

[/Maemo community council hat]

What does this mean in plain English ? The libqt4-maemo5-* package names are deprecated in extras-devel. Use libqt4-experimental-* if you need Qt4.7 features, or libqt4-* if you want Qt4.6. Qt4.5 will no longer be supported after the release of PR1.2

Have a nice day !

 

Busy week in Nokia land

The following week is shaping up to be a very busy one for Nokia. Starting today, there is a (largish) scheduled maintenance in the Ovi Store, nearly two days for publishers and most of Monday for end-users. There were hints of some major spring Ovi improvements in the past months, let's hope this maintenance introduces at least some of the new & improved functions.

The second (even bigger) event will be the first MeeGo code drop (a technical preview release for developers), also known as "Day One", which is scheduled for Wednesday (search for March 31), and also a TSG meeting later that day.

Last, but not least, while not really announced, the Nokia N900 PR1.2 firmware release, probably the most important one so far (as it brings all-important official Qt4.6 compatibility) could easily happen this week. The early access PR1.2 SDK has been released a week ago, and the autobuilders on maemo.org have already been transitioned to PR1.2, so the firmware itself can't be far.

The MeeGo release is certainly the most important of all these events, so prep your hacking skills, you're going to be able to put them to good use in just a few days !

EDIT: As pointed out below, this week will also see the election of the Maemo Community Council, which while not strictly a Nokia activity, still plays an important role in the Maemo world. If you are a Maemo community member and have received a voting token, take a gander at the candidate list and their programs and make sure the candidates who you think are best take the seats!

Harmattan: Last of the Maemos or First of the MeeGos ?

It has been over a month now that MeeGo, Nokia's and Intel's joint mobile linux effort has been announced. The original formula was for Maemo 6 (also known as Harmattan) and Moblin 2.2 to merge, and form a Maemo 1.0 in the next iteration. This was cool and was generally well accepted (except for a few not too well communicated points like switching from Maemo's DEB to Moblin's RPM). Let's delve into the branding/community aspect of Harmattan, the upcoming protoMeego!

The Maemo 6 device is not even out yet, only announced for the second half of 2010. So, how does one prevent the Osborne effect? Well, the immediate, and understandable reaction was dropping the Maemo 6 brand for Harmattan. This seemed a bit of a middle ground, but it is evident that most people have never heard about Harmattan and will have trouble placing it in the correct position with regard to Maemo and MeeGo, so later  a MeeGo / Harmattan name started appearing. In interviews and blogs, even top Nokia folks regarded Harmattan as MeeGo compatible, or an instance of MeeGo. In theory, if a device implements the MeeGo API, it is MeeGo device, if it doesn't, well, then it isn't. What does this mean in practice? Hard to tell, unfortunately. The first problem is that the MeeGo API itself has not yet been publicly released, only outlined in a very rough architectural sketch. Furthermore, as discussed in my previous article, this Harmattan / MeeGo is not the MeeGo the N900 users (think they) will be getting. Many of you will say, why does it matter? If the SDK helps overcoming the RPM/DEB divide, isn't it pointless to point out "differences is obscure middleware components"? Well, sadly, the question is a lot more complex than that.

Arguably one of the biggest differentiators and unique aspects of the Maemo platfom is/was the well organized community at maemo.org. Many of you unfamiliar with the inner workings might think it's just a forum or a download portal of some sort, but in reality, it's almost a country of it's own. It encompasses several communication media, from forums through blogs to mailing lists, documentation and the complete community development and distribution process (which accounts for 95% of available software for Maemo devices). Another way this little country is unique is that is has elected representatives, and encompasses all sorts of users, from casual surfers through power users to hardcore developers - something very few communities of this size manage to do. This makes maemo.org and everything it stands for an invaluable asset of the Maemo platform. What does this mean with regard to Harmattan?

I hope the problem is starting to become apparent - by pushing Harmattan users into the meego.com fold, they will miss out the experience and momentum maemo.org has. At the same time, there will be a realization that the only thing in common with their Intel, LG, etc 'neighbours' at meego.com is the name itself - they will be using a different package format, different repositories, different DRM, different architecture, different (but similar) APIs, different application store and IMO it won't be long before it will be perceived as a MeeGo stepchild and the Harmattan section will be littered with 'when will the Harmattan device get a real MeeGo?' or 'why does everything have to work differently on Harmattan?' threads.

Okay, I hear you say, then they just integrate it with maemo.org and let it live through it's protoMeeGo days along with it's N8x0 and N900 predecessors until it really gets to be MeeGo 1.0. Unfortunately, that's not a decision without drawbacks, either. Right off the bat, there is the marketing problem of this making saying it somehow 'old', obsolete. In reality, it's not Harmattan that is obsolete, I feel that it was the MeeGo announcement that was in many ways premature as it is really something that affects the 2011 time frame of devices, anything before that will be MeeGo in name, not essence. And this brings us to the second problem of this approach - if the community coming with the Harmattan device is part of the Maemo community, there will be no substantial (read: one including end-users) Nokia device community present on meego.com until well into 2011 and the first 'designed for MeeGo' devices.

What's the solution, then? Harmattan is in a tough spot, Nokia aiming for high and noble long term goals, but that does not ease necessary near-term choices (especially considering they already made the most important one - going forward with Harmattan as planned regardless of MeeGo). I already talked about the branding problems - this is something only Nokia can decide on. On the platform side, I feel the maemo.org community can help, but solid bridges need to be built between maemo.org and meego.com, to allow for users to harness present-day community resources and experience, at the same time allowing them to grow/migrate into meego.com when the time is right. Trying to push them into a future meego.com infrastructure now could easily hurt Harmattan (and indirectly Nokia's own long term MeeGo) efforts.

DISCLAIMER: A lot of things about MeeGo are in flux, things becoming more clear when the first Harmattan and MeeGo SDKs are released (this should happen in just a few weeks).  I'm pretty certain there will be updates based on those coming for my little analysis above, so let's see what the future (and various MeeGo stakeholders) hold !

The danger of weak branding or: which MeeGo is the real MeeGo?

By following various blogs and forums, it occured to me there is quite a confusion as to what actually MeeGo is. The basic idea, announced in Barcelona during the MWC, was to have Maemo and Moblin merged into a new OS called MeeGo. So far so good (number of MeeGos: 1). However, recently Nokia re-branded Maemo 6 as MeeGo / Harmattan, which uses a different package format, repositories, so not quite the same MeeGo that was originally announced, despite the general similarity (number of MeeGos: 2). In the same vein, Moblin folks started calling Moblin 2.2 simply MeeGo (number of MeeGos: 3). But wait, the plot thickens! It has recently been confirmed that the N900 will be Nokia's reference platform for ARM-based MeeGo devices. Now, this is closest to the MWC MeeGo, but is just a developer reference platform, not something that end users are expected to install/use (number of MeeGoos: 4). Getting dizzy? Take a look at meego.com, you'll see that MeeGo also intends to provide separate versions (as in different user experience) of  MeeGo not just for Pocketables. There will be distinct editions for Netbooks, Media Phones, TVs, In-vehicle devices and, as you probably guessed it by now, they're all called MeeGo (number of MeeGoos: 5, 6, 7, 8). So the next time somebody asks for or talks about MeeGo, make sure it is clear what the object of the talk is, lest the discussion turn into Marklar.

This problem has been usually tackled by subbranding, for example Ubuntu very successfully uses names like KUbuntu, XUbuntu, Edubuntu, Ubuntu Netbook Remix, etc. Why is this so important you ask? MeeGo targets a very wide range of devices and users, far more diverse than Ubuntu. By allowing everything to be called MeeGo, despite having different UIs, architectures, application stores, DRMs, APIs, packaging systems and repositories, MeeGo becomes a weak brand. It will no longer be important whether something is MeeGo as it provides no guarantee of anything except for a generic Qt based compatibility (which means little to end-users). It's crucial this branding mess gets cleared up by the powers that be before the first releases are made and the first devices hit the streets, otherwise MeeGo (all 8 of them if I counted correctly) risks going from a strong distribution brand for the embedded industry to being just a generic synonym for 'Linux with Qt'.