The problem with Linux distros is the number of branches. It makes the developer's job a lot harder.
No, I've never had any issues with that. Sure, there is a few hours of work to verify the package dependencies for each root distribution and write the package scripts, but it isn't a big deal at all.
The people who have trouble with that, are the ones who cobble together particular versions of particular libraries, and write code that only works with those. They need Snap or similar, because
"modularity" is not something they grasp.
Now, if you had written
"You need better developers to do that", I would have agreed. There is a literal gigaton of programmers good enough to write poor quality Windows/Mac GUI apps, and a lot fewer programmers that can build something robust, and can afford to research how to do things right. That sort of stuff bites into the profit margins, after all. Ship early, and ship often, right?
The above isn't intended as snarky, by the way. It is an observation over the last two or three decades. In my experience, the quality of software is increasingly dual: you have a small number of brilliant tools -- and that includes both proprietary stuff like Adobe Photoshop, and open source stuff like GCC --, but the median quality is going down. Code is increasingly buggy and wastes resources.
that gives them coverage for 90% of desktops, who cares about the 2% [desktop] share of Linux?
True. The same can be said for anyone trying to do HPC on Macs or Windows: they're laughed out. Heck, even Microsoft prefers Linux servers on their Azure platform.
On the other hand, Adobe as a company rejected Linux outright, for reasons they never stated publicly. They even refused to port Macromedia Software browser plugins to Linux, after they acquired it, and did an utterly piss-poor job with their Flash browser plugin. That is similar to how Microsoft pumped millions into a couple of HPC clusters, just to get them into the Top-500 list; they knew nobody doing HPC would be fooled by their efforts. Some things are just political/personal to the business leaders.
A major reason why the device driver situation on Linux has become better, is the efforts by the kernel developers (the Linux driver project and the Linux Foundation
efforts), allowing the manufacturers to spend or risk very little to get Linux support for their devices (by contacting developers to do it for them. The true underlying problem has been that companies are unwilling to treat Linux developers as equals, like they would another business, but insist on treating them as end users.
A very similar problem is occurring with the various
Right to Repair movements. Manufacturers and sellers are not treating themselves as sellers, but as licensors, and their customers licensees, who do not really own what they buy. This is a business culture problem.
I am all for competition, and businesses making profit. What I do not like, is when politics (especially personal politics by the CEOs and other nitwits, who only really know money) is mixed in with it. Software patents, and a lot of the patent system mess, is one of those. (That might start a flamewar, but fact is, the purpose of the patent system is to ensure new innovations are marketed; not to stop competing products from entering the market, as they are predominantly used today.)
A large part of opposition to Linux, the belief that you cannot sell software on Linux, is based on the decade and half of expensive propaganda by Microsoft. They spent a
lot of money to make people believe Linux is a communist anti-market anti-business trick. Unfortunately, many people who have never tried to sell Linux software, still believe it today. (I see the effects of this daily even here in Finland, the birthplace of Linux. It is like a huge magic trick pulled over the general population.)
I have sold Linux software myself. A friend does so still, and has done it for a few years now. If you haven't, but think it cannot be done, just shut up: your belief has no basis in reality. If you have tried, but failed, then we can talk (why it failed, and how it could have worked).