Just to be clear: I consider it to be a good idea to write native apps for GNU/Linux, but first stabilize the APIs so that they stay basically stable for at least 20 years.
This is mostly a UX problem. Many ways to shoot yourself in the foot. Maybe someone could write a linter for checking symbol tables for depending on shared libraries not in the Steam runtime and private symbol use.
But also, compiling everything with dynamic libraries is kind of an interesting side effect of having all the source code in a single context of a distribution; maybe you should always statically compile if you're not part of this system.
>
But also, compiling everything with dynamic libraries is kind of an interesting side effect of having all the source code in a single context of a distribution
Under Windows, this is also done. But there is a difference: changes in a system-wide DLL better are really backwards-compatible.
If there are breaking changes, a new "package" gets introduced with new names for the DLLs. This is why on many Windows systems, lots of versions of, for example, the "Microsoft Visual C++ Redistributable" are installed. Nevertheless, the old versions are still available and get maintained for a very long time at least with respect to security fixes.
Also, the API design under Windows tends to be much more "future-proof". For example, a lot of data structures contain some size information as a first field so that the API can detect which "version" of a data structure has been passed so that future changes can be implemented in a backwards-compatible manner, e.g. WNDCLASSEXA:
Rather: don't try to be compatible with inherently unstable APIs:
https://sporks.space/2022/02/27/win32-is-the-stable-linux-us...
https://blog.hiler.eu/win32-the-only-stable-abi/
Just to be clear: I consider it to be a good idea to write native apps for GNU/Linux, but first stabilize the APIs so that they stay basically stable for at least 20 years.