[Interest] Qt free software policy
roland at logikalsolutions.com
Thu Aug 22 17:21:26 CEST 2019
On 8/22/19 5:00 AM, James Ross-Smith wrote:
> This a quite a timely thread, as I, like several others in here, am trying
> to decide on a Commercial or non-Commercial licensing approach with Qt.
> I've submitted numerous contact/quote/trial requests on the TQtC website
> over the last couple of weeks but never hear back, so it's very helpful to
> stumble across this discussion.
You are welcome. We do try to be of assistance in here.
To answer the other question I didn't cut and paste . . . For whatever
reason Qt Company didn't follow the Cannonical (Ubuntu) model. The
ex-wife alimony fixation on royalties makes me believe they have a whole
lot of Dire Straights Syndrome going on.
While it was a great tune, it was not a good business model.
I just finished up at a client site where commercial license was
purchased. I wasn't there or it never would have happened as they
certainly had no need for the "latest" anything. Be that as it may, the
negotiations started and happened many states away.
The way our "support" was explained to me by our boss was this (it might
be different for every negotiation):
"If we have trouble with installation of the development software,
configuration of the development environment or cross compiling for the
target system we can call and get help right away. If we find a bug we
have to file a bug report and get in the queue with everyone else."
When someone mentions "software support" a large chunk of the industry,
especially those of us who are older and have worked on large systems
from Digital Equipment Corporation, Oracle, IBM, etc., we expect a
sev-level escalation tree. You start somewhere down at the 4 or 5 level
(normally the bottom) and unresolved problems keep getting kicked up the
tree until it becomes a sev-1 (it can start at sev-1 if you have a
complete production outage). At sev-1 the vendor assembles a trauma-1
team which generally includes one or more of the developers who actually
developed the particular piece of hardware or software which is suspect.
Mileage may vary, but that has not been my experience in the Qt world. I
believe that is partially due to the distributed (OpenSource) nature of
the development. There are big chunks of Qt which Qt Company had
basically nothing to do with. I'm thinking the 3-D stuff might be a good
example given a message thread on this list from some months back. A
company of some size, be it one or more, developed the package and
donated some or all of it to the community. Unless Qt Company was to pay
that company for sev-level support, how could Qt Company ever provide
support for it? Sure, coders who never wrote any of it could dig through
the code and hopefully find something, but that's not exactly the level
of support one thinks of when they hear "support contract."
A much larger part of the issue has been, in my opinion, not
sufficiently pursuing a large embedded systems consulting group. I'm
talking about an embedded system in a box type consulting company where
they could do project level stuff from hardware design all the way
through setting up factory production. When people "went to the bench"
they would be working on Qt itself and providing support. This is how
the old, successful, companies did it. Albeit they were working on
mid-range and mainframe systems at the time.
The "device in a box" type companies are growing at alarming rates. Once
they bring in the correct heavy hitters (both high architectural level
and low firmware/algorithm level) they go from startup to nearly
$20Million in just a couple of years. The one problem all of them seem
to have is pursuing 100% billable time for all employees. If you are a
100% billable you are 100% failure, it just may take you a while to
realize it. Really successful ones rarely exceed 60% billable for a
year. Skills enhancement. Pre and post sales customer hand holding.
Numerous things which must happen aren't billable. If you are 100%
billable then you aren't doing those things. Employees will only learn
new skills on their own time and at their own expense for a short while.
Where Qt Company could thrive here is focusing on "no more than 60%
billable" with the rest of the time spent on Qt bug fixes, support and
new Qt development. What they would gain is an actual industry
perspective, not one which was created from reading surveys with an
agenda so their outcome was predetermined.
From that real world perspective they would learn the reality of things
which have been asked for by others in this mailing list for a very long
time and some new ones.
1) Compilation method which removes 100% of QML, including QML support
from non-QML classes.
While my correct views of QML are widely known, the reality is that many
embedded and IoT systems have no UI or correctly choose not to use QML
because they are running on battery without a GPU. Unless these systems
fall back to a pre-QML version of Qt, they cannot get rid of the buggy
2) A TCP/IP Software Appliance
Currently there is no standard for this but there is growing realization
in the IT industry (at least at the big company level) that *nix did it
wrong. Allowing applications to directly open ports and saddling them
with transport level security was a massively short sighted (AGILE?)
decision. It's lead to basically non-existent security at pretty much
every place handling any form of financial transaction. By the time
something is found and fixed they are already a
Target/Equifax/insert-favorite-headline-here level breach in the news.
ALL of the transport level security including the assignment of ports
must be handled by the OS level appliance. The application just opens a
file level interface with a name it is assigned by a system manager. The
system manager is free to change at will the transport level security
for one or all applications allowed to communicate.
DEC started on this back in the late 80s early 90s then followed down
the misguided *nix path. Some are working on it again. The final
solution will be something which can run on IBM Z/OS, MVS, OS/400, AIX;
HP OpenVMS, UX; TANDEM; whatever Unisys is still using including what
they run on their check processing machines, as well as the little x86
based *nix and Windows operating systems. It may not be the same code
cross compiled but it will have much the same interface and all of the
This is coming. There have been too many multi-billion dollar breaches
and you can't keep putting bandages on a patient bleeding from the jugular.
Could this solution be Qt based? First the core of Qt would have to be
ported to all of those platforms. Running on *nix and Windows alone
would make such a solution the new Microsoft Zune. At the very least
today's design decisions have to include the architectural reality that
applications very soon will not be allowed to perform their own TCP/IP
communications. For the FDA regulated world we've been moving to
Comm-Modules for a while. A plug-in hardware device which has some form
of on-board serial or BUS API. We communicate with it and how it
communicates with the outside world we simply do not care.
This same level of separation is about to be imposed on everything
handling financial transactions, including those "shopping apps" on phones.
Ah well, you get the idea.
To get back to your original question, how could they provide the level
of support most people think of when they hear "support contract"? They
don't have that massive consulting branch and even if they did Qt
Company didn't write huge chunks of Qt. True, they could bring in a
bunch of low level "chip head" developer types.
I'm talking here about people who like to look through MOC output and
code at the firmware level. Thiago seems to still be at that stage of
career. I'm not that young any more and my days of writing device
drivers in assembler are behind me. Prefer the architectural level now.
Architectural level is great for designing and developing a rock solid
system, not so good for finding a bug buried deep in third party code
which may have been exposed by some pre-compiler path. For that you need
a chip head who likes the deep dives. Yes, I've worked with guys older
than me who still do and love that, but I just couldn't stay at that
level. It wasn't fun for me.
Providing sev-level support would require a _very_ deep bench and in
reality would require people who have worked with every Qt package.
Unless I end up taking this bone imaging device contract, I will
probably never work with the 3-D package. I've worked on CAN-BUS systems
before but never used the Qt CAN-BUS stuff because there was already
some other CAN-BUS code in use. There are probably big new packages in
Qt I know nothing about because they aren't relevant to my universe. The
same can most likely be said for everyone here.
No. To get the kind of support one would inherently envision when they
purchase a "support contract" Qt would have to be proprietary with 100%
of the development in-house OR Qt Company (they are currently called
Qt Company arent' they? I've lost track of the name changes) would have
to have a massive consulting wing/division (thousands, not hundreds) who
were all heavy hitters splitting their time between client projects, Qt
development and Qt support.
What we currently have in the market place is hundreds (perhaps
thousands?) of 1+ person companies claiming to be "Qt Experts!" when, at
best that is disingenuous. Qt has become so unwieldy with so many
packages nobody can be an expert. You can be really awesome at some
subset in a tiny market niche but you can't be an expert with all of it.
Seriously, that is a loooong list. When a company contacts "Qt Experts!"
they aren't going to be willing to pay for you to learn on the job. Most
of them won't even pay their employees to do that.
Roland Hughes, President
More information about the Interest