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.

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*.