No need for an ABI with open-source drivers because Linux and drivers shall be open source. What matters is the API and modifications to this can be maintained

No need for an ABI with open-source drivers because Linux and drivers shall be open source. What matters is the API and modifications to this can be maintained by upstream. If your hardware drivers aren't open source the promises of the GPL break: read code (trust) modify code (fix) redistribute (share) redistribute modified code (improve) When this model works you get high quality support, performance, over long time. Example: Sandy Bridge (GPU HD3000) from Intel: Linux OpenGL 3.3 Windows OpenGL 3.1 MacOS OpenGL 3.2 // I'm not sure! At time of the hardware availability that didn't matter much but with modern applications and engines it does. If you use Linux and Steam you may benefit from that. 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.