Qt company, don't speak for developers anymore, your managements are totally awful



  • Look at the mess of this annoucement cause.

    How could Qt company business going well without understand, listening to the voices of developers? The last time Qt company earn profit is 2015.

    You tried so many things, develop so many new features, yet you refuse to hear the sounds of developers, you should open a vote to collect the opinions of the programmers after so many years of failures to earn profit, you should know that Qt is a framework, a tool design for developers, not those business guys or the CEO. They suck, no profit since 2015 prove this, the results tell you you are heading to the wrong direction, this is very obvious, why are you still so damn arrogant are refuse to listen to the opinions of your customers, the developers?

    Developers are the one who really using and care about this library, this framework, not those business guys, the managers are totally incompetence if they still believe those business guys who don't know software(or who knows a bit of them but don't have any passions of software) but money only rather than listen to the opinions of their real customers, the developers.

    When the other's big players, new comers are trying to attract more developers, you are trying your best to push them away in order to squeeze more money from existing developers, this is a sign of backrupt, it looks like you are struggle desperately


  • Moderators

    Though I'm not happy about the announcement either I think you're venting your frustration at the wrong people. This forum is mostly run/visited by developers, and only a few of them associated with the Qt Company.



  • @Chris-Kawa This is fine. Even they can see it, I don't expect they would change their mind, their decisions of these years already show us they only care about how to squeeze more money out from the pocket of developers, they don't care this project can go on or not, they just want to earn more money before this project become totally unworthy for them.


  • Moderators

    @tham Ok, so, having said that, what's your plan here? I mean don't get me wrong. I can see your frustration, but what are you trying to achieve with this post?



  • @Chris-Kawa Listen to more voices of the developers.


  • Moderators

    @tham But you're talking to the developers.



  • @Chris-Kawa No, I mean I wish this post can gather more opinions of the developers, it would be nice if we could find someway to create a vote. Real customers of Qt is the developers, how could you expect to earn money if the developers become more and more unlike this project? Qt will become less and less attractive to new comers and old users if they trying to push away developers like this.


  • Moderators

    No, I mean I wish this post can gather more opinions of the developers

    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.

    it would be nice if we could find someway to create a vote

    A vote on what? I think you're confused. We don't make any decisions here. We're just a bunch of people using Qt.



  • As a company I very much miss the trolltech days. The Qt build process and html documentation was so much nicer. They have been moving steadily in the direction of the announcement above, and while some of us "principle motivated" geeks will jump ship and quit using Qt, I'm sure many sheeple will just go with the flow and be good little drones with their user accounts, directed marketing, poorly envisioned tool enhancements, etc.

    Reading the announement above does give me cause to start looking more seriously at other tools that I might now use Qt for.

    On a related note, I suppose they may be able to be as brazen as they are, based on how dismal the GTK tools have become. LOL



  • I have read the recent posts on this theme, and read through the current & historical changes posts pointed to. I am just a user of Qt, I don't claim to understand the ins & outs the way you guys do. I do have a couple of questions I'd appreciate an answer to, and here seems as good as anywhere to pose them. I hope someone replies, else I'll thinking about raising its own topic.

    I don't know whether The Qt Company is good or bad in its decisions. I just know that they are who we've got, so I wish them the best and hope all works out, I don't want to slag them off or be rude to them.

    I would like to understand the following:

    1. Is this forum (forum.qt.io) anything to do with The Qt Company? Does it host, manage, sponsor or pay for this in any way, or is this a totally self-contained separate entity?

    2. I know that some people here contribute code/patches to Qt, e.g. working through issues from the bug forum. How does that relate to whatever code comes out in the next Qt Company release of Qt? Does someone there cherry-pick and choose what to include? Do bug fixes get ignored by them and the next version could re-include a previously-fixed issue? Are the Open Source contributions essentially limited to bug fixes, only The Qt Company introduces new features according to some road map?

    3. Not that I am advocating the following at all, just asking, but: if Qt is Open Source/LGPL, what does The Qt Company "own"? Could the community totally ignore them and "produce its own versions" forever if it wanted to? Or is it somehow beholden to the rights of The Qt Company?

    Thanks for any clarifications, I'm truly interested.


  • Moderators

    @JonB Not a Qt Company employee but here's my understanding:

    1. Forum is owned, hosted, payed for and managed by the Qt Company. You login with the unified Qt account etc. There are also other channels of communication, notably the mailing lists and irc channels, where most of the Qt Company employees seem to hang out. The forum drifted over the years towards self-support of users and community building. It pretty much self regulates and I haven't seen much "corporate overlords influence" here.
    2. Qt is developed in an Open Governance model meaning anyone can contribute. That being said there are appointed module maintainers and reviewers (some from Qt Company, some from outside), and you need their approval for your changes to be merged upstream. See details here. Outside contributions are generally not limited in scope but some contributions might be rejected as not in scope, too complicated etc. If I remember correctly the original Android port for example was started as an entirely outside project and merged in later. From my experience it can take anywhere from days to years for your changes to be merged in, all depending on how good of a lobbyist you are, which is the normal state in an open source project I guess.
    3. Yup, you can fork the open-source modules anytime you want and some do, notably people from medical field have their own 4.something fork maintained to this day and there's a CopperSpice project. As you can imagine Qt is pretty big so these forks are usually short lived or very limited in scope. You can't expect the same support or community for them obviously. Some modules are available only under the commercial license and can't be forked and for the open source ones there's a binding agreement with the KDE Free Qt Foundation guaranteeing they will stay that way.

  • Moderators

    I agree with @Chris-Kawa's answers; I'd like to add a few more points.

    @JonB said in Qt company, don't speak for developers anymore, your managements are totally awful:

    1. I know that some people here contribute code/patches to Qt, e.g. working through issues from the bug forum. How does that relate to whatever code comes out in the next Qt Company release of Qt? Does someone there cherry-pick and choose what to include? Do bug fixes get ignored by them and the next version could re-include a previously-fixed issue? Are the Open Source contributions essentially limited to bug fixes, only The Qt Company introduces new features according to some road map?

    Here's a simplified summary of the contribution process in recent years. It applies to both Qt Company employees and external contributors.

    Each time we submit a patch, we specify which git branch the patch should go into. Currently, the latest LTS release is Qt 5.12.7 and the latest stable release is Qt 5.14.1. So the "LTS" branch is 5.12, the "stable" branch is 5.14, and the "next version" branch is 5.15.

    • If we submit a new feature or add new API, the patch must go into 5.15. These types of patches are not allowed in the stable branch.
    • If we submit a minor bugfix or minor documentation update, it can (should) go into 5.14.
    • Now and then, the contents of 5.14 will be forward-merged into 5.15. This means everything in Qt 5.14.x will also be present in Qt 5.15.0.
    • If a patch is important enough to be part of the LTS, someone cherry-picks it from 5.14 to 5.12.
    • Assuming that the release of Qt 5.15.0 is still far away, we will still see Qt 5.14.2 in a few months, built and released from whatever is in the 5.14 branch. Likewise for Qt 5.12.8.
    • When the time comes, the contents of 5.14 is forward-merged into 5.15 one last time and then the former branch is closed forever. Qt 5.15.0 will be built and released from the 5.15 branch which becomes the new "stable" branch.

    This is a simplified and incomplete story, but should be a good start. The full story is at https://wiki.qt.io/Branch_Guidelines

    Now, it turns out that forward-merging and cherry-picking patches is a very painful and boring job. So, a new workflow was recently proposed: https://wiki.qt.io/Qt_Contributors_Summit_2019_-_Branch_Policy I believe the new process will begin when Qt 5.15.0 is ready for release.

    Note: The current system is already an improvement of the previous system, which strained the Continuous Integration (CI) machines and slowed down the rate of integrating fixes and features into Qt: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches

    1. Not that I am advocating the following at all, just asking, but: if Qt is Open Source/LGPL, what does The Qt Company "own"? Could the community totally ignore them and "produce its own versions" forever if it wanted to? Or is it somehow beholden to the rights of The Qt Company?

    Since the Qt Company (and its predecessors, Digia, Nokia, and Trolltech) wrote the majority of Qt code, they own the copyright to most of that code. However, since the code is released under the (L)GPL, we are all free to use this code that is owned by the Qt Company (as long as we abide by the terms of the (L)GPL) — In other words, the Qt Company has granted us a license to use the code that they own.

    Similarly, when we, as an external contributor, submit a patch, we own the copyright to that patch. However, we sign a Contributor License Agreement (CLA) before submitting, granting the Qt Company a license to use the code that we own.

    The Qt Company also owns the trademarks for Qt. I'm not 100% sure of the implications, but I think that even though we are free to create our own fork of Qt code we are not free to use the current logos for our fork.


  • Moderators

    @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?


  • Moderators

    @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:

    1. Keep using Qt 6.1.3. It should keep working, after all.
    2. Roll up to Qt 6.2.0 if it contains a fix/enhancement that improves our app.
    3. 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.
    4. Roll up to 6.2.2 when we know that the regression is gone.


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


  • Qt Champions 2017

    @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


Log in to reply