The initial focus of Mer
 

For those tl;dr types: Focus on hardware support first, then on the software.

I wanted to share this on #mer, but I think a longer, more organised rant is in order.

Disclaimer: I'm involved in Mer, quite a bit. From managing translations, patching the N8x0 kernel, to packaging and porting apps from Diablo (Pidgin, Tear). I never planned to do this, but it really is fun and rewarding. I think the community is what is making this project rock, even if few people are directly involved in it (yes, we need you!).

My main concern is feature parity with Diablo. I don't want history to repeat itself. Let me explain.

I used to be involved in another project (won't name names), which also aimed at being a replacement of a well estabilished, commercial one. Unfortunately, the developers were not interested in getting feature-parity first, they were only interested in experimentation and technology previews that eventually went nowhere and have been discarded or simply abandoned.

Eventually people who were testing this product got frustrated, and rightfully so. The product couldn't have been used full time, because the essential, basic needs were not met. No-one wanted to test the product's superfeatures, because it was just painful. Every time they complained the developers would jump out with another experiment, and people would eat it up. This went on for years. Eventually everyone lost faith, it was clear the project would never achieve its goals.

This little anecdote is an attempt to draw some parallels with Mer to avoid such a dismal situation.

We need sound working perfectly and out of the box on the NITs, so that people actually use Mer for more than five seconds. Mer shouldn't be degraded to just another toy.

Currently, enabling sound is a painful process and sound works rather terribly. I refuse to "eat my own dogfood", because I'm not going to use a crippled system.

We need the GPS to work out of the box on the NITs, instead of a huge wiki page with instructions on how to enable it. With GPS we can then port Maemo Mapper, Carman and other cool Maemo applications that would attract users.

We obviously need to support the LEDs, the light sensor and the camera as well. And have an event manager to handle things like popping the camera out on the N800 or sliding out the keyboard on the N810 (+handle its backlight).

Also, we should not ship with showstopping bugs which prevent Mer from booting randomly.

Then, only then can we focus on software, on porting more apps, on sprucing up the interface. Mer is going to be just an irrelevant toy if we don't get these things done, no matter how beautiful we make it with those fvwm scripts.

Having full hardware support, few apps and a bare interface is much better than the opposite situation. A lot more people can get involved, to develop apps for it and test it. Hardware support is really low-level stuff that few people understand. Reporting bugs of a media player is easy, but not being able to actually use a media player and thus not have any bugs to report is a shame.

Now you see how much really needs to be done. That's why we need your help!

Re: The initial focus of Mer
 

I'll just begin with saying I do agree with everything you say, so what this is, is just added information to get a full picture. :)

There's however also a danger to this approach - see OpenMoko & the Freerunner. A lot of the focus has been to make the hardware play right. And frankly, most of the interfaces i've used on my Freerunner made me want to throw the phone across the room in a raging fit. People have difficulties using the interfaces - the interfaces feel like demos on top of raw APIs.

What we -do- try is to work separately on hardware support for different devices and on the core system.

However, if we do yet another distribution just for N8x0, we would quickly be irrelevant as a project. Hence why we spend time embracing the core of the system. Which often takes resources from HW support. We're a limited set of skills still.

This story should be told often to many open source projects.

And I thank you for bringing it in.

This is blocked mostly by the fact we have to set up the logistics of providing GPS driver and DSP tasks for sound legally to users. And provide images for these. Yes, we can make it work at this moment with potentially illegal methods but I'd rather be safe than sorry in this matter.

These logistics is actually one of my tasks this month in maemo.org sprints - to establish a set of tasks for maemo.org employees to push through, what Mer needs to do. And the reason we don't have it yet, is my own fault - I have had to take care of a bunch of personal issues so Mer didn't harm my personal life :)

Regarding GPS, it's not as easy as you might think .. as Mer is Fremantle code and runs Fremantle API, and Maemo Mapper uses libgpsmgr/libgpsbt which is a leftover from Diablo .. We need open implementation of liblocation-dev to make this happen. And make Maemo Mapper use this.

Agreed, which lbt is now working on. Finally someone took the task to do it. LEDs are actually already supported but noone wrote a open set of LED signals (.. mce.ini).

There's good and bad sides to firmly set deadlines for release. One is that we won't spend 3 years like Enlightenment to get things right. The other is that we have fresh snapshots to test, develop and such on. But this also means crap will come out once in a while. At least we're tracking the issues. I once ran a release that took two years to finish. But damn, it was solid. But users started using our betas very early - which was a problem since we were still developing it.

FVWM is really not for beauty, but for a need - to get rid of hildon-desktop 2.0.19, which is actually responsible for many of the bugs you experience :/

Again, thanks for the discussion. This is a open project after all, so any constructive criticism is always welcome. My advice is: Write up a list of 10 things that you believe should be fixed. That helps us plan through seeing what -you- think is madly wrong.

Re: The initial focus of Mer
 

Alright, we've already discussed this with Stskeeps in private, there is no need to reiterate the conversation here.

Let me just say that my post has a few problems I'd like to adress.

1) It focuses on h/w support for NITs only. This was not my intention, I meant all the officially supported h/w platforms (NITs *and* SmartDevices SmartQ Q5 and Q7 tablets).

2) The line between "software" and "UI" is a bit blurred, but hopefully it still gets the point across.

3) What I meant by "feature-parity with Diablo" is not to make a Diablo clone, but to have equal hardware support. Which is full. This point is perhaps what caused most of the confusion.

I've decided to monitor the situation and see what happens in the next three months. Perhaps judging right now, when the project is still in a bit of a whirl, is too hasty.

And, as we've agreed, when I see problems I won't hesitate to point them out.

Re: The initial focus of Mer
 

I am just a normal user and very curious how Mer will be. I need most the WiFi and the browser. The other features and apps are not so important to me. E-mail also matters.

Re: The initial focus of Mer
 

I agree with tomaszd that getting to the point where some developers and early adopters can use Mer day-to-day would be a huge step. I don't think hardware support is the only way to achieve that. I think the minimal set of required features will vary for each user, and some people (like myself) may not use that much of the hardware. I mainly use my tablet for PIM functionality and browser connectivity. I gave up on fiddling with my n810's GPS a long time ago because it took too long to lock. Except for the occasional youtube video I watch on my n810, I wouldn't miss sound very much either. Bluetooth support is for me just a nice-to-have feature. Of course, I wouldn't give up these things unless Mer had some advantages to compensate.

I just installed Mer 0.16testing3 and have to say that it's not too far away from something I could use everyday. For my usage pattern, I think fixing the following issues would allow me to feel pretty comfortable with Mer:

1. screen calibration problem - doesn't seem to do anything, and without calibration it's hard to choose some small buttons
2. on-screen keyboard constantly popping up on my n810 - if I could disable it that would be a start since I always use the hardware keyboard
3. most icons not working - I installed gpe-todo and could hardly use it because the toolbar had completely empty icons
4. app manager crashes - the app manager seems very fragile - this makes it harder to try out some new apps. This can be worked around by using apt-get inside xterm, except the on-screen keyboard problem (#2) makes xterm very frustrating.
5. power management - I haven't had Mer running long enough to know if this is an issue, but it is important that my tablet can remain powered on in a standby state with light usage for a couple of days at a time. The default-installed cpu-meter worries me a little about this.

Aside from these issues, Mer has some advantages compared to diablo for me:

1. Mer's GTK fixes some issues with GtkTreeView expanders on diablo. I'm writing a little python app that depends heavily on GtkTreeView and it runs better on Mer (more like my ubuntu laptop).
2. I did "sudo apt-get install emacs22-gtk" and it just worked. I have a fully graphical emacs. It would be even better if it supported the full-screen hardware button, but it is very usable.
3. Mer's xterm and ls support colorization. Nice! :)
4. It looks like there are tons of apps ready to run that are just an apt-get install away, such as gnumeric. It doesn't respond to the hardware full-screen key, but it has a menu option for fullscreen. It also doesn't have the bug that occurs under diablo where you have to click on the edit bar when editing every cell, which makes it much more usable in Mer for me.

Re: The initial focus of Mer
 

This is a good example of a normal buggy testing version.
Do not use testing versions of Mer if you expect no crashes. ;)

But if you do want to use buggy software and find bugs, please report them in the testing wiki-page :)

Re: The initial focus of Mer
 

Understood... I reported the bugs I found on the wiki. And it seemed that the 0.16testing3 worked better for me than 0.15 so I'm sticking with that.

Re: The initial focus of Mer
 

Is sound working by default in 0.16?

Re: The initial focus of Mer
 

I'm very excited about Mer. Unfortunately, I can't jump on board until I get flashing fix for my N810. Until then, I can't afford to hose my NIT.

But let me say that I think that any software project has to have a balance of bugs fixes and enhancements. Not enough bug fixes & you alienate your users as Tomaszd has said so eloquently. But enhancements can earn good will & cover up, if not a multitude of wrongs, then at least a good handful. :-) Plus, enhancements can bring workarounds.

Re: The initial focus of Mer
 

That's what Mer needs! Hardware support out of the box!
If that works, you may use other environments (like LXDE) and Ubuntu Apps until hildon is stable.