Something that is eating battery is some non hwaccelerated media like vorbis etc... I guess such open codecs also can be improved for those who are good as such stuff...

On something like an N8x0, maybe. On a "modern" device that doesn't use the DSP and has a media stack that includes pulseaudio, the codec is the least of your worries.

What, you managed to completely miss load-applet since 2005? :-b

explaining the reason I haven't bought am Android phone and still own my n900.it is real time multi tasking and that's the first thing I look in a mobile device, like I said about battery life, I've been using the n9 with applications running and what not asks have never really drained the battery. IMean with the suggestion that applications should suspend when the screen is off, well what if I don't want them too, if I can choose to use the performance profile all the time and others can use the power saver multitasking that would be the best of both worlds would it not, bit then don't developers have to deal with two types of memory management or does the OS do that.Istill get annoyed at the n9 when I lock the screen and it decides to app playing a video or when I minimise it

And what on earth is the point apps eating battery in the background if not neaded? Second did i say we should go android way?

I think you misunderstand my point. What I am saying is, if you port apps from pc to battery/embedded devices you have too think twice how you implement your code and avoid to eat Cpu when not needed. If you do strace on every pc apps today you see them poll alot in the background alot of communication with dbus/x11 and so on. I dont know if this is a problem. But just giving some an example. Thing is devs have to Think more about such stuff when we port apps from linux on desktop. But still I agree they shall not break compability with pc linux as they have done with android but I dont think that will happen anyway

So, again, this is my own personal curiosity, it does NOT reflect anything about how Jolla will be doing things or how Jolla thinks, but I personally think it's something that's worth talking about and discussed through, for any community involved device - and I'd like to discuss with a community about this.

Imagine a scenario that is along these lines - a device OS is consisting of:

* Mer Core, a fully open source mobile Core (http://www.merproject.org) and openly governed, used by multiple vendors
* A hardware adaptation, may or may not be closed source and may or may not be redistributable (like all other HW adaptations)
* A 'handset' project that serves to create a handset architecture, with general applications that work. Handset project is open source and openly governed (but not a democracy, see below).
* Company special sauce that makes device a <company> device, not possible to involve in by community and is closed source.

Combinations of other hardware adaptations + Core + 'handset' will yield a working and usable handset UI.

Company participates and contributes in all parts above.

Handset project is obligated to release stable and tested handset bases that companies/community projects can utilize to release usable 'products', but at same time should allow innovation, research in new areas, new devices, new features and ability to integrate them over time.

How do you think this can be working in practice - and what methods would you use to make it possible? When is special sauce a problem and when is it "OK"?

As a start, I don't think you can't do a product through democracy, there will be deadlines, there will be people who has to say no at times and there will be features that cannot be merged due to instability.

And there will be bugs to fix. It would be a mix between a project that has to both deliver, and have space for research and innovation.

There will be 'stable' releases where you can't merge features at the last minute.

This is all naturally occurring things in a product programme - in serious open source projects too which seek to deliver stable software.

It is in the current climate not possible to both do a commercially viable and end-user suitable mobile device and it being 100% OSS. Concentrated open source effort that comes from a company has to be financed somehow as well.

What do you think? How do you best involve a community in such a scenario so it's a mutually benefiting relationship? I'd very much like to hear proposals for models.

Let's not end up bikeshedding or have endless discussions - and especially, not end up in discussions about Nokia has done and what they haven't done and what they should have done.

This is a clean slate for discussion - start from this post and go from there.

This is fantastic news, if it sticks.
In that case it's our last hope, the final frontier in this gone-evil software world.
If they come up with something like the n900 with a physical keyboard, my money is as good as theirs. I'll pre-order it directly.
I don't care about 1000000+ apps either, decent hardware and the MeeGo/Mer OS base is quite enough.

Go Jolla!

It's a problem when it introduces APIs (fragmentation), when it's buggy and the vendor refuses to maintain it, when it can't be removed or replaced, and when it's actively used against the owner's interests or wishes.

With the possible exception of a few device drivers, I don't see why not.

Well, first you'd have to define "community". Because we're really not a homogeneous group at all, and we often have conflicting needs and goals ;-)

That said, I would go with this: pick the areas where you can work together with a community, in the open, and really do that. I'm not going to give you a laundry list of what not to do as we've all experienced that, but the gist of it is: don't start something unless you mean it.

May the source be with you.



ignore him^

Branding and look & feel is another area where you can get problems. When you're paying the costs for all that SW work, you can't possibly compete with someone else who can grab exactly the same product and slap it on devices at the same price (or cheaper) as your device.

Taking that into account, as differentiation is mostly happening on a UI level, it's not completely realistic to expect completely reusable/open licensing of some of these components. Something reasonably permissive like CC-BY-NC licensing, though, would still allow community use/experimentation, for instance.