A couple of questions for my dear Qt friends: after a long winter, mostly devoted to building and deploying HTML5 games and educational apps, I find myself evaluating Qt again for a big project… It is an app to be used on schools: it must work online and partly offline as well. And it has to run on desktops (Linux/Win) and mobile (Android/iOS).

HTML5 apps have evolved a lot. We built very interesting collaborative things using it, and the team is already familiar with backbone.js and other goodies. But the requirement that part of the funcionality must be available offline is puzzling me for this particular project. HTML5 offline support will not cut it, as data to enable the features we need is not something that fits in the typical localstorage cache solution. So I was thinking about using something like Apache Cordova (previously phonegap) and its sqlite plugin. The thing is that I would very much wanted a single code base…

The research lead to interesting new projects, like node-webkit and chromium embedding framework. All have pros and cons, and none runs on all platforms we need to support.

And then yesterday I found that ICS was working on cordova-qt. So maybe it is possible to build such an app (HTML5 based with local fs support) and really deploy it worldwide from a single codebase? Apparently, not yet… the project appears to be a bit stale. Does anyone know why? Perhaps the announcement that Digia will work on native iOS and Android versions of Qt has made this a lower priority? It would be nice to use a C++ app with QtWebKit, but IIUIC this does not work for iOS and Android, so back to square one, right? Comments are welcome!

Back in 2005, my small company had an active customer base of more than 15,000 developers using our plugins. These were extensions (Xtras) for Macromedia Director, at the time the number one tool for authoring of CD-ROM and online games published via Shockwave. The global Director developers community was composed of 300,000+ professionals, not counting the illegal copies. Sure, Flash (also from Macromedia) was starting to become a powerhouse and was competing strongly with its older brother. But development of both software continued at a healthy pace, and the collaboration between both teams resulted in the opportunity to use Director as a container for Flash media, with a bright outlook for both. Director was still the tool of choice for 3D games, kiosks, CD-ROMS and lots of projects where the ability to extend the environment with C++ code was required, with embedded Flash elements providing the eye candy and an army of designers that were used to the platform.
Then Elop was elected CEO of Macromedia. And some months later, the company was sold to Adobe. A nice and stable transition was assured at the time. Director was not to be killed, like Freehand and some others. And it fact it wasn’t. The Director product team had a good channel of communication with the community at the time, and from them we were told that several options were being considered for the future, we just had to wait a bit for the dust to settle.
Looking back, it would have been better if the product was sold to another company, or it Adobe management had clearly stated from the start that no significant updates were planned. Instead, Director remained alive at Adobe as a cash cow, with a reduced team that was strangled slowly, always waiting for better news “in the near future”. It was planned obsolescence, and it continues until today: there were sporadic releases (to reap the upgrade fees) and this helped keep some content created in Director still alive. Nowadays the developer community consists mostly of old timers who are maintaining their legacy projects, and struggling against an aging code base that is minimally supported. There were more than 40 companies producing Xtras for Director circa 2002, and from these only 1 or 2 (including ours) is still active. This is mostly out of respect to the existing customers and the investment they have made on the “ecosystem”, as keeping this business alive (support and minimal maintenance costs) is something that has not generated a profit for me in the last two years.

So I was not happy to see Elop (after graduating from Adobe and Microsoft, which surely increased his business “skills”) took over the role of Nokia CEO. Oh, oh… spider sense ticked off. Luckily, the other shoe dropped almost as quickly, also in a matter of months, as we all know by now.

There is, however, a significant distinction between both scenarios. Director was never free software. There was no option: some from the community even tried the only possible route, which was to acquire the product, but Adobe did not want to let it go, probably out of fear that it will compete strongly again with Flash. So the “strangling” of the community succeeded. Qt, on the other hand, is free software. And KDE has also secured the FreeQt agreement. So, thanks to the L(GPL) and the efforts of the community, there is a way out.

I read several blogs asking for restrain and calling a fork “premature”. I respect those opinions, but having lived through a previous elopcalypse, I beg to differ. A small part of me hopes I am wrong, but I believe a fork is not only necessary, but inevitable. And I think KDE is the place where this fork should live, with kdelibs and qt forming an unified platform where truly free (in license, cost and development direction) software can be built. Everyone knows the problems KDE developers and the community have with their patches being integrated in Qt.: with a Qt tree living inside KDE we would be free to apply true open source principles to the development, and let it thrive in the way our software has. I understand Qt Software inside Nokia is implementing open governance and all, and I trust the people in charge of this initiative. But again, their power is limited. I respectfully must say that any initiative led by Nokia or their employees will never be truly open in the sense KDE is. And the axe might fall again in a couple of months, and then again. And the good people will be gone. Qt developers would have migrated to another environments. And the opportunity will be lost.

Some will say: but then we will loose the Nokia-sponsored development. This is true. But these are already gone, or will be gone soon, IMHO.

Well, we can check this in 2 years, and I will certainly buy a round of beer to everyone at the 2013 Desktop Summit if I am wrong. In fact, I will be happy to do so, and I would be happy to be wrong as it would mean less work for KDE. But I got tired of the “calm down” posts. Putting it in blunt words, we can no longer trust Nokia or depend on it for the core framework KDE needs. Even if most Nokians are very good guys, brilliant engineers and a joy to work with, the new management has shown its true face. Two months ago they were drafting developers in Dublin for Meego, and some people dedicated their time and resources to support the Qt-everywhere promise. This commitment has been broken, and it will not be the first one. Reading the join press release (Elop and Ballmer, come on) feels like an April’s Fool joke, honestly. Just stare at the photo for a while. We can not expect any FLOSS love from these guys, sorry. Like KDE, Meego is hurt, but it can also recover if Qt moves to a truly open upstream repository. Qt, imho, can no longer be controlled by Nokia: development has to happen in the open and be governed like a true community project, like KDE. I can imagine that such a move would make other Meego players happier as well.