[Interest] Qt free software policy

Fri Aug 23 15:06:51 CEST 2019

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.

If you design your software right nothing in Qml should be seen into your C++ except the module registration. Your C++ code expose to the meta object with properties and signal and that's about it.Qml use the meta exposition, you can still use the meta calls without Qml. This is one thing I really like about Qml, it doesn't invade the application code, it sit above it and you can use the javascript for view model adaptor/converter. I have give up on QWidget and looking at my code base now I would not go back, the automatic binding re evaluation is such a connect() call saver. 

-----Original Message-----
From: Interest <interest-bounces at qt-project.org> On Behalf Of Roland Hughes
Sent: August 22, 2019 11:21 AM
To: interest at qt-project.org
Subject: Re: [Interest] Qt free software policy

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

_______________________________________________
Interest mailing list
Interest at qt-project.org
https://lists.qt-project.org/listinfo/interest