I'll again snip the core parts that I want to reply.

> Preserve the old methods so that things that used to work keep working...
I have many old applications which compile without modification, or work without re-compilation given all the libraries are available. In Linux, most of the libraries are backwards compatible. Newer versions of the required libraries works with the said application unless the application gets the version and requires a strict version. For these libraries, the packages are always available (e.g. Spotify required libssl-1.0.0 for some time, but they updated it so it works with 1.0.{0,1,2}). Most of the low level libraries are API/ABI stable in Linux world.

> Microsoft does this. Windows userspace apps from 20 years ago still work in Windows 10 today despite the system having advanced significantly since then.

With the help of WindowsOnWindows (WoW32,WoW16), a complete embedded Windows XP image, a great hack called Compatibility Layer and other tidbits which makes things much more complicated and convoluted. Modern Windows 10 contains at least three complete Windows subsystems (or abstract installations) inside. This is hardly a good solution. You can install a complete 32 bit Linux subsystem to achieve the same thing, which is neatly called as multi arch support, and it's much simpler: a set of libraries, nothing more.

> Windows 7 hardware drivers from 10 years ago still work in Windows 10 too.

From my experience 7 to 10 compatibility is not universal. Despite having the same "foundation", 2K drivers didn't work on XP. XP drivers didn't work on Vista albeit advertised as compatible. Same for Vista to 7. 7 to 10 mostly works, and it's better than ever, but it's hardly bulletproof. Hardware vendors used this incompatibilities as an excuse to be lazy and obsolete lots of hardware. Been there, experienced that.

> Bug fixes. Almost never interface changes.

Sound card & TV tuner drivers are notorious because of the timing and direct access they required. Interface and access capability changes killed Creative's hardware EAX in XP to Vista migration IIRC. The cards are buried behind expensive API calls with the expense of latency. Most of the effects have vanished (since the card access in vanished) overnight. I had many of the Creative cards (Live, Audigy, Audigy2), and felt the hurt.

> If I can't update my kernel because it means that my camera will stop working...

Actually, I have a lot of hardware which were deserted by their manufacturers by not updating their drivers and Microsoft refusing to provide even a basic driver. Nearly all of these devices work under Linux, with better performance compared to their official drivers.

I had a printer which had a translation layer binary, but no kernel space driver. This translation layer binary is used as an intermediate CUPS filter to convert the PDF/PCL to printer's own language. The binary didn't conform to POSIX/Linux standard coding practices, and if you didn't provide the exact (old) library it wanted, it forked continuously and didn't work. So your print button was rigged as a slow death button for your PC. I can accept a binary blob, but code it right.

Similarly we have ~1000 servers at work. Some of them are ~10 years old, but they work with most modern distros without complaining. Everything is available, and stable. Even closed source drivers. I don't think the problem is the unstable API/ABI.

BTW, an interface change doesn't affect all the modules. Your module is affected if the interface you talk to changes. You only need to recompile the .o or the source since ABI is not stable due to non-stable API. This is not a real world problem from my experience with said servers.

> The Linux kernel pushes GPL virality further than it should...

I think we need that vitality, but it's another discussion topic, so I'll leave it here.

> 1) you give them your driver code

No, You can provide an .o file if you want.

> you keep doing work to re-certify and re-release your driver

Again, you can just update the .o file if the interface you talk to changes. Not a big deal if you're serious about Linux support.

> (but you could just mainline your driver code, hint hint!)

Unless you implement your magic in the driver (like a WinModem), and you didn't license closed IP from someone, you can open source your drivers. Even Broadcom open sourced their drivers. So it's not something scary if you plan it right.

> 3) billions of people go fuck themselves

The mobile vendors' choice is business related. Even if the code is open, they will obsolete it nevertheless. So, open source driver availability is not a factor here.

I also want to add some more information about this.

- AMD has re-designed its silicon to allow fully open drivers. This is a big gesture towards Linux and Free Software.

- Many high end hardware manufacturers (like Mellanox) open source their software stack (OFED, Subnet Manager) because the code is worthless as an IP without their silicon and hardware.

- Open source drivers prevent obsoletion, but driver cannot manufacture the chip itself, so it has no role on product lifecycle. Upcycling embedded hardware is not trivial for everyday user.