Carsten, David and Robin, Thank you very much for this proposal and work already done and started. This single post alone convinces me that we have not wasted any work on MeeGo (ce), and that it in fact will have bright future ahead, no matter of the name of the project , the products based on it or possible companies involved in it.
This very clearly is the best part of OSS promise, when one (business) model changes, the projects and the best people continue with the code and their learning of the old model. I sincerely hope that people understand that your Mer project is not against anything or anyone. If companies don't understand the value of your proposal in this "round", for sure they will in next one. Have a happy hacking, and see you around. Br, //Harri -----Original Message----- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Carsten Munk Sent: 3. lokakuuta 2011 9:01 To: meego-dev; meego-comm...@meego.com Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo 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 _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
