The lack of pro-audio software is definitely a thing. Mixxx is pretty good though for DJing. It's better than most of the rest of the pro-audio landscape on Linux. There are now also pretty good DAWs (Bitwig, especially).
Releasing binaries is still a PITA for Linux. That's one of the main reason it has so little support from closed source consumer software. If you care, see my comment history on my company dropping Linux support for a pro-audio app, even though our software works on Linux.
But for development tools, it's you-win-some-you-lose-some. There are some development tools (the Valgrind suite, for example) that I still miss after mostly switching to macOS. Going from Linux to macOS also means losing great tools.
Most of the time those packages, or the build files for them, are contributed by the distributions themselves, or avid users of those distros. (Reference: I have multiple software projects I've created that are a part of every Linux distribution. I've never packaged any of them myself.) Even big enterprise companies usually work directly with the distros under NDA, and the distros produce the packages.
That works for FOSS, but not for smaller closed-source consumer apps. And it's not just building, it's also testing and debugging. It's just not tractable for a small company to test on dozens of different distros / versions for such a small percentage of users.
they seem to providing their own builds. And - if you wrote your build system reasonably (e.g. CMake, properly check for dependencies etc.) - then building on different distros would not be much of a headache. You may not provide 40 different binary packages, and they may only fit recent versions of the popular distributions, but - after you set this up once, I wonder if it isn't just running a script after you have your versioned source tarball release.
Literally most of the packages on the page you link there explicitly say that they're maintained by other people. The author seems to maintain an RPM and a DEB setup, which is already more than most. And my point is absolutely not that some people don't go nuts there, but that's not where or how most Linux users get their software. It's mostly coming from stuff packaged by the distributions.
And I am sure that's how most open source packages on Linux are built. Again, I spent a lot of time in that world. (Former KDE core developer, former employee at SAP Linux Lab, friends working at all major distros, have a bunch of my stuff in every distro, talks at lots of Linux conferences, etc.)
Building really isn't the problem. It's testing and supporting. Building is relatively easy. But you can't just ship commercial packages without testing them. Pulling out a Debian 11 VM because someone's having problems with your software there under Wayland, but not X11, but it seems to work in Sid... Again for the 0.01% of your customers using that configuration, ... it's hard. And it rarely makes economic sense unless you've got a disproportionate number of users on Linux, or a ginormus user base. You can't assume because something works on Arch Linux that it also works on Mate. Or that something on Ubuntu works on Debian. Or Redhat on SUSE. And then your users may have any of 3-4 versions of those installed. By the time you get to a specific configuration you're dealing with often debugging things for a single-digit number of users.
Windows is about 66% of our customers, macOS about 33%, Linux about 1%. On Windows we currently only test on x64 for Windows 10 and Widows 11. On macOS we test 4 configurations. Each Windows configuration we test is 33% of our users. Each macOS configuration about 8%. Linux is starting at 1%, and previously we tested only one configuration, which was already 8x more costly than macOS. But there were a lot of complaints from people using other distros / versions, which resulted in anger, bad reviews, claims that we don't understand Linux...
To get reasonable coverage of the Linux desktop landscape, we'd need to test probably 20+ different configurations, meaning each of them would cover about 0.05% of our customers. The QA tests take multiple hours to run through. That makes supporting a Linux user a staggering 160x more expensive than supporting a macOS user, and 660x more expensive than supporting a Windows user.
Again, you need either a giant user base, or a disproportionate number on Linux (which is the opposite of true in pro-audio) to even hit break-even on Linux users.
dunno but for example you got more than one audio stack on linux so they should at least test both, with different hardwares, etc. Not sure flatpak would help here...
I was talking about about the problem of having to package software per distro.
Regarding audio, if you decide to target several audio stack yes indeed. I hope this get eliminated by Pipewire really soon. It's already the case as a end user (Pipewire replaces Pulseaudio, Jack and the userland part of Alsa) but I don't know if all use cases are covered yet.
If I'm not mistaken Pipewire started from the need to be able sandbox multimedia streams in Flatpak , so I guess Flatpak might be indirectly helping here :)
Regarding hardware it's the same problem for any operating system though, testing with all hardware can be tricky for a small company.
Releasing binaries is still a PITA for Linux. That's one of the main reason it has so little support from closed source consumer software. If you care, see my comment history on my company dropping Linux support for a pro-audio app, even though our software works on Linux.
But for development tools, it's you-win-some-you-lose-some. There are some development tools (the Valgrind suite, for example) that I still miss after mostly switching to macOS. Going from Linux to macOS also means losing great tools.