Future of Windows in pro audio

[ampetrosillo]

I'm not shifting anything. You are basically saying that there is little software for Linux because it's too hard and a technical nightmare. I'm saying that this is not exactly true, it can be truer for older codebases which require a significant rewrite, but not for new stuff which is often multiplatform right from the start (those sane development practices, hey?). The APIs rarely shift. Also, if you must insist on proprietary software, you can't complain if it doesn't fit an open source model. (The free software people would rather it all died out anyway). All this talk of PipeWire, ALSA, Jack, etc. is a huge straw man. There have been various competing standards but that's not what stopped Linux from becoming "relevant". You are shifting the goalposts, not me. When I say that it can be done, you respond condescendingly. Anyway, I'm tired. Au revoir.

[ampetrosillo]

This is why SSL shut down Harrison on Linux....

SSL haven't shut down Harrison on Linux. Mixbus is still available for Linux.

But not their plugins any longer.

[Tiles]

I'm not shifting anything. You are basically saying that there is little software for Linux because it's too hard and a technical nightmare. I'm saying that this is not exactly true, it can be truer for older codebases which require a significant rewrite, but not for new stuff which is often multiplatform right from the start (those sane development practices, hey?). The APIs rarely shift. Also, if you must insist on proprietary software, you can't complain if it doesn't fit an open source model. (The free software people would rather it all died out anyway). All this talk of PipeWire, ALSA, Jack, etc. is a huge straw man. There have been various competing standards but that's not what stopped Linux from becoming "relevant". You are shifting the goalposts, not me. When I say that it can be done, you respond condescendingly. Anyway, I'm tired. Au revoir.

We’re still talking past each other on the same core distinction.

No one is claiming Linux is “a technical nightmare” in general, or that new cross-platform development is not possible. The point has consistently been about the additional cost of supporting Linux as a target platform in real-world maintenance, especially due to distribution variance, packaging, dependency management, and system-level integration.

Those factors do not disappear for modern codebases; they are handled differently, often by constraining support scope or introducing additional layers. That is a trade-off, not a strawman.

This is similar to how, in project management, a feature might be technically feasible but still not viable at scale due to increased coordination cost, support burden, and long-term maintenance overhead.

The disagreement here is not about whether these costs exist, but about how significant they are in practice when supporting Linux as a target platform.

This is the real underlying issue in this discussion: not whether Linux can be targeted, but what the cost of doing so is. These are observable constraints in software development, reflected in how platforms are actually supported and adopted in industry, regardless of opinion or interpretation.

Whether that trade-off is sufficient to influence adoption is the actual point of discussion. It is not a matter of “it can be done, therefore overhead is irrelevant”.

[VariKusBrainZ]

In the battle of egos its the innocent bystanders that suffer

[uOpt]

This is why SSL shut down Harrison on Linux....

SSL haven't shut down Harrison on Linux. Mixbus is still available for Linux.

But not their plugins any longer.

Yes, that, and they also refuse to answer questions about it.

[BBFG#]

This is why SSL shut down Harrison on Linux...

And this is why I uninstalled Mixbus and stopped updating them.
It's been my personal experience that once an iLok product has been attached, it spreads like a parasitic virus.

[Tiles]

No need to speculate.

https://support.harrisonaudio.com/hc/en ... -for-Linux

They explicitly state that the decision was due to a low volume of Linux licence purchases.

That is exactly the point: if the return is not there, the additional development and maintenance effort does not justify continued support. Market outcome and technical overhead are not separate explanations here, they reinforce each other.

[BBFG#]

Yeah, I'm just glad they were honest enough to tell me that so I could stop wasting anymore time with them.

[ampetrosillo]

No need to speculate.

https://support.harrisonaudio.com/hc/en ... -for-Linux

They explicitly state that the decision was due to a low volume of Linux licence purchases.

That is exactly the point: if the return is not there, the additional development and maintenance effort does not justify continued support. Market outcome and technical overhead are not separate explanations here, they reinforce each other.

Wrong. The big effort had already been put. The plugins were stable and mature. They just either reassigned Ben Loftis or they fired him outright.

[Tiles]

No need to speculate.

https://support.harrisonaudio.com/hc/en ... -for-Linux

They explicitly state that the decision was due to a low volume of Linux licence purchases.

That is exactly the point: if the return is not there, the additional development and maintenance effort does not justify continued support. Market outcome and technical overhead are not separate explanations here, they reinforce each other.

Wrong. The big effort had already been put. The plugins were stable and mature. They just either reassigned Ben Loftis or they fired him outright.

That does not contradict the point being made. It actually reinforces it. It shows that the ongoing cost of maintaining the product was no longer justified by the revenue.

If there were basically no ongoing costs, they would have just kept it alive. They didn’t.

Initial development being done doesn’t change that. Maintenance is where a lot of the actual work and overhead sits: updates, compatibility, support, packaging, keeping it running across changing systems.

Harrison explicitly says low sales. That just means the return didn’t justify the ongoing effort.

Reducing that to “they just reassigned someone” misses the point. This is cost vs return. And somebody who claims experience in project management should be aware that this is one of the basic decision-making principles in that field.

And it’s not a one-off. This is exactly how you end up with the ecosystem we have.

[ampetrosillo]

In which way do you think your response rebukes mine? Any platform you support will need dedicated staff. They probably have somebody for macOS and somebody else for Windows. Why should Linux be easier than those two OSes? You will always need a third person. If you don't sell enough Linux licenses to justify the expense, you stop supporting Linux. (Very subjective too).

[Tiles]

You keep attempting to frame this as a binary choice between 'having staff' and 'not having staff,' but that is a false dichotomy that misses the actual technical and economic reality.

You are once again using a straw man argument to avoid addressing my actual point. My point is not about whether a platform requires 'dedicated staff.' That is a triviality. You are trying to debate whether someone is assigned to a task, whereas I am talking about the disproportionate engineering effort required for Linux compared to Windows.

You are conflating headcount with workload intensity. There is a massive difference between an engineer spending a few hours a month on stable Windows updates and that same engineer spending forty hours a week fighting Linux fragmentation, managing diverse packaging formats like DEB, RPM, or Flatpak, and resolving constant shifts in system-level dependencies.

This isn't 'subjective.' It is the objective reality of developing for a fragmented ecosystem that I face on a daily basis. On Windows, you deal with a relatively stable ABI and a unified deployment model. On Linux, the maintenance overhead is significantly higher because the environment itself is constantly shifting under your feet.

To bring it back to the economic reality: The decision to drop a platform isn't based on whether you have staff. It’s based on whether the revenue covers the actual engineering man-hours required to keep it functional. If the maintenance overhead outweighs the return, the platform is cut. Stop reframing the discussion and address the technical complexity I am actually describing.

[Largos]

You keep attempting to frame this as a binary choice between 'having staff' and 'not having staff,' but that is a false dichotomy that misses the actual technical and economic reality.

You are once again using a straw man argument to avoid addressing my actual point. My point is not about whether a platform requires 'dedicated staff.' That is a triviality. You are trying to debate whether someone is assigned to a task, whereas I am talking about the disproportionate engineering effort required for Linux compared to Windows.

You are conflating headcount with workload intensity. There is a massive difference between an engineer spending a few hours a month on stable Windows updates and that same engineer spending forty hours a week fighting Linux fragmentation, managing diverse packaging formats like DEB, RPM, or Flatpak, and resolving constant shifts in system-level dependencies.

This isn't 'subjective.' It is the objective reality of developing for a fragmented ecosystem that I face on a daily basis. On Windows, you deal with a relatively stable ABI and a unified deployment model. On Linux, the maintenance overhead is significantly higher because the environment itself is constantly shifting under your feet.

To bring it back to the economic reality: The decision to drop a platform isn't based on whether you have staff. It’s based on whether the revenue covers the actual engineering man-hours required to keep it functional. If the maintenance overhead outweighs the return, the platform is cut. Stop reframing the discussion and address the technical complexity I am actually describing.

The actual reality is it's smaller teams doing Linux releases and larger companies not, so your logic doesn't really align with real life.

[Tiles]

Nice red herring. You are confusing technical possibility with professional viability. The reality is these companies do need to make money. This is called a market. A small hobby team or an open-source developer can afford to spend resources on a port. Especially since many live for and from the open-source spirit, making a Linux version a logical choice for them. But a commercial company that wants to be profitable cannot.

Professional operations don't operate on 'willpower.' They operate on standardized reliability and profitability. The fact that small teams can produce quick-and-dirty ports, or also maintain proper ports based on volunteers, while the vast majority of commercial entities decline to provide full support proves my point: the professional maintenance overhead required to meet industry standards is so massive that it often fails to meet the ROI requirements. It's not a lack of will. It's the high cost of meeting professional standards and maintenance in a fragmented ecosystem.

Or shorter and easier to understand: a company needs to make money.

The reality is simply this: much of the software is missing on Linux. We aren't debating whether that's true. We are discussing the reasons why it is. As an open-source developer who provides ports myself, I deal with these reasons and realities on a daily basis. I am describing the technical and economic reality that we developers live in. My daily work is shaped by these very realities.

[Largos]

Nice red herring. You are confusing technical possibility with professional viability. The reality is these companies do need to make money. This is called a market. A small hobby team or an open-source developer can afford to spend resources on a port. Especially since many live for and from the open-source spirit, making a Linux version a logical choice for them. But a commercial company that wants to be profitable cannot.

Professional operations don't operate on 'willpower.' They operate on standardized reliability and profitability. The fact that small teams can produce quick-and-dirty ports, or also maintain proper ports based on volunteers, while the vast majority of commercial entities decline to provide full support proves my point: the professional maintenance overhead required to meet industry standards is so massive that it often fails to meet the ROI requirements. It's not a lack of will. It's the high cost of meeting professional standards and maintenance in a fragmented ecosystem.

Or shorter and easier to understand: a company needs to make money.

The reality is simply this: much of the software is missing on Linux. We aren't debating whether that's true. We are discussing the reasons why it is. As an open-source developer who provides ports myself, I deal with these reasons and realities on a daily basis. I am describing the technical and economic reality that we developers live in. My daily work is shaped by these very realities.

Smaller companies like can be profitable whilst selling Linux software but companies can't be? This is some extreme mental gymnastics. I wonder if in your mind, Logic isn't available on windows because it's not seen as a profitable platform