My experience is that the Linux audio APIs have been so volatile that I often can’t run older audio software, even when I have access to the source code.

I have actually composed and recorded music with open-source software, but the cost of doing so was very high, so I switched to proprietary software. Even worse, the open-source software for various reasons has had interoperability problems—you can’t export in standard formats, or that kind of thing. With proprietary software, I was less tied down, since I could export data from one program to another and continue working.

So I’m slowly working on converting the old songs I wrote with open-source tools into standard formats.

The ALSA API (the fundamental device driver layer) hasn't changed in any significant way in more than 20 years. There was one trivial change that might require a 1 line change in a program that happened to use that particular call, but not all Linux audio apps did so.

I don't know what you mean by "cannot export in standard formats", unless you're referring to something like AAF.

AAF is a closed-source proprietary standard for "session files" that fundamentally relies on utterly closed Microsoft APIs. There are some incomplete open source implementations that use a GNU efffort to reimplement those APIs but AAF is also the prime example of design-by-committee. I will never put time into trying to support AAF. Note also that AAF support is missing in major DAWs and users need to rely on 3rd party translators such as Chicken Systems AATranslator (RIP).

If you're referring to standard formats for audio files (WAV, AIFF, CAF and more), then I really don't know what you're thinking of.I cannot think of any open source audio project that has problems with exporting to "standard formats".

ALSA may not have changed, but programs variously have used ALSA, ESD, JACK, OSS, PulseAudio, and aRts. Depending on your hardware, some of these options have been variously unusable at points--too many developers assume that you have a hardware mixer, for example, which is true for standard PC audio output but not true for any pro interface I have ever used (even the dirt cheap ones). At various points, I ended up with audio that only worked with exclusive access. I tolerated it for a while but now I consider it a dealbreaker.

I'm 100% willing to pay Apple to make this problem go away for me. Core Audio is an amazing API.

For cannot export in standard formats--talking about MusicXML. Until a couple of years ago I also had problems listening to music on my Linux system; I think it was because of some patent licensing issue.

All of the above APIs except ALSA run on top of ALSA, except OSS which was deprecated more than 20 years ago. The CoreAudio API has changed just as much in that time period.. there are huge chunks of the CoreAudio API that existed back in 1999 that no longer work or even exist.

Also, note you can't use the audio APIs from macOS "classic" on macOS/OS X (and never could - Apple banned it from the start, so every single audio app that existed for macs pre OS X had to have its audio I/O completely rewritten. Apple didn't pay for this - 3rd party developers did).

I write pro-audio/music creation software for a living, and I can assure you that from this perspective, CoreAudio is definitely not an amazing API. That's without even taking into account the differences between CoreAudio on iOS and macOS.

The only Linux distributions that had problems playing patent-protected formats over the last 20 years were the ones that stuck to a strictly libre software policy. If you picked one of them (e.g. Debian), it's hardly Linux' fault that you chose a distribution one of whose raison d'etre's was to exclude any non-free formats of any kind. I used RedHat starting in 1997 and it never had a problem playing mp3 files.