Websoup

After a short historical overview and a short list of growing pains, in this, third installment of the mobile Qt app story, I will focus on what boulders remain in the path of widespread adoption of Qt among app mobile developers. Most of the technical groundwork has been laid down, but to reach a final resolution, it needs to include a bit more than just a healthy base.


Decouple Qt releases from firmware releases

As seen from the infamous PR1.2 delay, a coupled-with-the-firmware release cycle is detrimental to the platform. If multiple devices are on the market, it would mean instant-fragmentation as developers would have to code for the Qt released with the last firmware. This is eating Android alive, too, as various handsets have different upgrade cycles. A separate distribution mechanism HAS to be employed. It will be tricky as with MeeGo and Symbian^4 Qt is part of the OS and many teams will be reluctant to bet firmware functionality on the backward compatibility of Qt. But that is not the only thing that can cause fragmentation if it isn't true that...

One mobile widget framework is enough


I harp about this regularly (and will continue to do so until I get good news from an official source :), the option to have separate widget frameworks for Symbian (Orbit/uiemo) and MeeGo (DirectUI/MeeGo Touch Framework) is something that is completely against what Qt is trying to accomplish by bridging the two OS-es. 

All you bases are belong to us

Qt is almost a country of it's own, addressing (or having a development version that addresses) various aspects of software development, both mobile and desktop. However, there is one thing where it is sorely lacking - the wizz-bang games department. Yes, QGraphicsView and 3D enablers are cool and all, but that is not enough (even with QML and UI scripting). It would certainly be an overkill and unnecessary delay to implement a complete game engine in Qt, but there are alternatives - make a Unity3D port, or, better yet, in the spirit of open source, sponsor Ogre binding (and GLES) development for Qt, with the necessary physics libs.

Build it and they will come - Ovi and devices

Professional mobile developers can and will materialize only after the market for the Qt apps materializes. The prerequisite for this is that Qt gets a first-class treatment in the Ovi store, and the QA process is not a hit-and-miss, something that developers are guessing about. Once the Ovi store really starts accepting Qt apps en masse, the question turns into how many devices can be targeted via Qt. I can hear you say "well that's like almost all Symbian handsets in the last 2-3 years". Yeah, but... 


Market share is not necessarily mindshare

Devices that can be retrofitted with Qt already exist in the (tens of) millions range. However, these devices are mostly low to midrange devices as there were no runaway Symbian successes in the high-end segment for a while now. It will be hard to convince people to target a market, no matter how objectively big if they believe/see it as a relic, which means... 

You've got to be cool

The vehicles for the Qt platform need to be cool and carriers of high tech. This is the wave Android is riding in 2010. Now, the best way to do this is having iconic devices (iPhone killers if you wish), but this is not ONLY about devices, it's about how you handle your technology in general, your devs, your community, blogs and everything related to it. Qt has to be perceived cool, a must-have even by non-tech people, not just a sticker on the corner of a box and something geeks nod over on irc. It IS the differentiating factor. Take for example the happenings of last week in the Nokia N900 land. A triple-release is done - preview of the Qt Web Runtime, a new version of Qt Mobility and the super-cool fcamera project. This triplet just oozes with tech-cool demo potential, but it just isn't leveraged, hardly getting even a blog post. Instead there is a campaign and an 'exciting news' about Ovi doing a comic (I'm sure it will be good, but... ). This points to comms issues, but also lack of

Communication/Community Focus

While I don't know how many different communities and aspects of Qt should there addressed separately, I'm pretty sure we are already overloaded, even before the hordes of the new Qt developer generations emerge. There is the Qt Developer Network, then we have Forum Nokia (home of the Nokia Qt SDK), followed by a more specific MeeGo community that is vested (well, at least the handset variant) in Qt, and the same will be true for Symbian. OTOH If you want to publish/talk about Qt development on currently available devices, you should go to maemo.org. While in community waters, we should also mention Qt Centre. Quite a handful of forums, mailing lists and irc channels to follow, and I have not even talked about communities focused squarely at end-users ! Speaking of end-users, some people who even knew about those Qt/fcam releases I mentioned above were quite discontent, because there is/was no concept of...

Control and drive expectations

The 'other' platforms and ecosystem have built up and trained users to expect certain things in a certain way, and if they are not educated, they will not understand what is going on and will easily dismiss even good news when it is not is a form they expect it in. See the above - new releases of QtMobility, WRT, etc were not treated by many as real news or support by Nokia for the N900, even though they were done by official Nokia teams. The concept of the 'holy firmware release' is still strong, because people don't understand the concept of libraries and components (as that is not how most other platforms operate).


Those would be my major points, and while they might sound a bit grim (some not even related to Qt itself), I don't think they are insurmountable at all, it just takes a little effort (some already underway) and presto, the arid Qt mobile app landscape can bloom like a savanna after a rain.