Qt 5.15 LTS Support Extended An Additional Two Years - For Their Paying Subscribers

[bug77]

It attracts attention, entices users to follow that link and engage in discussions.

So does every tabloid or troll.

[quaz0r]

copper spice

[Vistaus]

copper spice

is full of lies

[yurikoles]

Is QT6 out of beta yet?

“QT“ stands for QuickTime, 6.0 released July 15, 2002.

[DanL]

That's embarrassing for a multi-million dollar company.

Not a single one of them thought, "Gee, we should right click 'EoS' and add that to our internal dictionary so our chart doesn't make us look like a bunch of doofuses who leave typos all over the place."

Meh, it gets the point across and the red underlines kind of fit in with the End of Support thing (red=danger/alert). I'd rather have them worrying about making Qt as good as can be instead of fluffy marketing images, Don't judge things strictly based on appearances. (See space shuttle Challenger for classic case study of this effect.)

[tildearrow]

is full of lies

and was originally based on Qt4 - zero HiDPI support

[skeevy420]

Meh, it gets the point across and the red underlines kind of fit in with the End of Support thing (red=danger/alert). I'd rather have them worrying about making Qt as good as can be instead of fluffy marketing images, Don't judge things strictly based on appearances. (See space shuttle Challenger for classic case study of this effect.)

You clearly didn't go to their page. If you did, you didn't realize that they corrected EoS on their other images. Just not the first image that's front and center. All I'm saying is that a multi-million dollar company full of nothing but mainly college graduates should have caught those editing mistakes.




Look, it's not like they're Phoronix relying on a single person to do the reporting, editing, content generation, fact checking, tests, and more. That doesn't even include the back-end roles required to manage a small business.

That's why most of us here have no problems pointing out typos, especially the funnier ones. Not to mention that a lifetime of Phoronix costs 1/3 the one month of Qt. I'll let Michael slide. Greedy ass Qt company? Hells to the naw.




Paraphrased, that's:

"I know you're dealing with a Qt issue, but In addition to tech support I'm also a salesman and noticed you're using an older Qt version. Instead of helping you I have to put your support ticket on hold while you talk to an account manager to upsell you to a newer Qt version. Also, today is blackface day."

Why do they think that's a good graphic?

And the conversation after that call between the Manager and Salesperson:

"Sucks we can't tell them it's fixed with the KDE Qt 5 Patch Collection."

"Yeah, but then we'd be out of a job. Those freeloading FOSS people steal 4 Billion a year in revenue from us."

[Luke]

So long as QT does not take down the repos containing older versions and doesn't move development off the current (as in QT6 right now) public repo to a private repo, the issue is not whether they are still offering their traditional free and open source code, but whether or not having done so obligates the same devs to get on a treadmill of producing more and more product and doing more and more work whether they need it for their own projects or not. Of course a project that chooses to reject community contributions and become one customer's "kept" project can be forked and sometimes that fork becomes the dominant version.

Software itself (as in a single published version known to work on a single known set of underlying libraries) is a product not a service and renting it out (think Office 365) is crap, but software maintainance sure as hell is a service. This is true whether in a "gift economy" where people fix the bugs that bother their own systems, publish them for others to use, and use others' bugfixes in return, a capitalist economy where all users of a closed proprietary program pay a single team of paid programmers to fix all their issues, or something in between. A FOSS project with a one or more big paying customers is in between. Beer may not brew itself out of thin air, but there is more than one economic system capable of brewing it.

Having worked on software myself (MATE) I have "seen with my own hands" what it takes to apply bugfixes from the master/main/dev branch to older versions. Some commits will apply clean as cherrypicks ,then build and run fine. More may apply clean, but then have build or runtime issues and require porting. Finally there are those that generate a merge conflict requiring manual resolution. Note that anyone who can make git (or whatever a project uses for version control) work and compile software can clone the repo and do simple cherrypicks themselves.

Best case for a FOSS project is as the use of a project grows, the percentage of users "paying" in time and effort rather than in money does not drop.In that case, the team grows with the project and things stay on track. LTS versions needed by distros get help from those distros, so the bottlenecks are at the development and approval of new code and not at fixing bugs in old code. This is a healthy and fully free project, in which the "beer" is kept free by many hands in the brewery. With many working on it, the effort is spread over the full spectrum of issues, bugs, and potential new features. This is something the paid model will have trouble matching.

Next up is a "hybrid" model: the project had grown too big and widely used for the original authors to maintain by themselves, but one or more of the users (think Red Hat) have paying customers of their own, either for prebuilt packages, support, or both. This downstream project (often a distro) contributes either programmers they have already hired, or simply contributes funds to hire one or more programmers. These hired hands can start chewing through the production line work of backporting bugfixes, reviewing PR's and writing fixes for the sort of bugs that tend to get ignored otherwise. This frees up the original team to work on the core of the project and not get stuck on a treadmill of maintaining multiple older releases. A little of this can go a long way. Note that the speedup this brings will focus on the needs of that paying distro.

Last is the model where most of the work is paid in money, in other words that most of the exchange of value between users and programmers passes through money and the economy. This has "frictional" lossses such as that money being taxed, and those who are paying the piper may even more be able to call the tune. So long as the code itself is still developed in the open, again anyone can build from the main/master/dev branch, and anyone can backport fixes themselves. This may lead to duplicated effort, with the same bugfixes being backported, say once in private by QT and a second time in public by KDE, with the code thus beginning to diverge. A closed project is if the source code is not published at all or is published after the binaries have been in use a while.

[Luke]

Unapproved so here's a summary:

So long as QT does not take down the repos containing older versions and doesn't move development off the current (as in QT6 right now) public repo to a private repo, the issue is not whether they are still offering their traditional free and open source code, but whether or not having done so obligates the same devs to get on a treadmill of producing more and more product

Software itself (as in a single published version known to work on a single known set of underlying libraries) is a product not a service and renting it out (think Office 365) is crap, but software maintainance sure as hell is a service. This is true whether in a "gift economy" where people fix the bugs that bother their own systems, publish them for others to use, and use others' bugfixes in return, a capitalist economy where all users of a closed proprietary program pay a single team of paid programmers to fix all their issues, or something in between. A FOSS project with a one or more big paying customers is in between. Beer may not brew itself out of thin air, but there is more than one economic system capable of brewing it.