A month ago the MeeGo wiki informed us about the critical Core OS Program/Kernel policy changes that were approved in the December 15, 2010 Technical Steering Group Meeting. The importance of these changes was actually left unoticed but there are many hints about how the MeeGo ecosystem really works and essentially what we should expect in the future from MeeGo and all the companies behind it. Phorepoc is going to highlight all these hard facts that went unoticed.

At first we should examine how the MeeGo ecosystem was working before the changes:

Before MeeGo we had Maemo and Moblin. Maemo was Nokias Linux distribution for tablet devices so Nokia had full control of the OS progression and the changes that were meant to be made. Moblin (short for Mobile Linux) on the other hand was only driven by Intel on its first incarnation and later was turned over to the Linux Foundation. This way the standarisation of Moblin was guaranteed!

A year ago (February 2010) Maemo and Moblin merged into MeeGo and so control was tottaly on Linux Foundation's hands. For most people this marked the end of Maemo and Nokia's support for the OS and all the devices powered by it but things are actually more complicated and are demonstrated on the policy change we've seen a month ago. Maemo and Moblin were different in many things. Maemo was a Debian derivative while Moblin was Fedora based. That made them have 2 totally diferent distribution models and repositories but in the end, MeeGo used the Redhat package manager just like Moblin. Despite that, manufacturers can follow their own alternative way.

One such example is Sabayon. Sabayon is a Gentoo derivative, a meta-distribution which has portage and alternatively you can use the unsupported paludis. But Sabayon, other than Gentoo's official package manager, also has its own binary package manager, Entropy.

In practise, Nokia could use the Debian based Maemo package manager but that is not true. The kernel and Core OS policy made it clear that any changes made to the OS by any company must be submited for approval to be included in newer versions of MeeGo. This could mean that the Linux Foundation might not accept changes about either the Linux kernel patches or core features of the OS and so companies might heading in a dead end when developing the OS. For most people that meant the death of Maemo as we knew it. We all thought that Nokia will follow the same paradigm used by Intel and all future hardware vendors of MeeGo. But there was a problem on that policy and that problem was getting bigger and bigger with more companies like AMD, Novell, WeTab supporting MeeGo and submiting changes to it's kernel.

The Linux Foundation just couldn't manage all the changes submited. There were plenty kernel patches conflicting each other making the whole project even worse to manage. So the decision was clear. Move all the obligations to hardware vendors and keep as close as it is possible to the upstream kernel.

Taken from the official anouncement the new policy sais:

[div3 class="quote" class2="quote-l" class3="quote-r"] [dropcap cap="1"]MeeGo will ship with one 'reference kernel', that will have one shared codebase between all the devices it supports (with different configuration files). This kernel will be close to the upstream kernel with very few patches applied to it, and the version will be chosen by the architecture team such that the kernel is relatively recent, while still allowing for a reasonable stabilization period before a MeeGo release ships.[/dropcap] [dropcap cap="2"]For a platform to be part of this `reference kernel', the supporting adaptation code (drivers/etc) needs to already be in the upstream kernel for the version that the reference kernel uses. It's assumed that such a platform will only need a low number of small patches to fix the occasional bug.[/dropcap] [dropcap cap="3"]For platforms that cannot or do not want to use the reference kernel, a separate RPM package will be created in one of the MeeGo OBS instances. This package will be named kernel-adaptation-(platform name) to clearly mark it as separate from the reference kernel. The hardware vendor/platform enabling team for the platform will have complete ownership and responsibility for this separate kernel (adaptation kernel) package. Any team wishing to do this must identify at least one real maintainer and keep the list of active maintainers current for the duration of the required lifecycle.[/dropcap] [dropcap cap="4"]Having a separate "adaptation kernel" does not absolve the kernel owner from the requirement that all the code must go into the upstream kernel in a reasonable timeframe[/dropcap] [dropcap cap="5"]To protect the reputation of MeeGo, the owner of the adaptation kernel must ensure that security issues get fixed for the life time that the adaptation kernel is in use/supported (a minimum of 12 months after the MeeGo release)[/dropcap] [dropcap cap="6"]The adaption kernels must follow the same release process/timing as the rest of MeeGo; e.g. the same feature freeze, code complete dates etc etc.[/dropcap] [dropcap cap="7"]For MeeGo compliance and consistency, maintainers of "adaptation kernels" are required to backport any and all relevant userspace visible kernel features from the reference kernel so that applications and middleware that runs on the reference kernel can assume reasonable feature and functionality parity.[/dropcap] [dropcap cap="8"]The MeeGo compliance profile will have a set of kernel configuration options that are required to be set, in order to provide a consistent ABI and consistent functionality to the application stack.[/dropcap][/div3]

In order to understand that decision we will see Nokia's and Novell's cases On the following diagram:

With the new policy, MeeGo's kernel is really closer to the vanilla Linux kernel. The purpose of it is to have a clean code base with the least amount of patches for stability and portabily reasons. There will be different configuration files for each platform (in our example ARM and x86) that will share the same code. Companies will have more freedom in evolving the code but also more responsibilities as they will have to maintain all the changes that are not uploaded into MeeGo's reference kernel by the Foundation. They will know from the begining that any changes that they are making will have to be maintained by themselves so any changes will be more carefull to comply with the standards of the MeeGo Core and Kernel.

Nokia can now keep on evolving Maemo as her own MeeGo derivative. This new derivative has already a name and it's called MeeGo/Harmattan. It will use the standard MeeGo linux kernel with all the updates and patches from Maemo that couldn't fit into MeeGo, like a different UI and UX similar to that of Maemo 5 and maybe a secondary package manager based on debian for keeping support for the old Maemo community. The same freedom can be seen from other non-hardware companies like Novell which they can bring more compatibility between their desktop sollutions and their MeeGo adaptations. Each company will be able to easily share any non-standard code including patches and unapproved applications with each other through third party repositories so the MeeGo ecosystem can evolve beyond Foundation's control!

It's clear that the MeeGo is heading into becoming a true open Linux distribution, (the exact oposite of what Android is), and bring freedom not only to users but also developers and hardware vendors. The policy change could be seen as a bad sign that will lead into further fragmentation, but with the standarisation of development arround Qt and the already high hardware requirements from the current MeeGo versions we strongly believe that we will hardly see the same ammount of fragmentation seen on Android or even Symbian

The policy change also shows some other things about good management of Operating Systems. We have seen Symbian moving to Nokia from the Symbian Foundation. It was exactly the opposite with MeeGo. Nokia was the only hardware vendor supporting Symbian so the Symbian's Foundation became a bureaucratic obstacle in the OS evolution. On MeeGo on the other hand hardware vendors and in general supporters of the OS are increasing as time passes so a more open system that will only be strict on standarasing the basics is really needed to show the way, and that's what this new kernel policy brings