We certainly live in challenging times. Maemo / Moblin / MeeGo and Now Tizen. Not everyone is happy with the direction that MeeGo is going in and as such don’t want to blindly follow our leaders. One Answer / Proposal is “Project Mer” which aims at being:
an open, inclusive, meritocratically governed and openly developed distribution, providing a mobile-optimised base distribution for use by device manufacturers.
Initial community reactions are very encouraging from People willing to contribute in whatever capacity they can. Is this the conception of MeeGo 2.0 that we are witnessing ? That is not an easy question to answer for now, but a great one to come back to in the future.
Project-Mer Goals are defined as:
- To be openly developed and governed as a meritocracy
- That the primary customers of the platform are device vendors – not end-users.
- To have a device manufacturer oriented structure, processes and tools: make life easy for them
- To provide a device oriented architecture
- To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
- To innovate in the mobile OS space
Below is the Project-Mer announcement:
Hi all,
MeeGo is dead … long live Tizen !! – Haven’t we heard that before? –
Maemo, Moblin?
We need a community that transcends the mere branding of MeeGo, Maemo,
Moblin – and now Tizen.
A lot of proposals have been put forward:
* Move to Tizen and trust that “They’ll get it right this time”
* Merge or join some existing projects (like the Qt Project, Debian,
openSUSE, etc)
* Keep MeeGo alive by approaching the Linux Foundation
The goal is to find a truly sustainable way for MeeGo and other
interested communities to work with Tizen.
Our solution is the Mer Project:
How does the concept of a truly open and inclusive integration
community for devices sound? After all if “upstream is king” – then
contributions will end up the same place, no matter if it’s Tizen,
Maemo, MeeGo or openSUSE.
Some history – many of us in MeeGo originated from a project called
Mer, short for Maemo Reconstructed – where we approached doing a open
mobile platform through reconstruction of the Maemo platform into a
open platform. We were big on open governance, open development and
open source.
For a few months a group of us have been working on various scenarios
of change in MeeGo [1] and now that the Tizen news is out in the open,
it’s time to talk about what we as a community can make happen next.
To make it clear: this is not in any way an anti-Tizen or anti-Intel
project, but a direction we can and will go in – we strongly want to
collaborate with Tizen and Intel.
We will continue to welcome contribution and participation from the
hacker community – in fact we aim to make it so easy to port to a new
vendor device that a single hacker could do it for their device.
We decided to approach the problems and potential scenarios of change
in MeeGo in the light of the reallocation of resources caused by what
is now known as the Tizen work. There have not been any Trunk/1.3
releases since August and Tablet UX has totally stalled. What really
works (and works quite well) is the Core. It’s time to take the pieces
and use them for reconstruction.
We have some clear goals:
* To be openly developed and openly governed as a meritocracy
* That primary customers of the platform are device vendors – not end-users.
* To provide a device manufacturer oriented structure, processes and
tools: make life easy for them
* To have a device oriented architecture
* To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
* To innovate in the mobile OS space
Now we’d like to talk a bit about what specific initiatives we propose to take:
0) Becoming MeeGo 2.0
Our work has the intended goal of being MeeGo 2.0 – and we hope that
the Linux Foundation will see our work as a worthy succesor within the
MeeGo spirit. We’d like to provide ability to be Tizen compliant, i.e.
supporting HTML5/WAC and the application story there and feed back to
that ecosystem.
1) Modularity. A set of architectural components for making devices.
Rather than dictate the architecture we will support collaboration and
the flexibility to easily access off-the-shelf components for device
projects. Component independence permits focused feature and delivery
management too.
Initially the project will be developing a Core for basing products on
and will split UX and hardware adaptations out into seperate projects
within the community surrounding the Core.
2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for
building products with.
We have already taken MeeGo and cut it into a set of 302 source
packages that can boot into a Qt UI along with standard MeeGo stack
pieces. This work can be seen already at [2] and we’ve made our first
release and have had it booting on devices already[6].
To ease maintenance, we would like to encourage people to participate
in the Core work of the Tizen project, utilizing their work where we
can in Mer: why do the same work twice? Even if Tizen turns out to be
dramatically different, the maintenance load of 302 source packages –
much of it typical Linux software, is significantly lower than that of
the 1400 packages found in MeeGo today.
Using another lesson learned from MeeGo, we also want to port this
work to everywhere, ARMv6/7 – hardfp, softfp, i486, Atom, MIPS, etc –
allowing much more freedom for porting to new devices.
3) Change governance towards a more technically oriented one, similar
to the Yocto Project
We’d like to propose a revamp of governance based upon the Yocto
Project governance – which is much more geared towards open technical
work – encouraging collaboration and discussion. You can look at a
description of this at [3].
4) Work towards better vendor relations and software to support these
as well as easier contribution methods.
As part of our “customer oriented” goal we’re improving delivery
methods from Mer. We are designing simpler and more resilient update
mechanisms to support smaller and more distributed organisations
(think outsourcing too!). We want to encourage easy upstream
contribution and easy following and patching of the MeeGo source tree
– even with local vendor patches.
5) Initial reference vendor – the Community Edition
To make our work focused, the Community Edition handset work[4] will
continue based on the Mer Core. It will act as a model of a reference
vendor [5] and will provide feedback into the project about delivery
methods and problems caused by changes.
We recognise that much needs to be done:
* Hosting and build systems
* Finances & Legal
but these are well understood (if not trivial) problems.
If you’re interested, want to comment or participate – in both
community or commercial contexts – feel free to give feedback to this
mailing list post, or to #mer IRC channel on irc.freenode.net.
[1] http://mer-l-in.blogspot.com/2011/08/restructure-meego-by-installments.html
[2] http://monster.tspre.org:2080/project/packages?project=Mer%3ATrunk%3ABase
, http://monster.tspre.org/~prjfetcher/mer/README.txt ,
http://monster.tspre.org/~prjfetcher/mer/releases/0.20110920.1/kickstarts/
[3] http://www.yoctoproject.org/about/governance
[4] http://wiki.meego.com/ARM/N900
[5] http://mer-l-in.blogspot.com/2011/08/meego-lead-by-example.html
[6] http://www.youtube.com/embed/fouPJRLygNQ?hl
Best regards,
Carsten Munk
David Greaves
Robin Burchell
on behalf of the Mer Project
Is Project Mer for you ?
Thanks to Tim for the Picture.