Re: [Meego-handset] Mer breadth (Was Naming of Community Edition)
2011/10/12 Andrew Flegg : > On Wed, Oct 12, 2011 at 20:55, Carsten Munk wrote: >> >> "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." -- hence the "there's no >> "the" Mer Handset UX". >> >> There's some reasons why this split. [...] > > Thanks makes sense and is well explained. Having said that, I'd be > concerned that a small Core with a few hackers won't be possible to > gain enough momentum to capture a new middle-tier-or-above vendor. Honestly, I think where success lies is with small to medium vendors instead. That's who will have the most strength from this. Of course, the solutions that we intend to provide will be usable for bigger organisations too. > >> 2) We want to move much of the politics out of the Mer project and >> motivate people to create and build their own projects, though basing >> on Mer, much in the same way site projects are based upon Apache >> httpd. - we can't and don't want to govern projects utilizing the >> core, let them innovate on their own terms. > > Apache's an interesting choice of example given there *is* an > overarching "Apache" project and brand under which projects like JCL, > Tomcat, HTTPD, Commons Lang, Commons Collections and so on all > operate. Agreed, perhaps "Linux" would be a better comparison > >> There was a discussion about same topic some days back on IRC and the >> conclusion we reached was: [...] > > It's a little disappointing that so much is happening in realtime on > IRC, preventing those who can't participate 24x7 from contributing. > It's still a massive step-up on private conference calls within MeeGo, > but it is still a barrier to openness when ad-hoc discussions result > in decisions without any pre-prepared agenda. Even post-communication > to the mailing lists would be sufficent. Agreed - we had a hiccup with DNS so that's blocking Mer mailing lists for a little bit. > Well put. But what is the success criteria? My suggestion would be > that a vendor is looking for an ecosystem-in-a-box whilst providing > the differentiation capabilities they feel they need to succeed in > their market. That means a good core; points where they can integrate > either an off-the-shelf OSS UI or build their own differentiating one; > good tools (both for app developers and their own developers looking > to adapt to their hardware) and an assurance that some things (e.g. > security updates for some packages) will be got "for free". Let's face it - if giant companies have difficulties making ecosystems, we'll have even more difficulties. What I think really has value is the fact that you can avoid hiring a lot of Linux people to maintain a simple stack. That it's easy to get things made - want an alarm clock? here, take a beagleboard and an LCD and some speakers, write some QML, there you go. > > A bootstrapping project which delivers a tight Linux userland with Qt > might not provide sufficient leg up for it to appear on a list of > options compared with the perceived "weight" of Ubuntu/Debian/... (or > even, heaven forbid, Tizen). The problem is, again that if those solutions are really so great and easy, why aren't people having an easy time building products using these things? With Tizen, it's vaporware right now. But we intend on utilizing Tizen in the core where possible - our angle is just ease through Qt instead and a open innovative process. > > So, I suppose my question is: what's the perceived problem? How does > Mer address it? How is success measured? And is Core the focus because > it's the right answer for the perceived problem or because it's > pragmatically the thing which can be delivered now? Success for Mer is measured in people using it to innovate and for people to make prototypes and products using it. The Core is the focus as this is the simple thing many really lust for is a simple, easy-to-port working Linux platform, openly developed and governed that doesn't rely on the whims of corporate choices and roadmaps, that you can build your business on without risking bankruptcy at every new keynote opportunity. Success for myself is if I have a stable foundation for my business to make products in a world like in http://www.youtube.com/watch?v=6Cf7IL_eZ38 - and having fun developing the core at same time. BR Carsten Munk > > Cheers, > > Andrew > > -- > Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ > ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
Re: [Meego-handset] Mer breadth (Was Naming of Community Edition)
On Wed, Oct 12, 2011 at 20:55, Carsten Munk wrote: > > "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." -- hence the "there's no > "the" Mer Handset UX". > > There's some reasons why this split. [...] Thanks makes sense and is well explained. Having said that, I'd be concerned that a small Core with a few hackers won't be possible to gain enough momentum to capture a new middle-tier-or-above vendor. > 2) We want to move much of the politics out of the Mer project and > motivate people to create and build their own projects, though basing > on Mer, much in the same way site projects are based upon Apache > httpd. - we can't and don't want to govern projects utilizing the > core, let them innovate on their own terms. Apache's an interesting choice of example given there *is* an overarching "Apache" project and brand under which projects like JCL, Tomcat, HTTPD, Commons Lang, Commons Collections and so on all operate. > There was a discussion about same topic some days back on IRC and the > conclusion we reached was: [...] It's a little disappointing that so much is happening in realtime on IRC, preventing those who can't participate 24x7 from contributing. It's still a massive step-up on private conference calls within MeeGo, but it is still a barrier to openness when ad-hoc discussions result in decisions without any pre-prepared agenda. Even post-communication to the mailing lists would be sufficent. > The idea is to have the Mer project present it's functions well, allow > a common project wiki space for useful activities surrounding the > core, as well as extensively refer to vendors, users and activity > within the Mer community - but that those activities are self-governed > and projects/teams of their own. Well put. But what is the success criteria? My suggestion would be that a vendor is looking for an ecosystem-in-a-box whilst providing the differentiation capabilities they feel they need to succeed in their market. That means a good core; points where they can integrate either an off-the-shelf OSS UI or build their own differentiating one; good tools (both for app developers and their own developers looking to adapt to their hardware) and an assurance that some things (e.g. security updates for some packages) will be got "for free". A bootstrapping project which delivers a tight Linux userland with Qt might not provide sufficient leg up for it to appear on a list of options compared with the perceived "weight" of Ubuntu/Debian/... (or even, heaven forbid, Tizen). So, I suppose my question is: what's the perceived problem? How does Mer address it? How is success measured? And is Core the focus because it's the right answer for the perceived problem or because it's pragmatically the thing which can be delivered now? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
[Meego-handset] Mer breadth (Was Naming of Community Edition)
2011/10/12 Andrew Flegg : > Carsten wrote: >> >> We (as in the steering group) like to query the community for ideas >> on what to call the Community Edition in the future. Currently our >> splash screens says MeeGo 1.3 Community Edition which will be >> increasingily inaccurate as we're working to rebase CE on top of >> the Mer Core. > > OK, I'm confused on where you are with defining Mer's governance - > which "steering group" are you referring to? I'm talking about the CE steering group, as recently announced, we're on meego-handset, so :) > >> Some limitations: >> * Can't include trademarks or company names, such as MeeGo / Tizen, >> Nokia, etc. >> * Can't include Mer within it as Mer's a core and CE is not "the" >> Mer UX (nor is anything) > > OK, above you refer to "Mer Core" which - as you know - fits into what > I was pitching "MeeGo 2.0" would be: http://wiki.meego.com/Blueprint. > I think this is now the template for how Mer should function. However, > you also state "Mer's a core" (implying nothing more than that). > > Glossary: > > * "Mer" - a group of projects providing the infrastructure for developing > an open source, mobile Linux OS. > * "Mer Core" - a project which provides the smallest booting Linux & Qt > environment. > * "Mer Tools" - build tools and stuff on top of "Core" necessary to build > it either cross-compiled or self-hosting. > * "Mer Apps" - apps.formeego.org development, infrastructure etc. > * "Plasma Active for Mer" - a project taking Plasma Active and > delivering a Mer > build of it. > * "Handset UX for Mer" - a project taking MeeGo's Handset UX and delivering a > Mer build of it. > * "Mer Community Edition" - a polished, project aiming to deliver a > day-to-day > usable build of one or more of the other Mer projects, acting as a > reference > vendor. Fact is that we cannot host all those things and lay bandwidth, infrastructure, legal support, governance etc to them. As stated in the mail sent to the meego mailing lists: "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." -- hence the "there's no "the" Mer Handset UX". There's some reasons why this split. 1) It was seen in MeeGo that reference UX'es got preferential treatment in the core, subverting any process, especially when it came to big reveals - which caused the total breakdown of a open and working requirements process 2) We want to move much of the politics out of the Mer project and motivate people to create and build their own projects, though basing on Mer, much in the same way site projects are based upon Apache httpd. - we can't and don't want to govern projects utilizing the core, let them innovate on their own terms. 3) It was seen in MeeGo that having a central governance sometimes hindered people innovating - people were seen as to having to ask permission for everything. Let's focus at what -needs- to work, a good, open governed and open developed core for people to build upon. 4) We want to make sure that any customers of the core goes through the same process of contribution - everybody is treated the same (on technical merits), noone is preferred There was a discussion about same topic some days back on IRC and the conclusion we reached was: (Vendors in here is the principle of Mer 'customers', be it hardware adaptation, UX teams, hardware vendors, hobbyists, SME's, etc) Mer project is the efforts that is the core, the activities supporting the core (like QA, release engineering, etc), and activities allowing to utilize the core better by vendors (like BOSS, MINT, mic2, etc). There was also considered the potential of somehow help projects/vendors align with Core, in terms of releases, such as "this hardware adaptation tests to work on top of Mer v2" and be referred to along with release announcements. The idea is to have the Mer project present it's functions well, allow a common project wiki space for useful activities surrounding the core, as well as extensively refer to vendors, users and activity within the Mer community - but that those activities are self-governed and projects/teams of their own. BR Carsten Munk ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
