Why Linux is Becoming Impossible for Audio Developers to Ignore

[TechHaus]

Ai response, wow.

[TechHaus]

One of my favorite Youtube tech channels just released this 2 hours ago:

I Left Windows a Year Ago... Was It Worth It?

[Grizzellda]

Wow, you guyz have gotten intellectual in this thread! Long posts, university style essays!!!

I like to keep things brief, to the point...

I am totally willing to pay a reasonable price for QUALITY Linux apps. No issues, I truly feel that software devs gotta earn an income. Capitalism, ha ha !

Also, said it before...a loud shout out to all those companies, they, (and "we"), know who they are, doing native Linux stuff. NATIVE!!! is the thing here, I reckon.

And what about MuTools, Grizzellda still keeps wundering??

[kerfuffle]

Where can I find a comprehensive step-by-step article that describes how to port my plug-ins to Linux?

[audiojunkie]

Where can I find a comprehensive step-by-step article that describes how to port my plug-ins to Linux?

What format are you wanting to port to: VST3, CLAP, LV2?

What framework are you wanting to use for porting: JUCE, DISTRHO Plugin Framework (DPF), etc?

Assuming that you are using VST3, you have several options, since the VSTSDK already supports Linux. The key is to use one of the cross platform frameworks, such as JUCE, DPF, etc. For the most part, you would then compile the plugin natively on Linux.

https://lwn.net/Articles/890272/

https://jatinchowdhury18.medium.com/bui ... f8937dbac3

https://linuxaudio.dev/

https://steinbergmedia.github.io/vst3_d ... g-ins.html

https://justinmalinow.com/blog/getting- ... evelopment

https://juce.com/

https://juce.com/tutorials/tutorial_new ... r_project/

https://lv2plug.in/book/

https://github.com/sjaehn/lv2tutorial

https://medium.com/@12264447666.william ... 8d6195bdca

https://reillyspitzfaden.com/posts/2025 ... b-actions/

https://distrho.github.io/DPF/

https://deepwiki.com/zamaudio/zam-plugi ... ild-system

Hopefully some of this will give you some insights.

[Marvinh]

Where can I find a comprehensive step-by-step article that describes how to port my plug-ins to Linux?

Finding a good cmake template is half the battle.

VST3 VSTGUI:
//vst3 project generator linux mac os script
https://github.com/steinbergmedia/vst3p ... ter/script

JUCE:
//for juce
https://github.com/sudara/pamplejuce

IPLUG 2 is not 100% there I don't think I dont have much news on that.

[stoopicus]

I love that this thread devolved, on its own, into a great illustration of why developers rarely take Linux seriously.

And again, I say this as a daily Linux user, not a hater at all.

[audiojunkie]

I love that this thread devolved, on its own, into a great illustration of why developers rarely take Linux seriously.

And again, I say this as a daily Linux user, not a hater at all.

If you "aren't a hater", then why do you love that this thread devolved. It only "devolved" because of a single person. Literally no one else is saying anything negative.

[kerfuffle]

I asked because I wouldn't mind making Linux builds of my plug-ins, but you'd think that Linux users who desperately want developers to make their software available for Linux would make it *as easy as possible* for the developers to do so...

For example by providing a guide that explains stuff like what's a good distro to build on, are all these Linux users only on Intel or also on ARM (or PowerPC lol), does that mean I need to provide two binaries, do Linux users expect an installer or are they comfortable copying the .so files into the right places, what's the preferred compiler, what sort of GPU acceleration can I expect users to have or not have, and so on.

The easier you make it for developers who are new to Linux (or like myself who last developed for Linux 25 years ago), the less resistance there is to switching. (linuxaudio.dev was helpful but they still assume the developer is an experienced Linux user.)

[audiojunkie]

I asked because I wouldn't mind making Linux builds of my plug-ins, but you'd think that Linux users who desperately want developers to make their software available for Linux would make it *as easy as possible* for the developers to do so...

For example by providing a guide that explains stuff like what's a good distro to build on, are all these Linux users only on Intel or also on ARM (or PowerPC lol), does that mean I need to provide two binaries, do Linux users expect an installer or are they comfortable copying the .so files into the right places, what's the preferred compiler, what sort of GPU acceleration can I expect users to have or not have, and so on.

The easier you make it for developers who are new to Linux (or like myself who last developed for Linux 25 years ago), the less resistance there is to switching. (linuxaudio.dev was helpful but they still assume the developer is an experienced Linux user.)

I would advise sticking to x86-64 (Intel/AMD). Don't worry about ARM for desktop right now. Most developers just stick to Intel/AMD. I would advise compiling on an old version of Debian. So for example, Debian 13 is the current version. Compile on Debian 12. Most libraries are backwards compatible, so you cast the largest net over the most distros by doing this. Since most people use Debian/Ubuntu, it's usually a good idea to create a .DEB for one of your binaries. For the rest of the distros, copy the binaries into a Zip file along with a Readme that tells where to place the binaries. A good example of this would be The Wave Warden's Oden 2 packages:

https://thewavewarden.com/pages/odin-2

Instead of 600+ distros with 600+ compiled binaries, you have just two. Linux users have no problem copying .so files to the right locations. Unfortunately, I'm not a programmer. So, while I can use Make and compile an application, my coding knowledge doesn't go too far beyond what I am telling you. I do try to provide as much information as I can though.

[stoopicus]

I asked because I wouldn't mind making Linux builds of my plug-ins, but you'd think that Linux users who desperately want developers to make their software available for Linux would make it *as easy as possible* for the developers to do so...

This is a great point. Linux makes up about 4% of the desktop market and likely much less of the music software sales market. If linux users want developers to spend even 4% of their time on linux support they need to give them a reason to do so.

Linux users should be essentially begging developers to support them and celebrating the ones that do, even partially or imperfectly.

[TechHaus]

I asked because I wouldn't mind making Linux builds of my plug-ins, but you'd think that Linux users who desperately want developers to make their software available for Linux would make it *as easy as possible* for the developers to do so...

This is a great point. Linux makes up about 4% of the desktop market and likely much less of the music software sales market. If linux users want developers to spend even 4% of their time on linux support they need to give them a reason to do so.

Linux users should be essentially begging developers to support them and celebrating the ones that do, even partially or imperfectly.

I mean every new product thread on here has folks begging for Linux versions, and when there are Linux versions, they get tons of thanks! Surely you've seen these, posts, no?

And from the dev from Auburn Sounds:

Also Linux is not that small a market, with us plugin vendors estimating 5% to 10% of music sales on this platform. It also much less troublesome than macOS to update for, so always a pleasure to maintain a minimum of Linux compatibility if you don't have too much dependencies (now, the Studio One and Wayland news is probably going to be a interesting...). It can't be overstated how huge the arrival of Studio One is on this platform.

https://linuxmusicians.com/viewtopic.ph ... 67#p160867

A+++ awesome dev, who also have their own plugin framework that keeps getting updated. They just added a new preset browser and mouse wheel stuff, for example.

https://github.com/auburnsounds/dplug

There's a wiki and discord and whatnot if you need help.

[Tiles]

I am totally willing to pay a reasonable price for QUALITY Linux apps.

Sure. But would you also be willing to spend a significant part of your lifetime developing and maintaining a high-quality Linux application across what effectively behaves like 600+ different platforms?

There is no such thing as "the Linux", unfortunately. This alone reduces the often-quoted 4% market share to maybe 3% in practical terms. And even that is fragmented across different library versions, package managers, audio stacks (PulseAudio, ALSA, PipeWire), kernel versions, and rolling versus stable release models.

Out of those roughly 3% of desktop users that you can realistically reach, only a fraction are actually using Linux for music production in the first place.

On top of that, a VST effect is already a niche product within the broader VST ecosystem itself.

So we are effectively talking about a fraction of a fraction of a fraction of the overall user base that would actually be interested in the product at all, not the most optimistic 4%. You quickly end up with a much smaller effective market while facing significantly higher development, testing, and maintenance costs.

Most developers who support Linux end up providing Flatpak or AppImage packages. But even then, they only cover part of the Linux ecosystem. And even with standards like VST3, things are not as straightforward as on Windows. On Linux, it is effectively a container format that depends on a wide range of system components to work properly. In short: it does not just run everywhere out of the box.

Supporting Linux is not just about getting the software to run. It is about testing, maintaining, and supporting it across a wide range of environments.

For comparison, building a Windows installer typically takes me around ten minutes, while getting the Linux version into a usable and distributable state often requires days of research and troubleshooting. I just had this before a few days again.

This applies not only to commercial software, but also to open source: the additional effort still needs to be justified in terms of time and sustainability.

We developers are not the bad guys here. In the end, multiplatform support has to pay for itself.

From a developer perspective, the goal is not more market share, but a sane level of standardization that makes sustainable development possible across the ecosystem.

[TechHaus]

I am totally willing to pay a reasonable price for QUALITY Linux apps.

Sure. But would you also be willing to spend a significant part of your lifetime developing and maintaining a high-quality Linux application across what effectively behaves like 600+ different platforms?

There is no such thing as "the Linux", unfortunately. This alone reduces the often-quoted 4% market share to maybe 3% in practical terms. And even that is fragmented across different library versions, package managers, audio stacks (PulseAudio, ALSA, PipeWire), kernel versions, and rolling versus stable release models.

So are you under the impression that u-he and audio damage have 600 different installers for the different platforms?

Or did one suffice?

Let me check. Yes, they just label the downloads "Linux".

But how, if things are as you claim?

[Tiles]

No, that is not the claim I am making. We talk about the market share. And the fragmentation.

The 4% refers to overall desktop market share, which is fine as a high-level statistic.

The point is that this does not translate into an equally usable development target.

Once you account for fragmentation, incompatible system environments, and real-world support constraints, the effectively addressable Linux user base for a given application can be significantly lower, in some cases closer to 1–2% of the total desktop market. Or even lower.

So we are not talking about “wrong numbers”, but about different layers of reality: overall market share versus realistically supportable and testable market share for a specific product.

And that distinction matters a lot when you have to decide where to spend development and maintenance effort.

Let me check. Yes, they just label the downloads "Linux".

A vst3 instrument?

They label it "Linux" because that's the distribution target, not because it's a single uniform platform. I edited my above post to make clear that even VST3 will not run on every linux distribution. A single download label does not equal uniform compatibility across all Linux environments.

I have once developed a game with a Linux binary too. Made with Unity. It runs on Ubuntu 12.04. And nowhere else. This is my "market" for this game on the Linux side. I labeled it "the Linux version".