Why More and More Companies Would Rather Rewrite Their Code Than Continue Using Qt?

[QtTester]

a translation from https://mp.weixin.qq.com/s/EWBtMRqeO95RqDJkKdGItA

In recent years, more and more companies have started re-evaluating Qt. Not because Qt doesn't work anymore—on the contrary, it's because it works so well that many teams jumped in headfirst years ago, only to discover today how deep the rabbit hole goes.
When people used to mention Qt, the words that came to mind were:
Cross-platform. Mature. Classic. Industrial software powerhouse. Essential for C++ desktop development.
Now when companies mention Qt, the first reaction has become: "Is this thing going to get us a cease-and-desist letter?"
Notice how the tone has completely changed?
That's Qt's biggest problem right now: Its scariest aspect is no longer technical—it's increasingly resembling a legal trap.
I. Many People Aren't Deterred by Technology, But by Cease-and-Desist Letters
Let me start with a true story that's almost absurd.
A colleague of mine simply asked a question online about Qt encryption. Unexpectedly, Qt's official customer service actually called to inquire about the situation.
At this point, many might think: Oh, perhaps it's just routine communication.
But guess what happened next?
The nightmare began.
What followed was:
Daily cease-and-desist letters.
You read that right—literally every day. Not starting with clarifying boundaries, not helping sort out what's compliant and what's not, not telling you how to fix things—
But immediately cranking up the pressure:
You may be infringing.
The most disgusting part of this is that many teams weren't deliberately trying to freeload, nor were they knowingly violating rules. Simply put, many people treated Qt as just another development framework, only to discover they'd stepped into a legal quagmire.
Developers were confused. Team leads were confused. Leadership was furious.
Leadership's most authentic reaction usually isn't "let's research the licensing agreement," but rather:

"We pay money and still have this much trouble? Can't we just not use this thing?"

With that one sentence, Qt's credibility within the company drops by half.
II. What's Most Frustrating About Qt Isn't the Cost—It's the Fear of Using It
Let's be clear: It's normal for commercial software to charge money.
Nobody thinks Qt shouldn't charge. The issue was never "how dare you charge?"
The problem is that Qt now gives many small-to-medium teams, client application projects, and industrial software teams the impression not of "reasonable pricing," but of:
Either pay up, or don't use it. And even if you pay, you're not necessarily in the clear.
That's absurd.
Many people criticize Qt not because they're "stingy," but because the entire commercial licensing mechanism feels too much like a trap.
First, the pricing is unfriendly
Don't keep using "big companies can afford the licensing fees" as an excuse.
When you're building a PC client, device management tool, industrial HMI interface, or supporting desktop software, it's often not some "strategic company-level project," but rather a small team of a dozen people within the company.
The entire company having money and this small team being able to smoothly secure budget approval are two different things. Whether leadership is willing to continuously approve Qt licensing fees for such a project is yet another matter.
Developers think Qt is great to use; leadership thinks:
Are there alternatives? Is it absolutely necessary? Will we have to keep renewing this?
If even one of these three questions can't be answered, Qt's budget approval becomes increasingly difficult.
Second, the licensing mechanism is too rigid, creating a dilemma
One of Qt's most problematic aspects is that it doesn't follow a "low-cost entry with smooth upgrade later" business model. What do many teams fear most?
They fear starting with it for development convenience, then discovering after the business grows that license switching, agreement boundaries, legacy code, and module dependencies have all become landmines.
When using the open-source version, they fear crossing boundaries. When switching to commercial, they fear unclear legacy issues. When using the commercial version, they fear increasing renewal pressure. Once it stops, the team immediately panics: What about subsequent iterations? Version updates? Client delivery?
In short:
Once you use Qt, you're not controlling it—it starts controlling you.
Third, and most critically: "Uncertainty"
What companies fear most is never high cost.
What companies fear most is:
Expensive, troublesome, and impossible to explain clearly.
This is Qt's real problem.
III. Engineers Can't Explain It, Legal Can't Understand It—The Project Team Takes the Fall
When many developers mention Qt licensing issues, they immediately start talking about:
LGPL. Dynamic linking. Static linking. Distribution methods. Module restrictions. Plugin loading.
Sounds very professional, right?
Here's the problem:
The company's legal team can't understand any of it.
You explain dynamic linking to legal—they just frown.
You tell leadership "theoretically this should be fine"—leadership just asks:

"Theoretically? What about in practice?"

Once that question drops, the conversation is basically over.
Because what companies want isn't "theoretically fine," not "lots of people online do it this way," and certainly not "someone in the community said it's probably okay."
What companies want is:
Certainty.
Preferably the kind that's clear at a glance, doesn't require lengthy explanations, and doesn't require worrying with every release.
And Qt, in the eyes of many companies right now, is precisely what's most lacking in certainty.
You say from a technical perspective, LGPL doesn't restrict dynamic linking. But in practice, who certifies that? Developers don't have the authority. Legal doesn't understand the technical details. Once Qt takes a hard stance, the project team immediately becomes the most unfortunate party.
Eventually, things slide toward a very realistic conclusion:
Stop explaining—just replace it.
IV. The Worst Part Isn't the Cost—It's the "Scare You First" Attitude
Why do more and more developers hate Qt?
Not because Qt is commercialized. Not because Qt has a legal team. Not even because Qt licensing is expensive.
But because what many people now feel isn't a "let us help you use this compliantly" attitude, but rather: "We're watching you to see if you have any problems."
Once this feeling takes hold, it's really damaging.
What developers fear most isn't spending money—it's being disgusted.
What companies fear most isn't procurement—it's lack of control.
What leadership fears most isn't technology migration—it's whether this thing will become a never-ending headache.
Especially when many people mention issues with domestic agents, they're even more furious. Many teams' experience is:
Regardless of whether you're open-source or licensed, cease-and-desist letters get sent indiscriminately.
How can anyone withstand that?
When leadership sees this kind of thing, they won't analyze how advanced QML is, nor care how elegant signal-slot is.
Leadership will only have one heartbreaking question:

"Can't we just not use this thing? With so many of you, can't you think of an alternative?"

Don't underestimate it—this statement is more damaging than a cease-and-desist letter.
Because once leadership starts thinking this way, Qt is no longer a "mature technical solution" within the company, but rather "a source of trouble we'd better get rid of soon."
V. What Qt Has Really Lost Isn't Technical Superiority—It's Trust
To be fair, Qt is technically solid. Cross-platform capability, maturity, industrial scenario accumulation, C++ ecosystem, widget system—these are all there.
The problem is that enterprise technology selection stopped being purely technical long ago.
No matter how strong your technology is, if what companies ultimately feel is:

Continuous spending
Complex agreements
Vague risks
Legal headaches
Management unease

Then it becomes difficult to remain the "default choice."
Previously, people discussed:
Is Qt good to use?
Now people discuss:
Is Qt worth continuing to use?
These two questions look similar, but they're actually worlds apart.
When a technology framework starts being asked "is it worth it" on a large scale, it faces no longer just technical competition, but a crisis of trust.
And once trust is gone, technical advantages won't sustain it for long.
VI. So More and More Companies Are Turning to C#, WPF, Web, and Electron
Many people like to frame replacing Qt in idealized terms, as if you need to find something that "completely dominates Qt" in every aspect to count as a replacement.
That's not how it works at all. In reality, when companies switch technology stacks, it often comes down to one sentence:
Whoever makes things easier, I'll use them.
Not necessarily the strongest, but definitely the most stable.
For Windows business, more people are looking at C# + WPF
If your business primarily runs on Windows, many teams' thinking is straightforward:
Why should I endure Qt's commercial and compliance costs for "theoretical cross-platform" benefits?
C# + WPF may not be prettier than Qt, may not be as comprehensive as Qt, but it has one huge advantage:
Low organizational cost.
Easier to hire. Easier to maintain. Easier for leadership to understand. Much less legal pressure. Company procurement doesn't feel like going to war every time.
Just this point is enough.
Web + Electron / Tauri are also increasingly attractive
Don't look at how everyone complains about Electron's memory usage. From an enterprise perspective, it has many advantages:
Plenty of frontend developers. Fast UI development. Fast iteration. Large ecosystem. Not constantly being squeezed by licensing issues.