The Growing Disconnect Between KDE And The Qt Company

LWN.net News from the source

• Content
  • Weekly Edition
  • Archives
  • Search
  • Kernel
  • Security
  • Events calendar
  • Unread comments
  • LWN FAQ
  • Write for us
• Edition
  • Return to the Briefs page

User: Password: | | Subscribe / Log in / New account The growing disconnect between KDE and the Qt Company [Posted April 9, 2020 by corbet]

Here's a message posted by Olaf Schmidt-Wischhöfer to the kde-community mailing list detailing the current state of discussions between the KDE community, the Qt development project, and the Qt Company. It seems they are not going entirely well. "But last week, the company suddenly informed both the KDE e.V. board and 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."

There is a response from the Qt Company that doesn't add a whole lot. to post comments

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 14:26 UTC (Thu) by rsidd (subscriber, #2582) [Link] (28 responses)

The Qt Company should consider the history of XFree86, the original SSH, ZFS vs OpenZFS, etc. If required, there will be a fork, and the fork will win. Qt is too important.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 14:37 UTC (Thu) by Flameeyes (guest, #51238) [Link] (5 responses)

Heh. I guess this old article of mine is relevant 😉

https://lwn.net/Articles/282261/

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 5:11 UTC (Fri) by rsidd (subscriber, #2582) [Link] (4 responses)

Interesting you mention ffmpeg. It later got forked into libav, but that was a fork that failed. (Similarly, way back, linux forked glibc into its own version, but eventually re-adopted the GNU libc 2.0.)

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 16:00 UTC (Fri) by Flameeyes (guest, #51238) [Link]

Yeah I'm painfully aware of that fork as well ;)

The article also predates LibreOffice, and more recently Glimpse. Maybe I should revisit it and see how it holds true in 2020.

The growing disconnect between KDE and the Qt Company

Posted Apr 12, 2020 6:51 UTC (Sun) by khagaroth (guest, #109895) [Link] (1 responses)

The libav fork actually succeeded. Even thought it didn't replace ffmpeg, it did cause a change in attitude in the project and the whole ffmpeg ecosystem got better thanks to that.

The growing disconnect between KDE and the Qt Company

Posted Apr 20, 2020 21:58 UTC (Mon) by flussence (guest, #85566) [Link]

That's a strange definition of success, unless the long play all along was to dump all the bad attitude into libav and then self-destruct it so they'd stay gone. The attempted copyright fraud over the logo they had no rights to certainly wasn't done in good faith to ffmpeg, or anyone.

The growing disconnect between KDE and the Qt Company

Posted Apr 16, 2020 15:52 UTC (Thu) by smurf (subscriber, #17840) [Link]

libav didn't fail, it caused the ffmpeg people to get their act together, thus rendering libav unnecessary.

Also, not so way-back-ish, glibc got forked off to eglibc. The latter is now discontinued, but it was a success insofar as the glibc people woke up and fixed the issues that caused the fork in the first place.

Also consider LibreOffice as an eminently successful fork that has all but superseded the heap of inaction that is Apache OpenOffice.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 18:03 UTC (Thu) by flussence (guest, #85566) [Link] (21 responses)

The Qt Company should consider the history of the Qt Company. It's not too late for KDE to start porting to Gtk.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 18:44 UTC (Thu) by logang (subscriber, #127618) [Link] (6 responses)

Please god, no.

KDE is already one of the most disruptive pieces of software to update. If they were to rewrite everything *again*, I'd stop using it for good.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 23:25 UTC (Thu) by luya (subscriber, #50741) [Link] (4 responses)

KDE got rewritten for decade it seems suffering of identity crisis. Lack of focus and an apparent tech preview for Qt Company are possibly an issue.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 23:49 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

KDE died when they moved towards "semantic desktop" nonsense :(

The current state is actually not that bad, but so much stuff is just plain unpolished.

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 5:27 UTC (Fri) by flussence (guest, #85566) [Link] (2 responses)

That also seems to be the feeling of pretty much everyone I know that actually uses it - including an app developer or two. It's exasperating to see it go this way, as KDE3 was one of the things that got me to switch to Linux.

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 14:13 UTC (Fri) by yodermk (guest, #3803) [Link]

Yeah. I was a staunch KDE user most of the time from its first beta release in 1998. Stuck through the early KDE 4 releases. Finally switched to Gnome in the KDE 5 era, because it just had too many quirks. Every time I switch back to KDE to take a peek, it only lasts a couple days until I'm back on Gnome.

It's a shame, and maybe it's time for another peek...

The growing disconnect between KDE and the Qt Company

Posted Apr 12, 2020 11:30 UTC (Sun) by Wol (subscriber, #4433) [Link]

The semantic desktop was pretty much unusable for me ... it's all very well the devs saying "you need to help us debug it", but I was certainly not alone in it taking DAYS to go from login screen to desktop ... I think the longest I let it run was 36hrs.

I had to go to Xfce to get a usable system ...

I'm currently stuck on KDE4, but all being well my new system will be up and running with Qt5/Plasma/whatever new "goodies" are now out.

SuSE was always a good supporter of KDE - hopefully if there's trouble they'll step up to the plate with a fork ...

Cheers, Wol

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 7:59 UTC (Fri) by Duncan (guest, #6647) [Link]

That's why I've "gone live" with KDE and a select few additional packages here, and presumably why the Gentoo/KDE project makes the live ebuild versions that I and others use available in the project overlay . Of course that's a lot easier to do on a distro like Gentoo that's scripted-from-sources for everything already, with tools like smart-live-rebuild and ccache greatly reducing the pain.

It helps a lot when you can bisect a regression down to an individual commit, as opposed to an entire version upgrade, and I've had considerably more success with my bug reports as well, even compared to when I was running the KDE pre-releases.

It helps with unwanted "new features" as well. I don't claim to be a dev, but once the specific code is pointed out by bisect to an individual commit, I can often revert or tweak it in a patch I can auto-apply at every update. I've been carrying a few such patches for years, now. I did the same thing at the ebuild level for the period Gentoo/KDE tried killing USE=-semantic-desktop (despite upstream KDE/plasma's continued support for the build option), too. Fortunately that one was relatively short lived and I didn't end up having to chose a different desktop. =:^)

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 20:11 UTC (Thu) by halla (subscriber, #14185) [Link] (4 responses)

GTK is not the equivalent of Qt. It's not even the equivalent of the QtBase library. If push comes to shove, the natural thing would be to fork Qt. Porting to GTK? That would be rank idiocy.

The growing disconnect between KDE and the Qt Company

Posted Apr 13, 2020 16:42 UTC (Mon) by Sesse (subscriber, #53779) [Link] (3 responses)

You're saying this as if everyone wants their C++ widget libraries to also replace the C++ container classes :-)

The growing disconnect between KDE and the Qt Company

Posted Apr 14, 2020 7:51 UTC (Tue) by halla (subscriber, #14185) [Link] (2 responses)

Despite having worked with Qt for about 25 years, I'm not interested in C++. I abhor the STL and boost disgusts me. The stl container classes and iterators are abominations.

I started using Qt because it had Python bindings; I was able to become the maintainer of a big C++ application because Qt was as easy to use as Java. I continue to use Qt and C++ because I'm still the maintainer of that big C++ application.

But I'll never understand anyone who wants to use C++ without Qt. I'll never understand anyone who prefers the stl container classes to Qt's.

The growing disconnect between KDE and the Qt Company

Posted Apr 17, 2020 16:50 UTC (Fri) by zlynx (guest, #2285) [Link] (1 responses)

You use the standard C++ containers because they are standard. They don't require adding new dependencies.

I would just laugh if some developer wanted to add all of Qt as a dependency because they wanted to use a few Qt container classes. It's different if you're actually using it as a GUI library. Then it makes sense.

I've never found any general advantages to using the Qt stuff. The C++ standard capabilities are just as good. Trying to mix the two systems is stupid though, resulting in all kinds of useless copy operations.

Worst was when somebody decided to do a conversion operation between QList and std::vector. Every time the function was called. Oh sure look the unit tests with five elements work fine! Real life with 100,000 elements does NOT WORK FINE! Had to rewrite it to use templates. At least Qt does support standard iterators.

The growing disconnect between KDE and the Qt Company

Posted Apr 17, 2020 17:49 UTC (Fri) by halla (subscriber, #14185) [Link]

I don't use the stl, because it's ill-documented garbage created by armchair library designers. And you don't use Qt just because of QList and QVector; you use those classes because they come with a platform that makes it possible to create useful applications for real users.

I don't know who you are; zlynx; I don't know what you have created. But I agree that mixing std and Qt is dumb; using std is dumb.

I only know that I've maintained a big Qt-based application, Krita, with millions of users since 2004.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 21:26 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

It would make sense to port GNOME to QT, rather than vice versa.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 21:55 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Nah. Either way is just plain silly and just not going to happen. Qt fork seems more possible but I do wonder whether the community at large has the resources to maintain a healthy fork. I would love to hear thoughts on people more involved in that ecosystem

Oh God Oh No It Popped Up Again HELP

Posted Apr 9, 2020 21:31 UTC (Thu) by fratti (guest, #105722) [Link] (1 responses)

The day I am forced to use Gtk's file dialogue as my only option is the day I self-immolate in front of the Qt offices.

Oh God Oh No It Popped Up Again HELP

Posted Apr 10, 2020 13:55 UTC (Fri) by clopez (guest, #66009) [Link]

Lol.. i understand what you mean. Using xfce and im still have not figured how to change that stupid file chooser. It only avoids the pain the fact that i work 99% of time from a terminal.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 23:44 UTC (Thu) by atai (subscriber, #10977) [Link] (4 responses)

Probably more likely a fork of Qt rather than port to gtk

The growing disconnect between KDE and the Qt Company

Posted Apr 11, 2020 9:58 UTC (Sat) by ncm (guest, #165) [Link] (3 responses)

Forking Qt would be a good opportunity to get rid of its intrusive "signals", "slots", etc. macros.

Apparently Q_* alternatives have long been supported, but they have not caught on with users. Stewards of a fork can make the more responsible choice by simply eliminating the bad macros, leaving the others.

But that doesn't mean they will.

The growing disconnect between KDE and the Qt Company

Posted Apr 11, 2020 14:48 UTC (Sat) by halla (subscriber, #14185) [Link] (1 responses)

That's being discussed for Qt6: https://lists.qt-project.org/pipermail/development/2020-F... .

The growing disconnect between KDE and the Qt Company

Posted Apr 17, 2020 16:13 UTC (Fri) by ncm (guest, #165) [Link]

Followed up. They are still in denial mode.

The growing disconnect between KDE and the Qt Company

Posted Apr 12, 2020 9:04 UTC (Sun) by rdfm (subscriber, #50178) [Link]

That has already happened a while ago. I've been considering Copperspice as an alternative to Qt for a while now. But the pain of such a migration doesn't make economic sense where I work. Yet.

https://www.copperspice.com/

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 15:12 UTC (Thu) by codewiz (subscriber, #63050) [Link] (3 responses)

Even after considering the recent Coronavirus dip, QTCOM is still up 200% in the last 12 months.

Either the shareholders are not well informed about the grim financial outlook, or the KDE e.V. board was told a bunch of excuses.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 18:48 UTC (Thu) by logang (subscriber, #127618) [Link] (2 responses)

There's a huge difference between stock price and cash flow.

The only real link is that they could try and get cash by issuing shares. But investors obviously don't like that.

The growing disconnect between KDE and the Qt Company

Posted Apr 9, 2020 21:28 UTC (Thu) by fratti (guest, #105722) [Link] (1 responses)

They're a publicly traded company, so we can actually look at somewhat recent data for how their finances are doing.

Their cash reserves in Q2 of 2019 were at around 10 million euros, with 2 millions in short-term interest bearing debt. As a point of comparison, in Q1/2017 they were at 5.42 million Euros in cash reserves and 6.13 million Euros of short-term interest bearing debt.[1] While I don't doubt the situation has changed significantly in 2020, I also would count on a lot of very cheap short-term loans becoming available this year as the EU finally figures out that maybe they should act sooner rather than having a few more embarrassingly public spats over north vs. south, which will lead to them making a lot of cash available.

With Qt employing 340 people, a very large fall in revenue would have to happen for them to completely wipe out their cash reserves and prevent them from taking up any further short term loans. The kind of drop in revenue that, in my opinion, wouldn't be compensated for by trying to boost sales in an economy that isn't very spend-happy right now.

What I think is more likely is that there's some miscommunication between Qt and KDE as The Qt Company is pondering what to put into their 23rd of April interim statements to investors.

Disclaimer: I am no financial expert, I just pretend to understand things while posting comments online because it's the only way I can feel like I'm smart.

[1]: https://investors.qt.io/financials/

The growing disconnect between KDE and the Qt Company

Posted Apr 11, 2020 7:50 UTC (Sat) by oldtomas (guest, #72579) [Link]

Don't worry. Your comment gotta be one of the smartest in this specific location.

Don't get me wrong, I keep coming back to lwn because of the outstanding articles, but also because of the outstanding community here in the comments section. But some topics seem to trigger old and atavistic reflexes like "C is soo old!", "STL!", "Gotta be Java!", "Client-server ain't type-safe!". Those are language wars, license model wars (and this toolkit question, which is at the crossroad of both).

Guess there has to be some replacement for religion ;-)

C++ GUI

Posted Apr 9, 2020 18:56 UTC (Thu) by yodermk (guest, #3803) [Link] (11 responses)

I for one dearly wish there was a GUI toolkit that

1) was designed from the ground up for modern C++ 2) was BSD-type licensed

Am I missing the existence of one? I'm nowhere near qualified to start or lead such a project, but I'd probably contribute to it.

C++ GUI

Posted Apr 9, 2020 22:47 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]

FLTK is not really designed for C++, but it is very simple to use with C++. I try to avoid writing GUIs, but, when I must, I use it.

C++ GUI

Posted Apr 10, 2020 6:27 UTC (Fri) by liam (subscriber, #84133) [Link]

https://www.copperspice.com/

Not exactly "from the ground up" but I think the intent matches. Oh, it's lgpl 2.1, BTW.

C++ GUI

Posted Apr 10, 2020 6:40 UTC (Fri) by re:fi.64 (subscriber, #132628) [Link] (1 responses)

Not really ground up, but Boost.UI is a pretty cool, modernized wrapper over wxWidgets. Nana is also an option: http://nanapro.org/en-us/

C++ GUI

Posted Apr 12, 2020 22:38 UTC (Sun) by yodermk (guest, #3803) [Link]

Interesting, it looks like both are very much along the lines of what I'm looking for! Not sure why I haven't heard of them. Will check them out more extensively, thanks!

C++ GUI

Posted Apr 10, 2020 15:29 UTC (Fri) by simlo (guest, #10866) [Link] (6 responses)

Sorry, but I think this is a bit old school: writing monolithic programs in C++ was sounds like the 90s.

I write a lot of C++ code at my $DAYJOB and I like it a lot - but not for everything. I am more productive in Java and Python.

If Iwere to start a new GUI application, I would go for whatever good and fast applications are written in, and write the front end in that framework - and language!!! If it's typescript, learn typescript. Licenses are more important than language.

I would investigate using container like packaging (snap, flatpak kind of stuff) to distribute a client server architecture, where you can write the server backend in C++ if the performance requires it.

C++ GUI

Posted Apr 10, 2020 19:34 UTC (Fri) by HelloWorld (guest, #56129) [Link] (3 responses)

Having a client/server architecture means that you lose type safety, because all the data that travels between the frontend and the backend needs to be marshalled. And that is not the only problem with that approach. When the backend allocates an object on behalf of the frontend, it needs to hand out some kind of token that the frontend can then use to interact with the object. But the backend has no way of knowing when the token is garbage collected in the frontend, so it doesn't know when to deallocate the object, so you effectively break the garbage collector by running the program in two separate processes.

So unless you have business reasons to have the frontend and backend run in separate processes, it seems like a bad idea to me.

C++ GUI

Posted Apr 15, 2020 20:53 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (2 responses)

> Having a client/server architecture means that you lose type safety, because all the data that travels between the frontend and the backend needs to be marshalled.

I struggle to see what you mean by this. Marshalling can be entirely type safe, or entirely unsafe, depending on how it is implemented. There are whole libraries for type-safe marshalling (usually attached to an RPC framework, which you are probably going to want anyway).

> When the backend allocates an object on behalf of the frontend, it needs to hand out some kind of token that the frontend can then use to interact with the object. But the backend has no way of knowing when the token is garbage collected in the frontend, so it doesn't know when to deallocate the object, so you effectively break the garbage collector by running the program in two separate processes.

That's the frontend's problem (it leaked a handle rather than closing it). I am not aware of a single (popular, modern) language which simultaneously lacks all of the following:

- The finally block or an analogous feature (like Go's defer). - try-with-resources or an analogous feature (like Python's with statement or C#'s IDisposable) - Destructors (which run at a deterministic time, and should not be confused with GC-based finalizers). - goto err; - Something involving Monads (I'm sure that Haskell has solved this problem, I just don't think it uses any of the above solutions).

So my conclusion is that the frontend, regardless of implementation language, should be capable of informing the backend when it is finished with an object.

C++ GUI

Posted Apr 17, 2020 16:57 UTC (Fri) by zlynx (guest, #2285) [Link]

I do think it is pretty funny when programmers in garbage collected languages finally realize that they actually do have to do all the work that a C++ programmer does. Usually with worse tools than RAII gives you.

GC handles memory and that's it. Not any kind of resource handle or remote operation.

GC languages often have pretty stupid ways to handle intentionally restricting resources too. Since no one bothers tracking memory allocations in their code, it makes it pretty hard to restrict a single network request to 10 MB, for example.

Once you start using resource pools in Java, you may as well be writing C++ but with worse code.

C++ GUI

Posted Apr 22, 2020 6:02 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

> .my conclusion is that the frontend, regardless of implementation language, should be capable of informing the backend when it is finished with an object.

Standard question: see if someone thinks any language construct will guarantee a client will always be able to tell a server that it's time to release a resource...

If they say yes, they may not have much experience working with said systems. May or not matter for the job at hand, but it can be revealing.

C++ GUI

Posted Apr 12, 2020 20:09 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

"Good and fast applications" are still written in C or C++. Just take PCem and try to run "lighweight" software on something like 300MHz CPU (emulated).

You'll find out that it's easy to make something responsive with FLTK, GTK, QT or bazillion other toolkits but anything "modern" is just plan out unusable.

Now, if you go into real "hey, that's free software so it's Ok to force user to buy $50 of additional memory/CPU/GPU just to run it"... then you actually have a choice.

C++ GUI

Posted Apr 13, 2020 21:19 UTC (Mon) by bovinespirit (subscriber, #88348) [Link]

Qt have just released Qt for MCUs which appears to target exactly those kind of embedded devices. It uses QML and (I think limited) Javascript for the front end and Qt C++ for the backend. I think it's all under an expensive commercial license though (which may help their bottom line) but hopefully it'll be less than $50 a device.

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 9:14 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

For the cash flow to increase, projects that are currently using the Open Source version of Qt would have to switch to the commercial version. I don't really see why even a single project would do that. They'd just use the 12 months older version instead. The times where programs required the latest and greatest Qt release are long gone. Every Qt release in the last couple of years contains 99% of what projects need. If there's something minor missing, the project can just implement that detail or use another additional library.

This licensing change will not increase the cash flow. That is just implausible.

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 14:23 UTC (Fri) by yodermk (guest, #3803) [Link] (1 responses)

That's true, unless one wants to get a head start on Qt 6 with its redesign. I might want to do that.

That said, I'm unsure if I want to use Qt in the future now or not. Besides this kind of shenanigan, I'm a bit miffed at Qt's use of its MOC and its own types that duplicate so much of the C++ STL. I get that historically they had to develop that because the STL was not fully developed, but now it is.

If I were to use Qt, I would have strict separation between the GUI code and any actual data processing. That would be in pure C++.

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 21:06 UTC (Fri) by HelloWorld (guest, #56129) [Link]

Qt's container classes offer functionality that STL containers don't, such as copy-on-write, they also have STL interoperability (STL-style iterators), and they're templates, so no code is generated unless you use them. What exactly is the problem here?

If you don't like moc, you can use Verdigris instead, at the cost of some additional boilerplate. But I don't see why you would – moc is the kind of thing that you configure once in your build system and then never think about again.

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 11:33 UTC (Fri) by clemensg (guest, #94377) [Link] (5 responses)

The price of the commercial licenses is very high and you have to pay them per developer every year. Small companies can't afford that, so they use the LGPL version instead and implement parts, which are available in GPL-only or commercial (e.g. the virtual keyboard) themselves. Unless they create a more flexible licensing system geared towards smaller companies, I don't expect them to sell more licenses. And alienating the free software community is definitely not going to help either..

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 14:25 UTC (Fri) by yodermk (guest, #3803) [Link] (4 responses)

They do have a small business license, but it has to have maximum income of $250,000 (recently raised from $100k) so it's really only for the smallest of startups.

I agree, commercial pricing is absurd. Well, maybe not if you're really using it for all it's worth and it is your career. But not plausible if you just want a UI toolkit.

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 14:55 UTC (Fri) by lisandropm (✭ supporter ✭, #69317) [Link] (3 responses)

For latin america they are still too expensive. yesterday I read someone proposing a 10% of the final price of the product with a minimum of 1 US$ and a maximum of 50US$. That might make more sense.

The growing disconnect between KDE and the Qt Company

Posted Apr 14, 2020 18:11 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

What happens if your product uses 11 such components?

:-)

Cheers, Wol

The growing disconnect between KDE and the Qt Company

Posted Apr 14, 2020 18:28 UTC (Tue) by lisandropm (✭ supporter ✭, #69317) [Link] (1 responses)

Within Qt: my guess is that it would still be cheaper. From outside Qt: well, Qt provides mostly what I need.

The growing disconnect between KDE and the Qt Company

Posted Apr 19, 2020 16:25 UTC (Sun) by jospoortvliet (guest, #33164) [Link]

Problem is that that doesn't cover a common use case of Qt - build complex business applications that are used internally, or at a customer whom they are build for. In those cases Qt would earn, like, 50 bucks ;-)

It's quite hard to figure out licensing, and it often ends up being super stupidly bad for a portion of the user base, but to make it work for everyone often ends up lowering the total income significantly so you'd rather have it be unsuitable for a part of your customer base (who's money you lose out on) than fix that problem. Which then in turn can be a long term issue as small companies get bigger etc...

Pricing is a pita - I have some bad experience ;-)

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 11:56 UTC (Fri) by joib (subscriber, #8541) [Link] (2 responses)

It seems unsurprising that the old Trolltech dual licensing business model (whatever the virtue or lack thereof of said business model) doesn't work that well after Nokia relincensed qt under LGPL.

Hope they'll figure out something that is good for both the FOSS community and for the company.

The growing disconnect between KDE and the Qt Company

Posted Apr 10, 2020 13:46 UTC (Fri) by ocrete (subscriber, #107180) [Link] (1 responses)

But the old Trolltech model didn't work even before Nokia though it.. This is why Nokia could acquire the whole company for cheaper than writing their own UI toolkit.

That said, the new Qt company seems to be doing much better than old Trolltech. They have a healthy business with companies making embedded devices and needing some kind of UI.

This whole things feels like greed. Not that they're struggling more than everyone else, but it seems like they want to maintain growth despite most of their customers not growing this year. Or at least not have their revenues fall more than their customers R&D spend.

This whole Qt licensing fiasco repeats itself in various forms throughout the history of Qt+KDE, this is exactly why GNOME exists in the first place.

The growing disconnect between KDE and the Qt Company

Posted Apr 12, 2020 8:09 UTC (Sun) by oak (guest, #2786) [Link]

I don’t understand why their paying customers would want wider scale testing of new Qt releases (done by KDE etc) to be postponed by a year.

Copyright © 2020, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds