Qt, Open Source and corona

[Michael Rochefort]

Hopefully this email is put in the chain as intended, if not, my apologies.

On Thu Apr 9 10:01:48 BST 2020 Boudewijn Rempt wrote:
> * There needs to be a mailing list or two
> * There needs to be a system like gerrit or gitlab to host development
> * There needs to be CI -- the Qt project has its own thing for that, COIN.
> * There needs to be a website
> * There needs to be a committee or a way of making decisions: what to keep, what to drop, how to handle relations with the Qt company, how to release, whether Qt6 still makes sense, or whether Qt5 should be developed for the next decade...

The last point in particular is something I'm not seeing mentioned as much here. Part of the reason for using Qt is not just for the flexibility of its GUI system, but the underlying stack framework it provides. That, paired with the fact that it works reasonably well on the major platforms it supports, e.g. Windows, macOS, and Linux for the desktop space, makes it a very useful tool for creating consistently behaving cross platform applications. The discussions I've seen so far, and that's probably due to the user base here, seem to be focused on just the KDE and Linux community's needs. However, in the situation of a fork, would the community be willing to support the other platforms?

Paul posted a bit of what I was talking to him about (thanks for that!), but I would like to expand upon it further. In our industry (feature VFX and animation) Qt has a significant role in the tools we make. Autodesk uses it for Maya and 3DS Max; Foundry uses it for Nuke, Mari, Katana, and I think they're transitioning Modo to it; SideFX uses it for Houdini; pretty much every in-house studio tool with a GUI is Qt based (or otherwise written in OpenGL), and a myriad of other products use Qt. Marcus Ottosson authored Qt.py[0], which is a "Minimal Python 2 & 3 shim around all Qt bindings - PySide, PySide2, PyQt4 and PyQt5" which has been helpful with transitions in our industry in accordance with our VFX Reference Platform[1]. Autodesk releases the source code for Qt and any of their modifications. Based on the Houdini docs[2], SideFX seems to be using the LGPL variant of Qt, though their built header files distributed have the commercial/LGPL/GPL statements in them (same with Autodesk). I'm not super familiar with building Qt itself as I'm not a dev so I don't know if that's to be expected. And as an industry we typically stick to LTS releases, which is going to be changing for the free edition of Qt with 5.15...

When I heard about the forking possibility, here's what ran through my head first:

What kind of impact would a fork have on the ecosystem community if there is a significant divergence from the commercial offering? Would the community be up for maintaining their own Qt for Python (or other language) bindings and documentation? What about groups that write plugin tools for other host applications that use the commercial offering but also have their own open-source standalone application? What impact will this have on the agreement between the KDE Foundation and the Qt Company? What resources do we actually have to support the huge multi-platform offering that is Qt?

There are a lot of questions that a fork opens up and not a lot of answers right now as it's all unknown. I think laying out a plan for a potential community fork is a smart move considering the Qt Company's recent behavior, even if a fork is the least desirable option. However, I think determining fundamental resources, specifically developers willing to partake in this venture is the first step that needs to happen. Then working on the base goals of the project with those resources in mind to decide what is feasible and a priority to support. Determining CI/hosting/naming, to me, are more after-the-fact details that do matter but don't accomplish or mean much unless the previous points are solved.

Hopefully this all makes some form of sense :)

Cheers,
Mike

[0] https://www.github.com/mottosso/Qt.py
[1] https://vfxplatform.com
[2] https://www.sidefx.com/docs/houdini/licenses/index.html