4 ms·

> if it had never been developed In all fairness: Gnome was absolutely great at its beginnings… until the clique around Havoc Pennington took over and decided

> if it had never been developed In all fairness: Gnome was absolutely great at its beginnings… until the clique around Havoc Pennington took over and decided they know better than the users what's good for them and ruined Gnome… thus earning them the affectionate title "interface nazis" dished out by Linus Torvalds. https://www.cio.com/article/220271/11-technologies-that-tick-off-linus-torvalds.html#gnome https://www.cio.com/article/220271/11-technologies-that-tick... > after the Qt license issues were sorted out Much as I'd agree that GTK has proven to not be the way (either), I don't see the "Qt license issues" as being "sorted out" at all. It did look like it for a short while after Nokia bought Trolltech and made Qt available under LGPLv2.1, but that didn't last long: Shortly after, Microsoft managed to place their mole Stephen Elop onto the CEO seat of Nokia, and Elop methodically ruined Nokia in preparation for a Microsoft takeover and threw out Qt (which represented cross-platform, a concept Microsoft always saw as as a threat to their business model), replacing it with the ill-fated Windows Phone platform. Under Digia, and even more so once splitted out as QTCOM, The licensing focus of Qt has shifted from "make it more open so as to gain wide traction" (the strategy under Nokia) to "try to force devs into commercial licensing schemes and monetize to the max you can milk out of it", and it has been a sore downhill slide into a shitty situation. The "Qt license issues" we have today aren't the same as way back then in the QPL days of early KDE-vs-Gnome forum wars, but they are at least as bad imho. A lot of developers who used to develop mainly with Qt (me included) have since jumped ship because of that and prefer to avoid Qt too now, though the sad reality is that while there are better alternatives depending on the project, there isn't really a good free cross-platform allround alternative for Qt either. I think there is really a big window of opportunity and gap to be filled by a new modern cross-platform UI toolkit.

paulryanrogers 4y ago
Can't you still use QT as FOSS, albeit not their LTS binaries
- EntrePrescott 4y ago
  First of all, it's not just the LTS binaries, it's also the LTS source and license for it. Commercial-only. No FOSS. But it goes further: even for what is still FOSS (i.e. the non-LTS), the licensing gets progressively more and more restrictive: * whereas Nokia made Qt available under the relatively permissive LGPL2.1, that since changed to a mixture of LGPL3 and GPL, with a clear shift towards the latter: that is: for new modules, you typically only have the choice between commercial and GPL. Unless you are content with that for all of your software projects, that's quite the problematic constraint.
  - midoridensha 4y ago
    >for new modules, you typically only have the choice between commercial and GPL. Unless you are content with that for all of your software projects, that's quite the problematic constraint. For a FOSS project like KDE, why would this be problematic? I don't see how this is an issue at all.
    - EntrePrescott 4y ago
      Well, first of all, while the GPL is one particular FOSS license (out of many), it's not as if it was compatible with all FOSS licenses, far from it. So while imposing GPL or commercial may not be a problem for a FOSS project that happens by chance to have chosen that one specific license anyways… it can be a huge problem for others that want to choose a different FOSS license. And that's just for projects that happen to be FOSS anyways. The thing is: very few software developers have the luxury of releasing ALL their software projects as FOSS. Something has to pay the rent and food. There are a few select domains where developing FOSS software can be a the base for a business model that pays a sustainable living… but those tend to inherently have a very small intersection with the kinds of software typically developed with Qt. And huge complex frameworks aren't something a developer changes all the time like underwear. It's something devs tend to stick to, because it takes quite a significant time investment to master and to build your workflow, tooling etc. around. In other words: developers largely tend to do their FOSS projects in the same framework that they use for the work projects that pay their rent and food. If big framework A disqualifies itself for the latter and gets replaced with framework B for that, chances are that their FOSS projects will be centered around framework B as well and no longer around framework A. As long as Qt was a viable option for work, it made perfect sense to center one's FOSS efforts around Qt as well and thus around KDE, which is the primary Qt-based Desktop. But since the licensing situation of Qt deteriorated, that is no longer the case. So that's another factor where it impacts KDE.
emmelaich 4y ago
> until the clique around.. I think that's really unfair. Fact is, the Gnome/Freedesktop people were the first ones to actually do user experience tests thoroughly and then use that feedback.

paulryanrogers 4y ago

Can't you still use QT as FOSS, albeit not their LTS binaries

EntrePrescott 4y ago
First of all, it's not just the LTS binaries, it's also the LTS source and license for it. Commercial-only. No FOSS. But it goes further: even for what is still FOSS (i.e. the non-LTS), the licensing gets progressively more and more restrictive: * whereas Nokia made Qt available under the relatively permissive LGPL2.1, that since changed to a mixture of LGPL3 and GPL, with a clear shift towards the latter: that is: for new modules, you typically only have the choice between commercial and GPL. Unless you are content with that for all of your software projects, that's quite the problematic constraint.
- midoridensha 4y ago
  >for new modules, you typically only have the choice between commercial and GPL. Unless you are content with that for all of your software projects, that's quite the problematic constraint. For a FOSS project like KDE, why would this be problematic? I don't see how this is an issue at all.
  - EntrePrescott 4y ago
    Well, first of all, while the GPL is one particular FOSS license (out of many), it's not as if it was compatible with all FOSS licenses, far from it. So while imposing GPL or commercial may not be a problem for a FOSS project that happens by chance to have chosen that one specific license anyways… it can be a huge problem for others that want to choose a different FOSS license. And that's just for projects that happen to be FOSS anyways. The thing is: very few software developers have the luxury of releasing ALL their software projects as FOSS. Something has to pay the rent and food. There are a few select domains where developing FOSS software can be a the base for a business model that pays a sustainable living… but those tend to inherently have a very small intersection with the kinds of software typically developed with Qt. And huge complex frameworks aren't something a developer changes all the time like underwear. It's something devs tend to stick to, because it takes quite a significant time investment to master and to build your workflow, tooling etc. around. In other words: developers largely tend to do their FOSS projects in the same framework that they use for the work projects that pay their rent and food. If big framework A disqualifies itself for the latter and gets replaced with framework B for that, chances are that their FOSS projects will be centered around framework B as well and no longer around framework A. As long as Qt was a viable option for work, it made perfect sense to center one's FOSS efforts around Qt as well and thus around KDE, which is the primary Qt-based Desktop. But since the licensing situation of Qt deteriorated, that is no longer the case. So that's another factor where it impacts KDE.

emmelaich 4y ago

> until the clique around.. I think that's really unfair. Fact is, the Gnome/Freedesktop people were the first ones to actually do user experience tests thoroughly and then use that feedback.