[Council] State of Maemo, Q32010.2
 

The following address summarizes the Maemo Community Council's take on MeeGo Conference 2010 and Maemo's Role in the Future Development of MeeGo...
http://static.maemo.org/static/4/487...ncil_f2010.jpgThe six of us laughed out loud as we filed into the sound-proof broadcast room that peered over the dark green expanse of Aviva Stadium in Dublin, Ireland. The irony of a private meeting between an otherwise open group of people was understood by all. Still, the only way that the current Maemo Community Council (along with Nokia employee, Tero Kojo) was going to find any sense of relief from the constant conference noise turned out to be in a room designed to keep others out. Privacy wasn't the point of this meeting, though. First, these sorts of events are the only time that the Council is ever able to meet face to face. Second, there weren't a whole lot of people at MeeGo Conference 2010 who would care much about what we were talking about. But, in our opinions the subjects which we discussed were quite important to our corner of the open source world, and may impact the future of Maemo quite extraordinarily. Glasses of wine and pints of beer accompanied a conversation that was both highly interesting and very fun.

Over the next weeks and months, some of the things the Council discussed will be further investigated within the Maemo Community. Other items of interest will just begin to happen. But, the main thing to understand is that Nokia is still very interested in supporting this community and allowing us to carry forward in exciting ways. There are still plans to sponsor the community infrastructure (website, paid employees, etc.), ideas about opening various pieces of Maemo source code that are still closed, and helping us to develop a successful community SSU. Likewise, there are still plenty of Nokia employees -- even those who have been permanently reassigned to MeeGo -- who want to continue helping us to be a world class open source software community. If you're unsure of what MeeGo means for Maemo, understand that the Maemo Community's job is not complete. We may be entering a new phase of life, but there is still more to come.

Initially, the more-than-evident differences brought by MeeGo Conference 2010 were quite astounding to some of us old Maemo hands. The event was part trade show, part conference, and part hackathon -- but mostly, trade show. There were private rooms for companies to make deals in. A large contingent of attendees had probably heard little (or nothing) of Maemo and what Nokia was bringing to Intel's new edition of Moblin. Many people were there to see how MeeGo might impact their bottom lines. But, as the conference proceeded, it became very clear that Maemo's impact on the future of MeeGo would not be lost -- or forgotten -- anytime soon. Once in a while, I would take a moment to survey the crowd in order to pick out those people who were fondling their N900s and smile, proud that Maemo was still important to a few of us. And, as most birds of a feather know, it doesn't take long for flocks to reconnect. That's exactly what happened last week, as most of the Maemo crew found each other talking about Maemo, hacking on applications, and mostly just enjoying each other's company -- like a gathering of chaperones at a high school dance, conversing by the punch bowl as the kids did their thing.

As MeeGo Conference 2010 transitioned from the weekend Early Bird Events to the official conference to the "Unconference" on the last day, many positive things became clear. My own observations solidified the fact that the Maemo Community is still important. Likewise, MeeGo (Nokia, Intel, and The Linux Foundation) understands its Maemo roots. The community who made Maemo what it is garner a lot of respect from those who have followed its story. While MeeGo is most definitely the future of Linux-based mobile computing, it is also the offspring of Maemo. In fact, if Harmattan had remained a Maemo-centric product, this year's Maemo Summit may have looked and felt quite similar to this conference. Sure, us Maemo types might have have known a lot more of the attendees, but the content would have been the same. It might just be time for us to admit that Maemo, as parent, has finally finished the rearing process and it's child's turn to grow and flourish.

But, Maemo is far from dead. In fact, if we continue to look at Maemo as the parent and MeeGo as the child, Maemo will remain very much a guiding authority in the future of MeeGo (and whatever may come after that). Maemo has learned a lot over the years and can lend a lot of expertise to those just now coming to MeeGo and the open source world. And, after having looked at some of the current and future iterations of cross-platform Qt development tools, the fact that GTK+ is still being discussed as a viable solution within MeeGo, and knowing that support for a variety of programming languages is growing, Maemo may be more important that you think. The vision of those who are in control of MeeGo is that applications created for Maemo can work just as well within MeeGo and vice versa -- with very little refactoring. If you're waiting for directions as to what you should do next, stop waiting. Continue developing for Maemo or start developing for MeeGo. In the end, both will support each other.and,

This is what I came away with from MeeGo Conference: the fact that MeeGo and Maemo can coexist in ways that I had never thought of before. Until now -- a little more than one week after MeeGo Conference 2010 -- I was sure that MeeGo was the only future. Now, I see Maemo as something much more than a stepping stone, but that of a parent whose child is ready to leave home and make a name for herself. Yes, it can be sad to say goodbye, but there is immense joy in knowing that we had a hand in the upbringing and we will always be the place that our child comes home to.



Link: Original article.

Re: [Council] State of Maemo, Q32010.2
 

I'm very pleased that Maemo applications will most likely be able to run on Meego, and this is not just for the apps: it's because behind every app there are one or a group of people from this community, people which after some years I think like friends. Having these apps and hence the traces of all these people on Meego will be a way this kind of friendship can go on. I'll always prefer a thing made by someone I know (sort of, but this is the way the Internet works), than the shining counterpart of a corporation with no face.

Re: [Council] State of Maemo, Q32010.2
 

If you write a Qt application (e.g. Qt Quick with or without a C++ backend), sure. If you write a pure Gtk+ (or, rather, Hildon) application, it's possible.

However, the point here is that you can start developing apps for MeeGo now, and target Maemo 5 and Symbian and, ultimately, MeeGo by using Qt.

Similarly, since Qt is now Nokia's official story - even for Maemo - Maemo apps developed in Qt have a very good chance of running on MeeGo.

But a lot of Maemo apps integrate into Maemo in specific ways, which means the UI toolkit is one of the smallest problems; so don't get too overoptimistic.

Re: [Council] State of Maemo, Q32010.2
 

The import thing for me to understand is not only the apps for meego running maemo or maemo apps running meego. but the maemo as OS (bugs, improvement, new features, drivers) and n900 as phone. as i understand that most important people from maemo community that provided new apps and features and took a big part in it, sooner or later would move to meego, as Nokia and other companies would make all efforts to make the same for MeeGo (and it can be by hiring or giving away next generation phones for free). so i don't see them stay in amemo community or having any profit/free time for this. and as a end user like me and others would need to go forward to meego, and even if it's sounds pretty promising, i don't think all of us could spend that money for new phone every year or even half year and even not to be sure if it last for a long time. while we can see that nexus one that was out a long time ago is still number 1 dev phone for android.

Re: [Council] State of Maemo, Q32010.2
 

I always hate posts from an invisible "I".

Re: [Council] State of Maemo, Q32010.2
 

I always hate posts that comprise massive walls of text and still manage to say absolutely nothing.

Or is "god I hope we're still relevant next year" all we got from the meego conference?

Re: [Council] State of Maemo, Q32010.2
 

Unfortunately the Talk aggregation doesn't keep the author information. If you'll click the link to the original article, you'll see it's been written by Tim Samoff.

Re: [Council] State of Maemo, Q32010.2
 

While there doesn't seem to be a lot of proactive "this is what we're going to do" statements, it is nice to have a report. I didn't interpret it the way you did - the takeaway I got is that Maemo and MeeGo can and should coexist.

Re: [Council] State of Maemo, Q32010.2
 

To say it similar to Ari Jaaksi's famous words, "you can see Maemo PR 1.3 as an instance of MeeGo!" :)
It's the Qt 4.7 stuff that matters for development, not the kernel version and set of default applications. I suppose PR 1.3 is about as much MeeGo as Harmattan would have been.

Oh, and QML does perform quite well on the N900. Just don't use OpenGL rendering for QML as that is currently slow.

Re: [Council] State of Maemo, Q32010.2
 

Opening various pieces of Maemo would be great!
Any more information what pieces this could be?

Nicolai

Re: [Council] State of Maemo, Q32010.2
 

The bottom line is most likely that someone needs to ask. If you have an area that you would commit to supporting and maintaining, Nokia may consider opening the code. Of course, the caveat is that the code you ask for may be proprietary and/or not necessarily pertinent to open in regards to everything that Maemo "does."

But, stating a case and providing a legitimate means for maintaining the code is the first step.

Tim

Re: [Council] State of Maemo, Q32010.2
 

My impression was that everything of substance has already been asked for and turned down by Nokia, as recorded in the relevant bugzilla entries. Is this a new message that they're willing to revisit requests that they rejected earlier? Or just a reiteration that in principle, they're willing to open components, even though nothing new is actually going to come up?

And why do these requests have to come from the community, anyway? Why can't Nokia come out with an enumeration of every closed component and say whether they'd be willing to open it? And at that point, maybe some community members would be interested in volunteering to maintain some of those. The cost to a community member to even write up a request is rather high, and the presumption should be that Nokia wants to do the right, open thing anyway.

Re: [Council] State of Maemo, Q32010.2
 

Exactly, I thought the licensing change requests queue was essentially dead after this, and even some things that seemed to have been agreed in principle are stuck in limbo.

Has Nokia communicated that this is changing in any way?

Re: [Council] State of Maemo, Q32010.2
 

This is very much like what was said a year or so ago and addressed by myself and others then. Is there really any reason to think it will be different this time around?

I realize its a difficult position being on council, and I appreciate the selfless service, but I want to point out that on this end it seems as though sometimes what Nokia says is just repeated without any retrospection, value add, or adjustment for the perspective that maemo.org should be managed for the benefit of community members. Hard is it may be to do in a complicated environment, sometimes value lies in having the insight to lead the community towards solutions that will work and away from dead ends. The licensing change requests queue from a year ago seems to have been a dead end.

Re: [Council] State of Maemo, Q32010.2
 

don't get your hopes up. They've been promising to "open pieces of maemo" since the n770 days. once a particular package hits end-of-life, there's about a 10% chance on average they'll release source code.

nokia is apparently convinced something as unique and crucial as a crippled calendar application or a slow, featureless media player is somehow valuable to the corporation and has to be kept under lock and key.

Re: [Council] State of Maemo, Q32010.2
 

Well, let's hold them to their word:

1. Find a package
2. Find someone who could realistically maintain it
3. Put together a business case.

The Council would be happy to help with any of the above. We will also then push Nokia for an official response - of course, it might be "no", but that should be accompanied by an explanation.

However, I can understand why Nokia isn't going to do the work (checking licensing, looking for commercially sensitive information in the source) unless all three criteria are met.

Re: [Council] State of Maemo, Q32010.2
 

Wait, why do we have to come up with new ones when there are several requests still pending? Many of them are not objected to in principle, but there's no one looking at them. I mean, even something like a simple shell script that is a no-brainer has been stalled for over 3 months due to (presumably) lack of resources.

I'll ask again: has anything changed since the last word from Nokia on the subject I linked to in the previous post?

Re: [Council] State of Maemo, Q32010.2
 

Some of the business case and maintainerships in there are a little vague; a "well, it'd be nice" and "Diablo SSU would benefit" (without saying how, or what it'd enable).

Nokia have said it again. How have you escalated your currently stalled requests?

Re: [Council] State of Maemo, Q32010.2
 

If any more info is needed just ask, that's what a bugtracker is for!

That's nice. So there is someone assigned to looking at licencing change requests again?

I didn't realise we had to, or even how to escalate if bugs.maemo.org isn't the right channel any more.

FWIW the instructions state:

not "if there's no response take it to channel foo" or "keep bugging us until we respond" etc.

Re: [Council] State of Maemo, Q32010.2
 

I don't know what detail is needed, but I'd've thought that a more compelling proposal would be easier to get approved.

AFAIK, the process is the same, but...

...if someone doesn't respond in a timely manner, bugging them/the Council/Quim seems more appropriate than saying "well, I filed it, nothing happened, therefore Nokia is purposefully saying one thing and not doing another". Don't ascribe to malice what can be explained by incompetence, forgetfulness or over-work.

If after some bugging there's a response of "please wait" or no response at all, complaining would be appropriate and not taking Nokia's future assurances at their word.

Re: [Council] State of Maemo, Q32010.2
 

IMHO the problem isn't approval, it's getting someone to actually do the work. Requests for components that Nokia isn't willing to open get WONTFIXed pretty quickly.

Like this? ;-)

I don't believe for a second that there's any malice involved. But there is such a thing as fatigue from too much begging that gets you nowhere.

Re: [Council] State of Maemo, Q32010.2
 

It is just that:
sounds to me like something new, a new plan or strategy for
opening closed parts.
I am really excited about that. What can we expect?

Nicolai

Re: [Council] State of Maemo, Q32010.2
 

Not sure if this has been discussed before, but by giving incentives for this community to migrate to MeeGo, as in providing an application framework that is compatible with both MeeGo and Maemo, with still making it clear that doom looms over the horizon for Maemo, is Nokia trying to set this community as the core for the new MeeGo community?

Forgive me if I sound naive, I'm still getting myself acclimatized to the way things happen.

Re: [Council] State of Maemo, Q32010.2
 

So do the same thing again and hope that the results will be different this time? No, I don't think so. Sometimes you have to learn and move on. I don't have an obligation to give Nokia repeated chances or to repeatedly bang my head against a wall.

To put this in context, I have a hard time asking community members to work towards Diablo SSU^2 because my gut and my brain is telling me that we can't rely on Nokia opening things up. As a member of this community, my obligation is to the community. And I can't, in good conscience, try to convince fellow community members that they should expect good results. I said awhile ago that we would be better off if we proceeded on the assumption that nothing would be opened up and be pleasantly surprised and grateful if they do.

Re: [Council] State of Maemo, Q32010.2
 

Then don't. I'm not putting a gun to your head.

I don't disagree. And, for Fremantle, the bits I'm interested in seeing improved are already open source.

Re: [Council] State of Maemo, Q32010.2
 

This is ridiculous. If they can't respond in a timely manner to their bug tracker they need to get the hell out of the software industry altogether. It doesn't matter if it's malice, idiocy, or (poor babies) over-work. If Nokia stipulates a procedure and the procedure doesn't work because of them then Nokia is full of crap, full stop.

At the very least the Council can stop bleating about "opening up maemo" every six months so we don't have to explain to a new batch of users that it is all talk and no action.

Well, congratulations, you fantastic egotist. Is it dizzying, the way the world revolves around you? I guess we can stop talking about this altogether, since you've got what you want.

Re: [Council] State of Maemo, Q32010.2
 

You need to remember that the council members are in effect employees of Nokia marketing. They get small favours from Nokia (paid trips to conventions, free gadgets), and in return they try to make it seem as if Nokia cares about Maemo users, as in every few months "Nokia wants to open up code, but bad developers don't help", or in council publishing Nokia's "response" to MyNokia fiasco, as if it is actually a response.

Re: [Council] State of Maemo, Q32010.2
 

The Council is here to help (ignoring Matan's trolling). If no-one says "oh, by the way, could you get involved as the relicencing process doesn't seem to be working", we won't get involved. As it happens, I have emailed Nokia this afternoon - pointing at the "ping" lma pointed to, asking on the status and further clarification.

I think you misunderstood me. I was saying that I've not followed the relicencing queue as I've not put anything on it. I was also pointing out that the openness of Fremantle is higher than Diablo.

If there's something blocked that you're interested in, could you please give me the URLs, and let me know your attempts to chivvy it along? I agree with you and lma: in a perfect world, we would not need to chase things up; but this is the real world and, technically, Nokia don't have to open anything up. It's difficult to justify a commercial business case for it, so bleats of "everything should be open" won't help.

Maybe nothing will, and if you're tired of trying, that's fine.

Re: [Council] State of Maemo, Q32010.2
 

Hey, that's out of line.

Those were available to anyone with a significant contribution (including yourself), or even (as in the case of the Amsterdam loaner N900s) anyone who just showed up.

Note that it was a former council member that voiced the strongest objections to cherry and wrote notmynokia.

Re: [Council] State of Maemo, Q32010.2
 

Fair enough, let's get this out of the way ;-)

Oh, by the way, if the relicencing process is back in business could you get involved as it doesn't seem to be working. More specifically, if there's someone looking at this again they could do a lot worse than check the existing pending requests (they're not that many).

Thanks!

That's somewhat debatable, but I don't think a direct comparison is meaningful. I would say they're both semi-open but quite different and leave it at that.

Agreed, and for the record I have no beef with Nokia, the council or anyone else in that respect.

Re: [Council] State of Maemo, Q32010.2
 

Can someone please elaborate on this

Thank you,

Nicolai

Re: [Council] State of Maemo, Q32010.2
 

I can certainly sympathize with this position, having a fair amount of experience with Nokia myself, but I think it's worth reminding ourselves that Nokia is not a hive mind. The message we should probably be taking away from this is: "There are a lot of people inside Nokia working towards the same things you're working towards, but it's a tough battle and we need all of the help you can afford to give."

This is much the same reason I can't recommend Nokia products to friends and family (especially in the US) you can't reasonably expect Nokia to provide reasonable support for their products.

What it comes down to, I guess, is whether it's worth it to you to continue pushing the last bastion of true open source in the mobile world in the right direction, or whether it's time to throw in the towel. This is the big advantage that MeeGo (hopefully) brings, since it's not completely beholden to Nokia.

Re: [Council] State of Maemo, Q32010.2
 

I think we should look at the practicalities. We will lose people if we just ask them to give and push, etc., without addressing their concern that effort is wasted.

Re: [Council] State of Maemo, Q32010.2
 

Indeed, and for each person that's going to vary a bit, as it still only amounts to opinion at this point.

That's exactly it, though. Is the effort wasted? Evidently at least a few people at Nokia believe not. The message I took away from the conference is that they need us to help keep things moving in the right direction. Whether you want to fight that battle is up to you, but I'm not convinced it's futile yet.

Re: [Council] State of Maemo, Q32010.2
 

The functionality that Nokia finds interesting to open is being opened in the context of the MeeGo project. There was a bunch of components being opened around the MeeGo launch, another wave came when MeeGo 1.1 development started and these days there is another way going on together with the MeeGo 1.2 gate open for new features.

So yes, I agree that the requests at bugs.maemo.org could be handled more proactively, with more speed and a better ratio of acceptance. Still, it is also true that the amount and quality of free software contributions pushed by Nokia during 2010 alone is massive.

After four years working at Nokia I have seen just one way of opening components that was successful: the maintainers of the software (Nokia developers or from other companies) concluded that certain functionality would be better managed through an open license, and the whole step made sense to the Nokia software strategy.

If a request doesn't ring a bell to the maintainers and/or doesn't fit in Nokia's strategy then its chances are less than slim. And even when a request fits both then a dose of patience might be needed due to development priorities, release calendars...

This is no surprise to anybody involved in serious platform development, and this is perhaps why most of the open items in the queue have no vivid discussions at this point. Still "opening software" is a hot topic in certain Linux user circles and this is why I believe it gets hot here from time to time.

Conclusion for the Linux users interested: Nokia is opening a lot of valuable source code providing features that were not available in the standard Linux & free desktop stack - even if there is not much movement around some requests for opening legacy components.

Re: [Council] State of Maemo, Q32010.2
 

Question is, what does this mean to current Maemo 5 apps?

Let's take the media player as an example;
MeeGo will probably have a media player on its own, that uses some different audio system (I haven't checked), but since it's based on new libraries, it might be hard to backport.

Maemo 5 has a media player that can receive so much improvements from this community, yet, Nokia decided to keep it closed so competitors can't use the code in it, not sure which competitor wants to do that...

In this case, opening Maemo 5 components in MeeGo won't really benefit everyone around here, especially those planning to stick to Maemo 5, since... well, it's a much better day-to-day OS compared to MeeGo.

Re: [Council] State of Maemo, Q32010.2
 

I still can't fix the crappy, barely-usable calendar because apparently the interface code is precious.

Re: [Council] State of Maemo, Q32010.2
 

Nokia has been quite consistent at telling that it has no interest opening its user experience layer - which includes the Nokia proprietary apps. It's their investment and their decision.

Taking the media player as an example, if you are interested in community engagement then please consider contributing to the MeeGo media player(s) of the Handset UX or established free software projects based on Qt like Amarok. See http://jefferai.org/2010/05/amarok-m...the-beginning/ & http://amarok.kde.org/blog/archives/...martphone.html

Re: [Council] State of Maemo, Q32010.2
 

About Calendar, Nokia has made extensive contributions to the KDE's Kcal project, which powers now MeeGo's calendar backend: http://wiki.meego.com/Project/Calendar

On top of it you have the Calendar application for Handset UX, running on top of Qt and therefore with an interesting path of portability on top of Maemo 5.

Re: [Council] State of Maemo, Q32010.2
 

Can't you see the Qt forest for the MeeGo trees?

Porting to Maemo 5 MeeGo OSS apps and their open frameworks underneath is probably easier than dealing with legacy apps developed by someone that has just opened the code and moved forward to... probably to work on MeeGo.