Qt company, don't speak for developers anymore, your managements are totally awful
-
@JKSH Do I understand it correctly that with 5.14 present all following LTS releases, so 5.12.8 and up, won't be available to non-commercial customers? Is that in binaries or source too?
So basically if I'm on open source version and want to stay on LTS I'd have to do the 5.14 -> 5.12 cherry picking on my own? Given the obligations of L(GPL) I would then have to make the result of that process publicly available, so sort of a hand made 5.12.8 of my own. So basically it's gonna be a huge waste of time and multiplication of same effort for the open-source community. Also there's gonna be a few 5.12.8 (and up) versions floating around, all with subtle differences because of independent cherry picking done by people. Is that right or did I got that wrong? -
@JKSH Do I understand it correctly that with 5.14 present all following LTS releases, so 5.12.8 and up, won't be available to non-commercial customers? Is that in binaries or source too?
So basically if I'm on open source version and want to stay on LTS I'd have to do the 5.14 -> 5.12 cherry picking on my own? Given the obligations of L(GPL) I would then have to make the result of that process publicly available, so sort of a hand made 5.12.8 of my own. So basically it's gonna be a huge waste of time and multiplication of same effort for the open-source community. Also there's gonna be a few 5.12.8 (and up) versions floating around, all with subtle differences because of independent cherry picking done by people. Is that right or did I got that wrong?@Chris-Kawa said in Qt company, don't speak for developers anymore, your managements are totally awful:
@JKSH Do I understand it correctly that with 5.14 present all following LTS releases, so 5.12.8 and up, won't be available to non-commercial customers? Is that in binaries or source too?
Not quite. The new process starts with Qt 5.15; FOSS users will continue to get new Qt 5.12 releases until it reaches end-of-life in December 2021. (See https://lists.qt-project.org/pipermail/development/2020-January/038468.html)
So basically if I'm on open source version and want to stay on LTS I'd have to do the 5.14 -> 5.12 cherry picking on my own?
Not for Qt 5.12; yes for Qt 5.15 onwards... after the last public release of Qt 5.15 (I'd imagine we would get an official Qt 5.15.3 or .4 still)
The Qt Company hasn't yet clarified is how the git repo structure will look like when Qt 6.0.0 is released -- this will affect how additional patches land in Qt 5.15.
Given the obligations of L(GPL) I would then have to make the result of that process publicly available, so sort of a hand made 5.12.8 of my own. So basically it's gonna be a huge waste of time and multiplication of same effort for the open-source community. Also there's gonna be a few 5.12.8 (and up) versions floating around, all with subtle differences because of independent cherry picking done by people. Is that right or did I got that wrong?
I believe you're right on the first point: We'd be obliged to make available the source code of self-patched build(s) of Qt that we use to release our app/library.
However, we don't need to (and I sure hope we don't!) give self-patched builds a version number like Qt "5.15.8" and/or publish it as a new release. I believe it's enough to provide, say:
- A .zip/.txz file containing the self-patched Qt code, AND/OR
- A copy of the last official .zip/.txz file plus the .diff file(s) that we've applied.
Having said all that, I'm also hoping that self-applied patches would be few and far between in practice. Let's say we release an app on the official Qt 6.1.3, and then Qt 6.2.0 is released. We can:
- Keep using Qt 6.1.3. It should keep working, after all.
- Roll up to Qt 6.2.0 if it contains a fix/enhancement that improves our app.
- Revert to Qt 6.1.3 if the newer version contains a regression that affects our app, then cherry-pick the patches that improve our app.
- Roll up to 6.2.2 when we know that the regression is gone.
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
I detected some frustration with the decision makers where I work with Qt last year. I have no idea what they will think of this latest announcement.
For myself:
I am just jazzed to be able to code with such a beautiful framework. It saves me a lot of frustration for cross platform work. It is also fun to code. As for the announcement: eh, wait and see. -
@Chris-Kawa said in Qt company, don't speak for developers anymore, your managements are totally awful:
@JKSH Do I understand it correctly that with 5.14 present all following LTS releases, so 5.12.8 and up, won't be available to non-commercial customers? Is that in binaries or source too?
Not quite. The new process starts with Qt 5.15; FOSS users will continue to get new Qt 5.12 releases until it reaches end-of-life in December 2021. (See https://lists.qt-project.org/pipermail/development/2020-January/038468.html)
So basically if I'm on open source version and want to stay on LTS I'd have to do the 5.14 -> 5.12 cherry picking on my own?
Not for Qt 5.12; yes for Qt 5.15 onwards... after the last public release of Qt 5.15 (I'd imagine we would get an official Qt 5.15.3 or .4 still)
The Qt Company hasn't yet clarified is how the git repo structure will look like when Qt 6.0.0 is released -- this will affect how additional patches land in Qt 5.15.
Given the obligations of L(GPL) I would then have to make the result of that process publicly available, so sort of a hand made 5.12.8 of my own. So basically it's gonna be a huge waste of time and multiplication of same effort for the open-source community. Also there's gonna be a few 5.12.8 (and up) versions floating around, all with subtle differences because of independent cherry picking done by people. Is that right or did I got that wrong?
I believe you're right on the first point: We'd be obliged to make available the source code of self-patched build(s) of Qt that we use to release our app/library.
However, we don't need to (and I sure hope we don't!) give self-patched builds a version number like Qt "5.15.8" and/or publish it as a new release. I believe it's enough to provide, say:
- A .zip/.txz file containing the self-patched Qt code, AND/OR
- A copy of the last official .zip/.txz file plus the .diff file(s) that we've applied.
Having said all that, I'm also hoping that self-applied patches would be few and far between in practice. Let's say we release an app on the official Qt 6.1.3, and then Qt 6.2.0 is released. We can:
- Keep using Qt 6.1.3. It should keep working, after all.
- Roll up to Qt 6.2.0 if it contains a fix/enhancement that improves our app.
- Revert to Qt 6.1.3 if the newer version contains a regression that affects our app, then cherry-pick the patches that improve our app.
- Roll up to 6.2.2 when we know that the regression is gone.
@JKSH said in Qt company, don't speak for developers anymore, your managements are totally awful:
The Qt Company hasn't yet clarified is how the git repo structure will look like when Qt 6.0.0 is released -- this will affect how additional patches land in Qt 5.15.
Yeah, I don't like the silence of the lambs. The new terms had enough backlash, yet the introducers don't seem too keen on elaborating or addressing people's concerns (a.k.a the finer details).
@Chris-Kawa said in Qt company, don't speak for developers anymore, your managements are totally awful:
Do I understand it correctly that with 5.14 present all following LTS releases, so 5.12.8 and up, won't be available to non-commercial customers? Is that in binaries or source too?
Both, you're correct in principle, but not for these versions. There's no such thing as LTS for OSS users 5.15 onwards. The QtC never actually clarified if they're going to support 5.15 long enough, so it's feasible to jump to Qt 6, though ... so nobody really knows if 5.15 is LTS (old style) or just a regular release. In the latter case ... well you can imagine the implications ...
So basically if I'm on open source version and want to stay on LTS I'd have to do the 5.14 -> 5.12 cherry picking on my own?
If we grant substituting the version numbers, yes, you do.
Given the obligations of L(GPL) I would then have to make the result of that process publicly available, so sort of a hand made 5.12.8 of my own. So basically it's gonna be a huge waste of time and multiplication of same effort for the open-source community.
Correct and on point. Sales don't care about community though, they care about money.
Also there's gonna be a few 5.12.8 (and up) versions floating around, all with subtle differences because of independent cherry picking done by people. Is that right or did I got that wrong?
Not 5.12.x, but it may happen for 5.15+ If 5.15 isn't a real LTS (which we don't know really) then I'm pretty sure the KDE folks (at the very least) have to backport stuff from Qt 6 until they're able to switch over to the next major. Which as you can imagine is a big pain in the ass and an enormous effort.
@Chris-Kawa said in Qt company, don't speak for developers anymore, your managements are totally awful:
Sure, it could be interesting. The big points in the announcements are: login requirement, offline installer commercial-only, LTS commercial only and new startup offer. My personal opinion on those: first - very annoying, second - I don't use it so don't care, third - awful and the last one again doesn't apply to me so I don't care.
I vote on:
First - Complete nonsense
Second - *shrug* annoying, but okay
Third - If you want to shoot yourself in the foot, that's one way to do it. Less testing on LTS meaning even the paying customers don't get the free testing, and/or patches. Bugs that don't appear in later implementations aren't at all going to be seen or fixed, or backported by the OSS people, so you're stuck with QtC's guys, if they can spare the time that is.
Fourth - Stillborn, completely underthought and practically inapplicableRead and abide by the Qt Code of Conduct
-
@JKSH said in Qt company, don't speak for developers anymore, your managements are totally awful:
The Qt Company hasn't yet clarified is how the git repo structure will look like when Qt 6.0.0 is released -- this will affect how additional patches land in Qt 5.15.
Yeah, I don't like the silence of the lambs. The new terms had enough backlash, yet the introducers don't seem too keen on elaborating or addressing people's concerns (a.k.a the finer details).
@Chris-Kawa said in Qt company, don't speak for developers anymore, your managements are totally awful:
Do I understand it correctly that with 5.14 present all following LTS releases, so 5.12.8 and up, won't be available to non-commercial customers? Is that in binaries or source too?
Both, you're correct in principle, but not for these versions. There's no such thing as LTS for OSS users 5.15 onwards. The QtC never actually clarified if they're going to support 5.15 long enough, so it's feasible to jump to Qt 6, though ... so nobody really knows if 5.15 is LTS (old style) or just a regular release. In the latter case ... well you can imagine the implications ...
So basically if I'm on open source version and want to stay on LTS I'd have to do the 5.14 -> 5.12 cherry picking on my own?
If we grant substituting the version numbers, yes, you do.
Given the obligations of L(GPL) I would then have to make the result of that process publicly available, so sort of a hand made 5.12.8 of my own. So basically it's gonna be a huge waste of time and multiplication of same effort for the open-source community.
Correct and on point. Sales don't care about community though, they care about money.
Also there's gonna be a few 5.12.8 (and up) versions floating around, all with subtle differences because of independent cherry picking done by people. Is that right or did I got that wrong?
Not 5.12.x, but it may happen for 5.15+ If 5.15 isn't a real LTS (which we don't know really) then I'm pretty sure the KDE folks (at the very least) have to backport stuff from Qt 6 until they're able to switch over to the next major. Which as you can imagine is a big pain in the ass and an enormous effort.
@Chris-Kawa said in Qt company, don't speak for developers anymore, your managements are totally awful:
Sure, it could be interesting. The big points in the announcements are: login requirement, offline installer commercial-only, LTS commercial only and new startup offer. My personal opinion on those: first - very annoying, second - I don't use it so don't care, third - awful and the last one again doesn't apply to me so I don't care.
I vote on:
First - Complete nonsense
Second - *shrug* annoying, but okay
Third - If you want to shoot yourself in the foot, that's one way to do it. Less testing on LTS meaning even the paying customers don't get the free testing, and/or patches. Bugs that don't appear in later implementations aren't at all going to be seen or fixed, or backported by the OSS people, so you're stuck with QtC's guys, if they can spare the time that is.
Fourth - Stillborn, completely underthought and practically inapplicable@kshegunov Things become worse and worst.
“the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice.”
Please check this mailing list out, and how the Qt company response to the voices of the developers, their real customers.
Talk to the company? Useless, they erase everything they don't like to hear, those managers never understand we developers are their real customers, none of the company will buy for a technology do not deserve any love from the developers.
-
@tham said in Qt company, don't speak for developers anymore, your managements are totally awful:
@kshegunov Things become worse and worst.
“the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice.”
Please check this mailing list out, and how the Qt company response to the voices of the developers, their real customers.
Yes, I'm aware of the mail and the succinct blogpost, which is phrased in such a way that it basically means very little. Note how much the words sound like something that came out of a politician's mouth - talk a lot, say (almost) nothing.
Talk to the company?
It's been attempted on a couple of occasions on the interest/dev mailing list. The only person that had any decency to comment in his official capacity, as far as I can tell, was Tuukka and no firm statement was provided. "Talk to your lawyer" appears to be the company line, whereas many valid questions, as @Chris-Kawa's for example, went unanswered.
Useless, they erase everything they don't like to hear, those managers never understand we developers are their real customers, none of the company will buy for a technology do not deserve any love from the developers.
What can I say ... that I'm happy with the way the QtC's been acting would be to lie shamelessly. They aren't the devil, but such frustrating behavior can very well be their own undoing. I don't know who was personally behind these decisions, and I wouldn't care too much anyway, I'm not on a witch hunt. But my personal opinion is these late actions seem to be disconnected from the reality of the situation; the OSS users and contributors aren't objects to be disposed of lightheartedly. Moreover while the major burden of development is on the QtC, and that can't be ignored, and also they need to make money to survive, there is influx of outside code and I'm sure the people that contribute that code are not at all happy with the new status quo. (... and "I'm sure" is used here just as the polite way of saying "I know that for a fact" ...)
-
About the only thing I like regarding the OSS license scheme is that it allows whoever wants to fork the project and make their own product. If Qt folks are not meeting the needs then do the fork. Call it "Qu" (the letter after t), and let the chips fall where they may as to who has the better product in a couple of years.
-
About the only thing I like regarding the OSS license scheme is that it allows whoever wants to fork the project and make their own product. If Qt folks are not meeting the needs then do the fork. Call it "Qu" (the letter after t), and let the chips fall where they may as to who has the better product in a couple of years.
@Kent-Dorfman said in Qt company, don't speak for developers anymore, your managements are totally awful:
About the only thing I like regarding the OSS license scheme is that it allows whoever wants to fork the project and make their own product. If Qt folks are not meeting the needs then do the fork. Call it "Qu" (the letter after t), and let the chips fall where they may as to who has the better product in a couple of years.
This isn't free (and I don't mean moneywise), as very much of anything in this world. It was suggested/predicted to happen, but the point is that in such a scenario everybody loses ...
Read and abide by the Qt Code of Conduct
-
@Kent-Dorfman said in Qt company, don't speak for developers anymore, your managements are totally awful:
About the only thing I like regarding the OSS license scheme is that it allows whoever wants to fork the project and make their own product. If Qt folks are not meeting the needs then do the fork. Call it "Qu" (the letter after t), and let the chips fall where they may as to who has the better product in a couple of years.
This isn't free (and I don't mean moneywise), as very much of anything in this world. It was suggested/predicted to happen, but the point is that in such a scenario everybody loses ...
@kshegunov It happens already, Qt company made many stupid decisions before, but none of them can compare with this one, this is the stupidest one, and I believe they will commit more stupid decisions in the future, just wait
-
@kshegunov It happens already, Qt company made many stupid decisions before, but none of them can compare with this one, this is the stupidest one, and I believe they will commit more stupid decisions in the future, just wait
