> So far desktop Linux has successfully repelled most commercial software simply by being very difficult to package software for.
A couple of guys could figure out how to package Ardour so that it runs on every Linux distro except NixOS [0]. The idea that its hard to package software in a cross-distro way is pure BS.
[0] NixOS plays games with ld.so, which breaks any packaging that relies on being able to set LD_LOAD_PATH. It's the only Linux distro that does this to my knowledge.
That's an open-source application, which provides two fallbacks if the binary on their website doesn't work for whatever reason: you can compile from source, or you can install from a package provided by your distro, if there is one. Those last two generally aren't an option for closed-source commercial software. Also, since they're not asking about package format I'll assume their package is just a tarball, which works fine for some programs but it's not a proper package in the sense of being something you install from a package manager (and can later upgrade/remove with a package manager).
In general you can probably get a program to run on just about any Linux platform by providing X86 and ARM binaries, statically linking everything, and having fallbacks in case you need to use a certain subsystem (graphics, audio, etc..) and you don't know which one the user is going to want to use.
My experience with software development for big enterprisey customers is that you figure out what distros most of your customers are going to be using, and you test on those distros. That's a fair bit of work, because you might have to release both apt and rpm packages and maintain them, and the test environment is complicated and it doesn't cover the case where some random person wants to run your product on Arch/Mandriva/Gentoo/Mint or whatever. Testing every Linux distro is just not practically feasible, so a lot of people will end up running on platforms you didn't test. Maybe that's fine.
> which provides two fallbacks if the binary on their website doesn't work for whatever reason
I wasn't addressing the fallbacks in any way.
> My experience with software development for big enterprisey customers is that you figure out what distros most of your customers are going to be using, and you test on those distros.
This is their mistake. If you instead understand how applications run on Linux in general, you can do what Ardour (and Firefox and many, many others) do: create distro agnostic binary installable versions. We don't test every distro - we don't need to. We design the package so that if certain extremely minimal conditions are met, the package will run. Firefox has done the same (even if many people use the distro version instead).
Ideally you shouldn't need to test every distro, and everything should "just work" but then you're likely to have users run into bugs and incompatibilities you haven't seen because you didn't test that case.
Distro-agnostic tarballs or self-extracting archives you can just expand and run can work, but it's also not ideal because it subverts the package manager. Package managers allow you to install, remove, and update all the software installed in a system in a consistent way, and a tarball exists outside that ecosystem and lacks its benefits. In that sense, a binary tarball is a second-class citizen that doesn't integrate well with the rest of the system and is probably a security liability. Maybe that's an acceptable trade-off for a few applications, but it should leave a person with a "there's probably a better way to do this" sort of feeling.
The package manager creates an ecosystem of libraries and applications.
If your bundle contains the application and its libraries, it's not a part of that ecosystem, and it makes sense that it exists outside of it. In the case of Ardour, since a number of the dependency stack libraries contain patches that will never be upstreamed (or are for EOL'ed libraries), it makes even more sense.
Yes, there is the risk that if the bundle contains a security issue that has already been updated within the package manager's ecosystem, that's a liability.
But the flip side is that "integrating well with the rest of the system" is precisely what makes 3rd party packaging for all (or even many) distros challenging. I note that most of the efforts to address the situation all essentially bypass the package manager ecosystem (flatpak, for example), and that macOS has used the "standalone application folder except for core system libs" for decades now. The liabilities are real, but small, and seem to be an acceptable tradeoff for software that developers want to run on all (or even many) distros.
That’s missing the point by focusing on a proof of concept. It’s a very long way from showing a mostly-cross-platform OSS tool, to being an ISV that provides technical support and maintenance for a significant commercial application, for millions of nontechnical users, with legacy support, on a mercurial set of cross-platform moving targets.
To a product manager, this looks like a black hole where money and engineering/tech support resources get chewed up with very little value creation to show for it.
It’s also how some very mediocre distributions became enterprise standards for Linux - their value proposition basically being, “we’re not a moving target, and the Fortune 500 can buy a maintenance contract from us”. But this only happened in server land, where the hardware ecosystem isn’t so chaotic.
"significant commercial application": you have no idea how many downloads or users of Ardour there are.
"mercurial set of cross-platform moving targets": precisely what is addressed.
"nontechnical users": that's a new constraint not present in the original description, but probably not much of an issue if you're discussing a specialized tool rather than a "desktop" application.
"hardware ecosystem": completely irrelevant to the case in question.
Looking past the ridiculous hostility; the case in question is why it’s super rare to target Linux for desktop applications. The example offered has none of the trappings of a commercial offering.
By all means, though, all the best with your startup.
It's a 21 year old project that nets in excess of US$200k/year, and has been the basis of 3 commercial spinoff products. Not a large scale commercial project, certainly, but not a startup.
The question wasn't "why it’s super rare to target Linux for desktop applications". It wasn't a question at all, in fact. It was an assertion that it's hard to package 3rd party applications for Linux, and I am asserting that this claim is incorrect.
As to whether or not the packaging situation explains why it's super rare to target Linux for desktop application, that is indeed a different question, with multiple answers.
A couple of guys could figure out how to package Ardour so that it runs on every Linux distro except NixOS [0]. The idea that its hard to package software in a cross-distro way is pure BS.
[0] NixOS plays games with ld.so, which breaks any packaging that relies on being able to set LD_LOAD_PATH. It's the only Linux distro that does this to my knowledge.