I can also imagine a company like Wacom fighting cheap Chinese copies - I can't imagine persuading the business folks to make the copycat's life way easier by open sourcing the logic.
As long as Linux says it's either mainline or the highway, well, companies will be reluctant to put in the resources I'm afraid.
You may have thought about trade secrets.
Nevertheless, any trade secrets which are needed in the interface that is necessary for a device to be used by its owner, can easily be reverse engineered by someone with enough money, i.e. by all the important competitors.
So hoping that not providing documentation for the interface of your devices is a method to fight your powerful competitors is an illusion.
This method works only against your normal customers, by preventing them to find reasons to buy more of your products, for applications that you do not support, e.g. use under other operating systems.
Trade secrets are useful and they may be effectively protected when they do not concern the normal operation of a product, e.g. when they are used during the fabrication of a product.
But you don't always have the right to use them, or share them.
If company A owns a patent, and company B buys a license, company B may not have the rights to release their code to GPL and share it into mainline linux.
Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules.
The less activist stance is simply that maintaining a stable ABI requires either accumulating lots of backwards compatibility layers over time, or to stop improving certain parts of the kernel. Neither option has won out over the current situation.
I am all for open source drivers. But I would prefer working proprietary ones, if the alternative is buggy as hell.
Than I had to buy a new one in 2014. I told myself, no more ATI/AMD, let's buy one with an NVIDIA card. That card is a Quadro K1100M in a HP ZBook 15. The latest binary driver supporting that card is version 418. The newest driver is 510. Apparently the next Ubuntu 22.04 is shipping with kernel 5.15 and there is a 418 package for that kernel. I wonder what the latest compatible kernel will be. Is my laptop going to die of old age before I have to replace it because I won't be able to use its graphic card anymore? BTW, the open source driver doesn't work well. I don't check it again every year. All I remember is that I couldn't work with that the last time I tried.
On the other side, my USB scanner from the 90s still works perfectly well. Same for my mouse (I don't plugin it in every year) and any disk / pendrive I care to use.
It was not official maintenance, it was just an unmaintained open-source device driver found somewhere, which was needed for my hardware. I had to update it after every Linux kernel release in order to be able to continue to use it.
What was annoying was not the fact that almost every kernel release required modifications in the device driver, but the lack of a documentation about the kernel changes that is usable by someone who does not follow every day the kernel mailing lists.
The 3 main reasons which broke the device driver after each new kernel release were:
1. Some reorganization of the kernel header files, which moved some definitions to other header files, which were not included in the previous driver code.
2. Some structures had members added or deleted
3. Some functions had parameters added or deleted
Point 1 was easily solved by a search through the entire Linux source tree.
When structure members or function parameters were deleted, it could be hoped that it is enough to also delete them in the device driver, even if in some cases some earlier-executed initialization code had to be modified to make everything work like before.
The worst was when there were new structure members or function parameters, as there was no way to guess which values should be put in them.
Because, at least then, but I suppose that nothing has changed, there was no centralized document with the changes that need to be applied to drivers, the only way was to search the kernel mailing lists, to discover where was the patch that changed that structure or function.
That search was not too difficult, but I have never seen a message with the changes that will also explain what values must be put in the new members/parameters.
So after finding who did the changes, the mailing lists had to be searched for messages with the same authors or similar subjects to find any relevant information.
In many cases the search was too long, so it could be simpler to pass to the final solution of anything, i.e. to reading the source code of various kernel subsystems or of other device drivers, where the offending structures or functions were also used, to discover what values might be expected.
None of these activities was too difficult, but they were quite time-consuming.
What I would have expected is that anyone who makes a kernel change like that, would also write a short migration guide, saying e.g. that whoever used the previous function with 5 parameters now has to put the X value in the 6th parameter to obtain the previous behavior.
With the right documentation of the kernel changes, I could have updated the device driver in a couple of minutes every time, but, unfortunately, I have never seen such documentation.
(The "ChangeLog" of the kernel is usually completely irrelevant for device driver maintenance, because it does not list the symbols affected by changes, so when your device driver compilation stops on function or structure XYZ, you cannot search it in the ChangeLog to discover which is the change that affected it.)
Using an online editor, Mark a struct for changes…call a merge meeting with all affected module owners and everyone changes their code right there and then.
Even using email to talk about code is stupid and an unnecessary hurdle.
read code (trust)
modify code (fix)
redistribute (share)
redistribute modified code (improve)
Sandy Bridge (GPU HD3000) from Intel:
Linux OpenGL 3.3
Windows OpenGL 3.1
MacOS OpenGL 3.2 // I'm not sure!
Android "Google/Linux" failed here because Google didn't pushed neither ARM nor Qualcomm. This and separately maintained modifications through manufacturers are the reason that Android devices cannot be trusted and struggle with updates. You cannot bump the Linux kernel if you don't get an updated driver. And you cannot cannot bump the Google part because of the manufacturer patches which weren't upstreamed.
Android is an example of how open-source collaboration should not be done. Even Jolla failed and use closed-source drivers, which meant the need to remain ABI compatible, which meant the cannot upgrade the kernel, which meant the cannot fix issues within BTRFS. Purism avoided that all with much hard work together with NXP! They just need to make the device smaller and cheaper. Sorry Purism. But 800 bucks are even for a nerd/developer-device expensive. Valve did a clever thing with using AMD for the Steamdeck.
Noteworthy: Linux and GLIBC provide stable APIs and ABIs for the userspace, hopefully also Systemd. External developers and users rely on the promise of API and ABI stability.
The lack of a stable ABI makes out-of-tree harder to maintain, but the whole point of Linux is that you don't need to maintain them out-of-tree.