So Digia released a for-paying-customers-only QML compiler for Qt 5.3.(Link below).

Looking at the state of the compiler internals, an openly developed compiler could be achieved without too much effort. 

My guess as to why Digia made it for-paying-customers-only:

* gives a reason for people to pay (get access to cool stuff first! sort of against the spirit of the FreeQt foundation, but hey, business is business ..)
* it relies on QML internals and you don't want to support that between versions in the open; given all the comments in the sources around data structures and classes that will change "when the old compiler is gone" (referring, I believe, to the QML compiler), I would feel similarly
* it is built with limitations that render it only useful for proprietary applications, esp on mobile platforms; I suspect, though I haven't seen it in action, that it doesn't make sharing compiled units easy (or perhaps even possible) and that it doesn't support compiled-with-QML-sources-as-fallback-in-case-of-arch-or-QML-version-mismatch

I would expect, however, that if Digia doesn't move to open this compiler by Qt 5.4/5.5 that someone will step up and do the obvious work needed to make one everyone can use. I just don't see Plasma Next or Ubuntu Touch suffering slowness forever because they have to parse QML files ... (not to mention potential benefits of avoiding memory fragmentation and faster object access as they could all be laid out contiguously in memory ...)

As a positive side-note, the new in-memory representation of QML and JS objects now that QtQuick uses its own JS runtime makes this rather easy to accomplish.

.. and in case any QML devs are reading this: if QV4::Compiler::JSUnitGenerator::generateUnit took an optional allocator function, then a sizable malloc/free could be saved in QmlUnitGenerator::generate without ruining the generic nature of QV4::Compiler::JSUnitGenerator::generateUnit.