MeeGo Reconstructed - a plan of action and direction for MeeGo

A few days ago, I posted MeeGo not being dead until the fat lady sings. Now, the reason why I was being so cagey is out in the open: Mer is alive again, and aiming for MeeGo 2.0.

This isn't just a continuation of MeeGo, of course - nobody in the MeeGo community proper would argue that there is a need for change, and we've got a few lined up, such as an easier porting story to other devices and architectures (and a much friendlier community atmosphere to such projects), complete meritocracy, and many more.

To get one thing out in the open: this is just the core OS, a Linux distribution. There is no UI, and hardware adaptations are seperate from that core OS. It's an extremely slim Linux vehicle for making products out of. What you put on top is entirely your business - it's just a tool.

The idea being that you can then take it, drop a hardware reference for a device you love quite a bit, drop a UX in on top (either one you write yourself, or one from the greater community, like the MeeGo handset UX), and you have a product. Plasma Active is another example of what could be dropped in as a UX. The MeeGo handset community edition will most likely be looking to rebase on top of Mer in the near future.

In terms of the app stories available: Qt is available on Mer, so for developers seeking to target Qt, look to install Mer derivatives on your devices. This doesn't stop other toolkits or technologies, of course - all are welcome to come and base around Mer. We also have high hopes that we can achieve some base sharing with Tizen, and ideally, easily atain Tizen compliance. It is HTML5, after all.

I look forward to running a MeeGo handset UX on top of a Mer core on my n900 soon, and what can be accomplished in the future.

If you'd like to talk with us, pop onto #mer on freenode or use the webchat. We also have threads on both the MeeGo and maemo.org forums, should you be a fan of those.

the beauty of open source...

...is that it just doesn't die because somebody says so.

A lot of noise has been made about Intel closing up the MeeGo shop and heading for new waters, but predictably, a lot of people aren't very happy with this move, both individuals and companies who have products based around MeeGo.

I won't rehash the story any more than that, except to say this: MeeGo, or the ideals of it - an open mobile-oriented platform featuring Qt is still very much valid and needed, and it's not going away. There's some discussion already going on on the MeeGo lists about how best to continue, already.

Watch this space. MeeGo (in some form or other) is not dead, and neither is Qt.

MeeGo CE work

With the governance for MeeGo CE now being turned over to the community, and increasingly, the work on MeeGo also being done by the community, I thought that perhaps now was a good time to look at where we are, and where I think our priorities should be. I've already started working on these myself, and will continue to do so.

Present:

• CE Fall Release is a good start, a lot faster than 1.2
• We still use too much memory running daemons for things we (mostly) don't use, like Tracker. We should look at ways to minimise this penalty, or remove the offenders.
• We are lacking in applications in a number of areas
• Our (MTF-provided) theming is really ugly IMHO

Future:

• It was looking like we were more or less going to get a new UI'for free' from Intel with their tablet work, but signs show that they seem to have abandoned this work, so I don't think we should rely on it, and given that it isn't at all optimised for our screen sizes and resource constraints, we can't really reuse it wholesale, either. That thankfully doesn't mean we can't reuse pieces (lipstick uses parts of meego-ux-launcher. :)
• We should investigate applauncherd to (further) speed up application load times. This will have a memory hit, so we should be careful, and measure to make sure it is really worth it, but this could also be minimised by only running the QML booster plugin.
• Qt needs investigation to make sure graphicssystem switching is actually working; I don't think it is at present, and this may mean a lot of wasted RAM with GL contexts being held by backgrounded applications.
• Software tuning is required on all areas of the stack, one simple example found in a few minutes of investigation is messageserver, which links to QtGui unnecessarily.
• It would be nice to revisit theming, and make things prettier. This is possible on an application-by-application process (e.g. I personally think things like lipstick and qmlcalc are the start of some good directions), but we need to make sure we have an up-to-date, OSS licensed Qt Components theme available which *looks good*, and also *really* nice looking icons for our applications.
• More applications! I've started work on a clock / alarm application, we'll see where it goes in the next week or two. I'm waiting for Tom Swindell (alterego) of MeeGo fame to help me with a nice QML theme for lipstick, and there's a few other projects I have on the boil too - watch this space...

Sorry for the brain-dump. I hope someone has found it helpful/useful, it's at least helped me prioritise things a bit for myself, maybe for you too? :)

It should go without saying, but should anyone want to help out on CE at getting an open source mobile OS into top gear, please, by all means get in contact with us on #meego-arm on freenode, and we'll find you something to do.

on conferences

Just a short post, as I'm by now fashionably late for this.

I attended MeeGo Conference in San Francisco in May, my greatest thanks to my excellent employer, Collabora Ltd for sponsoring my trip. It was a pretty intense week for a lot of reasons, one of which being that the week before my visit, I was asked to demonstrate some software I have been working on, a sort of mesh synchronised object store.

I showed off a simple contacts application synchronising contacts across three devices, but my real plans for that are a lot more - but that is content for another post, perhaps, another day. I think the show went pretty well, certainly, the reception of some parts of the keynote was a bit mixed.

It was also the first time I have visited the US before, and it was certainly a different experience to practically anywhere I have been before. San Francisco was an interesting place in particular to visit, with extreme contrast (people living on the streets with obvious mental issues, while there are villas in the background etc.) and typical cultural differences, some of which I found quite strange, like mandatory tipping. All in all, I think I'd visit again, though.

The conference itself was quite excellent, lots of interesting talks going on, and as usual, meeting all the familiar faces - and making new friends - was fantastic. I only wish I had been less frantically busy and jetlagged (or tired after being busy) to make more of the experiences. By the time I had recovered from everything, the conference was almost over. Though thankfully, I spent an extra two days wandering the streets of the city seeing some sights.

the bomb has hit...

...now we need to let the dust settle.

So, unless you've been living in a cave, you've probably heard about the Nokia news by now. I of course have thoughts and opinions about this, not all of them clear. So I'll just stick with what I think about the future for Qt and MeeGo for now.

A lot of people around the Qt development community (some users, some contributors, and some Nokians) have been worrying. There have also been a few people asking about forking, and to them, I would say: not yet. Let the dust settle. Right now, Qt themselves don't know exactly what the future holds, but I would expect this to be clarified in the near future. Thiago has also clarified that open governance of Qt is still an ongoing project.

I don't personally see too much changing here, because despite news of Symbian's perhaps timely death, MeeGo still needs Qt, and I don't think MeeGo is in any imminent danger. Here's why.

• MeeGo is not just Nokia
  
  Intel is also involved in MeeGo, and in addition to that, there are other partners and OEMs.
  
  This will not change.
  
• MeeGo is open
  
  This means that anyone who wants to continue the work and contribute, can. There's no barriers, no licensing fees, and no patent worries. This is attractive to hardware manufacturers. Thanks to (trying) to reuse upstream components, it's also a less expensive alternative than Android.
  
  This will not change.
  
• Nokia did, right at the outset of the announcement say, they are continuing work on it
  
  Yes, it is true that they also announced that they are reducing their R&D spending on it, but perhaps this isn't such a bad thing. Perhaps lower spending will enable them to spend on what really matters, and focus on getting something out the door.

That's not that I think today's news is great, or even good - but I'd like to encourage calmness. Let's all have some time to digest the information and think about what exactly it means.

I might write more about this once I've had a chance to collect my own opinions a little more. I'm certainly concerned, and interested, but there is no need to panic.

the Qt contribution ecosystem

After recently writing about the broken contribution process in Qt, I got a little bit inspired to see what the current 'lay of the land' of the Qt contribution ecosystem looks like. So, I did what any self-respecting hacker would do, and wrote a quick script over the course of a few hours to generate the statistics I wanted. Beware, gitstats takes a long while to run over repositories with a big history. If you want to skip the work of running it over Qt yourself, grab a copy of the CSVs I generated.

Before I go any further, I'd like to emphasise the following from gitstats' README:

The information gitstats generates is in two primary facets: which individuals
are doing the work, and which organisations do those individuals come from.

The raw output from gitstats isn't perfect (obviously) as some individuals
change email addresses, etc, but gitstats does make some effort to try keep
track of people.

Usual disclaimer about raw data applies, you should have insight into the real
situation behind the figures before trying to apply any sort of real
interpretation to it.

There are a few ways in particular that gitstats' information is flawed. The biggest being that the 'organisation' an individual belongs to is generated from the first component of their email address.

The problems here:

• Wth people contributing from email addresses like ritt.ks@gmail.com (who is, by the way, a very prolific external Qt contributor): gitstats lumps them into an organisation like 'gmail'.
  
  This isn't bad for the *majority* of contributors, but obviously for those from free mail domains, it's not really correct.
  
• This also results, in some cases, in an extra 'organisation' being created, when someone who is already contributing to Qt switches to another mail address, as can be seen in the data with e.g. 'abecasis', created by João Abecasis, a Nokian, who has occasionally committed from joao@abecasis.name.
  
  This can't really be fixed in a satisfactory way automatically, as e.g. you may very well have people who move from one company to another, but keep contributing to Qt.
  
  The not so obvious problem with this is that contributions go to the organisation that user is in when they made that particular commit, so João's commits under abecasis.name go (incorrectly) to abecasis instead of to Nokia.

The Organisations

Notes when interpreting this graph:

• I had to cap the LOC added by Nokia, because it was off the scale. Part of this is because of updates to /src/3rdparty/ (think things like Webkit updates) by @nokia.com addresses
• For all intents and purposes, Trolltech and Nokia can be lumped together, I didn't do so because of the previous note
• 'gmail', as noted above, is actually a group of lots of individual contributors. There's some more of these (like 'users', which is people with email addresses from users.sourceforge.net)
• Some of the large contributions (gmail, archlinux, holodeck1, seznam, ostash) are bulked out because they include translation updates

Of interest to me when looking at this graph:

• Nokia is the elephant in the room. This is not unexpected, given that they have some 130 folk contributing to Qt. They are undoubtedly the largest single contributing organisation by a very, very long way.
• It looks like there are companies other than Nokia interested in contributing to Qt at a fairly large scale, for example, accenture, sosco, and digia. I'd presume that these are contractors. I'm informed that contractors generally work from the Nokia offices, which would explain why I hadn't seen much of them in Gitorious. (They still go through a code review process, as do other Nokia employees.)
• There is a large impact thanks to individual contributors
• There is a big KDE presence. This is not unexpected. :)
• There are a number of smaller companies in the Qt ecosystem, such as Codethink, Collabora (my own employer), Blankpage basyskom, and medical-insight.

The Individuals

Notes when interpreting this graph:

• I chose to cut out Nokia/Trolltech, because otherwise, it would have been pretty pointless. They contribute a lot, and there are a lot of them. Besides, for me at least, it's more interesting seeing the individual contributors.
• There is at least two ex-Nokian/TT people here:
• Anders Bakken, whom I have left in because he still occasionally contributes to Qt for his new employer (I think). But part of his number will of course come from his time at Nokia.
• Benjamin Meyer is an ex-TT guy, who left a few years ago. Since he never committed from either a TT or Nokia address, there's not much point to removing him, I think.

Of interest to me when looking at this graph:

• Contractors seem to be doing quite a bit (Shane Kearns, Mikka Heikkinen). Not surprising.
• Ritt Konstantin is a hero.
• There are a lot of people working on translations outside of Nokia (Ritt Konstantin, Laszlo Papp, Jure Repinc, Victor Ostashevsky), and just like we saw on the organisations graph, the numbers get a bit skewed as a result
• The numbers drop off very quickly, especially if you were to disqualify translations from these figures. This is a bit disappointing, but not surprising, given the hurdles to contributing to Qt.

Qt: the process is broken

After reading Albert's thoughts about the state of openness in Qt, I felt like I had something to contribute, and contribute I did in the comments on his post, but I don't think it is enough.

While I encouraged him to "please do stick in there", we're not exactly just at the start of this process anymore; Qt's moves towards opening up have been well received, but in the words of Thiago, "now we have to do more".


At the heart of it, I think it all boils down to two things:

• Lack of manpower
• The process to integrate merge requests is clunky and slow

So... what do we do?

Lack of manpower
This is actually probably is a much bigger problem than just merge requests in that there just aren't enough skilled people working on Qt itself (with push access), and the amount of work they have to do on their own tasks means there simply isn't enough manpower left over to work on the merge request queue, especially given the hoops that the current process requires the committers to jump through, which amount to an awful lot of effort and manual checking.

Solution:
Get more people. Perhaps it's not even out of the question to dedicate a few people to working on community management at a technical rather than twitter-level.

While marketing Qt is great, and I'm far from knocking those efforts, you also need to have a healthy developer community around Qt itself, and right now, that doesn't exist. If you have developers dedicated to furthering that community, you will reap that investment further down the road.

I imagine that people in this sort of a role would act as the 'grease in the wheels' while Open Governance moves slowly but surely along, helping in reviewing merge requests (knocking back those with simple mistakes) and working together with others inside of Qt to integrate the finished ones, basically moving all of the burden of integration off of the product developers.

Think community managers on steroids. With push access and the knowledge to use it.

The process is clunky and slow
Work on the process. Open Governance is addressing this, but so far, there's been a lot of talk, and little (visible) action thus far.

It needs to become more of a priority. The quicker this is solved, hopefully, the more manpower Nokia will gradually have to shift onto people other than their own tasks, and let the wider community worry about what concerns them.


Conclusion

(also known as, "where I state the blindingly obvious")

Let's face it, it's great to have access to the source repository, it's great to be able to submit changes, it's great to have an open license.

It's not so great to have your work ignored after making requested changes, or worse still, ignored completely.

This needs solving.

So, Nokia, are you really invested in making Qt as good as it can be?

[usual thanks to my good friend, John Brooks, for proofreading and putting up with my horrible use of English]

achieving openness: it's about the journey, not the destination

I have written a lot of articles previously about project openness, and I've had this one cooking in drafts for a while without time to write much around the actual issues I'm presenting.

With some more thought, I realised that the best way to proceed is just to publish, and not point fingers and draw conclusions (though I certainly did write this with some projects in mind), so here goes.

• Do you reject contributions for non-technical reasons?
• Do you have development documentation (e.g. build instructions, architecture information) available for external contributors?
• Do you answer questions on design, architecture, etc. from external contributors?
• Do you work with contributors to polish their contributions and educate them as to best practices and your project?
• Do you let external contributors take part in design decisions?
• Do you hold external contributions to the same standards of review as internal contributions?
• Do you grant rights (such as commit access, ability to close bugs) to external contributors?
• Do you have a public means for (preferably real time) communication that you use?
• Do you have a public issue tracker?
• Do you use your public infrastructure wherever possible unless an issue is explicitly private?

Run your project against the list -- perhaps you'll find some things you can improve on.

If you've any suggestions to add to the list, why not write a comment? :)

Qt: Bootstrapping openness

I witnessed (and was pleased to take part in) some interesting discussions on #qt-labs this afternoon, all stemming from a contribution to Qt3Support being rejected.

A long story short, the contribution - despite looking reasonably valid - was rejected because Qt3Support is effectively unmaintained, and as a result, any changes to it could have negative impacts on users of the support API.

I understand that argument, yet at the same time - I can't help but think it's a bit of a backwards approach to be taking. Typically, a contributor will wander along, find a bitrotting module/project that interests them, throw patches at the previous maintainer - and shortly after doing so, find themselves a de-facto (or indeed official) maintainer through their efforts.

This is a natural progression of things and should really be encouraged, it allows what would otherwise be dead code to live on. However, in Qt3Support's case, the central point was that they'd love someone else to take responsibility for it, but don't want to expend the effort themselves to triage, maintain, and otherwise support it right now.

To me, it's a false saving.

Time you save not maintaining it now (and encouraging potential contributors/future maintainers along the way) is spent being forced to put the code on life support maintenance if you decide you want that code, for whatever reason, later on.

Not to mention that those people who might be happily contributing you ideas or patches (to code old and new) are instead going to be spending their spare time doing something more rewarding than having their hard work rejected in the future.

Openness doesn't just happen overnight. It isn't just in the licensing. It requires real persistent effort and culture change. This is something I plan to keep revisiting over my next few posts.

{Note}: Before commenting, please note that this issue isn't *just* based around Qt3Support. That is one example of the problem, yes, but the patch was actually to QWorkspace which actually wasn't part of Qt3Support, and QtSql is in a similar boat - and there is nothing to port code using QtSql *to*.

Qt and Open Governance - it begins!

Just a short post to note that the promised infrastructure for Qt's open governance project is now live - go read Thiago's blogpost announcing this for more information.

This is something that concerns me quite a lot, and I'm extremely happy to see it move forward.

I would like to urge anyone interested to subscribe to the mailing list and help take part in the discussions over the coming weeks.

MeeGo Developer Engagement

Some of the more observant people may have already seen my mail to meego-dev proposing a program for developer engagement, or one of the forum threads about it within the relevant communities I'm targeting with it. (and for those of you who haven't, you have now!).

I made the unfortunate mistake of advertising this proposal just before heading off to Oslo, so I wasn't able to do it justice on the mailing list or write about it here, so, it's probably time to stop, pause, and reflect a bit.

In the days after writing that, I have been approached by a few people pointing out various other good work in a similar vein to this, such as the MeeGo application developer site being spearheaded by Ronan, all of which is great news - it's nice to know that I'm not alone in thinking that we need comprehensive developer help networks set up sooner, rather than later. So the tutorials side of my proposal can probably largely be shifted under the application developer site.

Where does that leave me? I still think that my proposal has value to add - primarily: a human touch. I think that the majority of we hackers are at heart a social bunch (of antisocial individuals, ironically). We don't like answering machines, or being fobbed off with boilerplate answers, and when we have problems, we want to talk to someone about it, and that's where developer engagement can really help go the last mile. We have technical solutions to this (blogs, and whatnot) - but at heart, it's a social issue, and we need to make sure we're fostering and encouraging the right attitude of collaboration and community to help carry the load.

I still don't have the answers to how this is going to fit together, despite a lot of soul searching over my brief time in Oslo, but I hope to schedule an IRC meeting sometime within the next week or two with the energetic bunch of volunteers that I have already picked up to discuss priorities, options, and where we go from here.

The future of the N900, what MeeGo Means!

There's been a lot of chatter recently about the Maemo+Moblin merger, particularly, a lot of fear from N900 owners about the future of their devices, and how MeeGo fits into that. This isn't anything new, I might add - there has been a huge storm on talk.maemo.org the past month about Maemo 6 on the N900. From my perspective at least, this is all fairly ill founded, and I think that a measure of patience and calm is needed.

There isn't a lot of technical reasons why it won't happen with either of them, and with MeeGo at least, it is fully open and community driven, so there should be no *other* obstacles to people teaming up and making it happen. There has already been discussion on #meego about making this happen, and it's only day two!

In the meantime, more updates for Maemo 5 are sure to follow - PR 1.2, the next reasonably sized update is being talked about increasingly on #maemo on freenode, which hopefully means it isn't too far away.

It's very easy to be pessimistic, it's very easy to worry that your device won't be unusable.

Don't take the easy route: fit into the MeeGo community and make things happen.