[Interest] Qt free software policy

[Roland Hughes]

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.

https://www.youtube.com/watch?v=JRDgihVDEko

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 
baggage.

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 
same functionality.

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.

https://doc.qt.io/qt-5/qtmodules.html

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
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com