On Wed, Oct 12, 2011 at 20:55, Carsten Munk <[email protected]> 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:[email protected] | http://www.bleb.org/ _______________________________________________ MeeGo-handset mailing list [email protected] http://lists.meego.com/listinfo/meego-handset
