Over the past several weeks I've been hitting one concept over and over again: "reference".

So Nokia has dramatically reduced commitment to MeeGo and has cited, amongst other thinks, MeeGo's inability to deliver a focussed baseline with sufficient speed. I happen to agree with this failure (and given Nokia was a significant part of MeeGo's management I don't think there's a blame issue - more a how do we fix it issue)

Assumptions and observations:

• MeeGo is intended to provide a viable but focussed baseline upon which vendors can build compliant products; not to be an expansive and 'complete' linux distribution.
• MeeGo has limited dedicated resourcs and focusing them on a reduced MeeGo core will improve quality.
• MeeGo's main customers are not end-users - they are device vendors : they should be the focus of our core engineering team's design, delivery and QA effort.
• MeeGo core does not appreciate the difficulties a vendor has in tracking MeeGo;
• A visibly secure development model is important to the perceived integrity of MeeGo - so visibly restricting write access to the core is important.

Proposal:

• MeeGo Core is confirmed as not being a linux distribution
• An open MeeGo project (openMeeGo?) is created on the community infrastructure to provide a reference MeeGo distribution
• Packages not *essential* to the delivery of a compliant MeeGo Core are moved into the community OBS (emacs, vi etc - maybe even the reference UXes) where they are available for use by development teams and end users.
• "openMeeGo" acts as a reference vendor and provides a forum for reviewing and improving the processes MeeGo uses to communicate releases
• MeeGo community (which includes core developers) has a significantly lower barrier to entry.

So... lets say we have some device that run MeeGo; what else can it do? Where are the apps?

This is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project.

As you may know I recently volunteered to setup a community OBS in my "spare time" (hah, right!). This is a progress report because I've reached a significant milestone... the following 193 applications have been built from 'Extras' most on both ARM and X86:

In a closed environment you use what's in the SDK and you get your own little space; talking to others is discouraged and sharing and re-use outside the blessed area is frowned upon. This dictatorial style has the advantage of making life easier for the vendor. In an open world we have more interactions... and as students of networks know: increased connectivity brings increased complexity as well as increased benefits.  So this is an initial proposal for the organisation of OBS build projects and packages to support a QA process into an app-store / Extras or garage-like environment.  I'll introduce some basic OBS concepts and then describe how this might work. I would like this to raise awareness of some potential complexities that we may face and get some thoughts on how to deal with them. ...... Oh, and this is about both Maemo and MeeGo.

...and not only is the Shadow War over but it looks like we will have a community OBS thanks to the team formerly known as maemo.org infrastructure :)

Here's the BBC Technology story it's good that the N900 is being seen as an open system at this level.

snippets:

The browser, codenamed Fennec, will initially be available for Nokia's N900 phone, followed by other handsets.

 and

 Apple is very restrictive. It doesn't allow other browsers.

which is all promoting the core values the community loves about Maemo...

This i just something that I saw on LWN (from Harald Welte) and felt needed a little more visibility here at maemo.

The presentation shows how Google has simply thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. Things like hard-coded device lists/permissions in object code rather than config files, the lack of support for hot-plugging devices (udev), the lack of kernel headers. A libc that throws away System V IPC that every unix/Linux software developer takes for granted. The lack of complete POSIX threads. I could continue this list, but hey, you should read those slides. now!

 The slides

As usual the commentary at LWN raises some interesting counters.

I got caught in a nasty traffic jam tonight just a few miles from home.

There was a road that I've never been down - windy country lanes, right general direction...

I grin and whip out my N900 and give it to my wife to navigate us - just the ticket?

No.

An hour later we've been lost several times, argued and are generally very annoyed and unhappy. My wife thinks that *I* think she's stupid 'cos she can't use a map application. She hates that. I hate that.

The maps UI sucks. It is unusable to a novice. The GPS seems to update randomly every 10 mins or so. It blocks the screen with messages. It tries to connect to GPRS when there's no signal (and clearly no need). Mostly it just completely fails to meet its purpose.

As we hit a road we recognised I realised that I was so pissed off with this experience that if I were a consumer who'd paid retail for this device I would want my money back - and as someone who has breathed Maemo for almost a year now, that makes me very, very sad.