You can blame Linux distros as a whole, for being obsessed with dynamic linking shared libraries.
The Linux kernel itself has a well publicized policy of not breaking user space and binary compatibility, but pretty much all distros regularly break binary compatibility, they require software to dynamically link to os provided shared libraries, and they don't allow statically linked programs to be distributed using their package managers.
Packaging and distributing software for windows or macOS is really easy.
Doing the same for Linux, particularly desktop applications, is a huge pain.
It's a point that Linus Torvalds has often bemoaned[0][1].
Packaging software for Windows is clearly a pain, because every time I install a game I get a download, followed by a launcher, followed by one or several MSVC++ runtimes, then another download, then some kind of extraction phase, a restart and then a menu. Unless I'm one of the first people to download the game, of course, because then I get a popup stating that the file I downloaded can't be trusted and that I should delete it.
It's an automated Rube Goldberg machine. Linux used to have these as well! I remember clearly the hacky automated Java 6 install script and the VirtualBox drivers that came as a several executable hundred megabytes in size.
You can static link if you want. You need to watch out for core system libraries like glibc (just like you need to watch out for Win7/8.1/10/11 on Windows) but that's about it.
I mean you can put up a `.deb` with a statically linked binary on your download page right? You can also use stuff like App Image right? It's not like nobody has ever put a go binary into a .deb before.
I don't think comparing "state of packages got off of apt" to "state of downloaded installers for Mac/Windows" is an apples to apples comparison.
Yep, several projects I know are leaning into AppImage to get around dealing with installers. The biggest problem with AppImage is that it _is_ just a binary, so things like desktop shortcuts don't come with it. AppImageLauncher does solve this issue (and create a "canonical place" to place your programs, like /Applications/ on mac).
I do agree it's fragmented and frustrating where we've ended up for installers. My main critique is more that the state of linux packaging _isn't_ what thunderbird is doing here.
You can statically link your apps just fine as long as you follow the license for the libraries you're linking (in the case of libc, the LGPL.) Before you get upset about this Windows does the same thing with their C runtime (although the license terms are different.) Ever seen the installer for it when you install another app? That's exactly what's going on.
Go nearly always does this for example (although in some version they switched to dynamically linking to glibc for the stub resolver) and you can take statically linked go binaries and copy them to totally different OSes as long as the architecture is compatible. I remember taking a copy of syncthing and copying it between my Android and a Raspberry pi at one point (or maybe it was a kindle and a raspberry pi) which run totally different OSes and it worked just fine (ignoring the Android stupidity of course.)
The Linux kernel itself has a well publicized policy of not breaking user space and binary compatibility, but pretty much all distros regularly break binary compatibility, they require software to dynamically link to os provided shared libraries, and they don't allow statically linked programs to be distributed using their package managers.
Packaging and distributing software for windows or macOS is really easy. Doing the same for Linux, particularly desktop applications, is a huge pain.
It's a point that Linus Torvalds has often bemoaned[0][1].
[0]: https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_W...
[1]: https://news.ycombinator.com/item?id=8379139