Obviously when you frame it like this it sounds insane, but the fact of the matter is that responding to support tickets and triaging bugs have a real, hard cost in $$$ spent. If supporting Linux platforms doubles your time spent responding to support requests and triaging tickets—even if you never fix an additional bug, it could very well be enough to entirely tank the profitability of adding Linux support, well above the value that any additional minor bugs they find might bring.

They can deprioritize bugs coming from Linux users if they find the triaging by itself so hard, but at that point I doubt they have the bandwidth to fix Windows-reported bugs either. The original post seems more like the approach of managers who are disconnected from reality and gauge everything from some metrics. Bugs = bad, reduce bugs by any means necessary.

(Either that or the bugs really are Linux-specific, which is quite possible)

I've worked on platform-independent code.

Even if a bug is platform-independent, the report may well be platform-specific and difficult to reproduce. The real nature of the bug only becomes clear after analysis, and getting the right platform for the analysis may be so much work that the whole thing is impractical.

"May be" doesn't mean "very rarely" either. It's sad, really. You may sit in front of your keyboard with an intuition that this bug affects lots of people and know that you can't really work on it, so how to you respond? Sad.

Having little experience with this, my question is, why not simply try to reproduce the ingame bug using Windows and throw it out if it can't be reproduced? Because at that point, I would categorize the bug itself as platform-specific.

Sometimes the reproduction instructions look as if they can be followed on another platform. I've done that. "Let me just try that quickly on my…" and bingo. But speaking generally, if a bug is that easy to reproduce on your usual development platform, you find it before shipping anyway.

Trying to reproduce a bug by doing something different than what the customer did is a good way to waste time, in my experience.

Perhaps I should elaborate.

One of my first really nasty bugs of this kind was platform-independent, in the sense that the fix affected all platforms. Once I had found the buggy code it was easy to reproduce it on my development workstation by constructing a more efficient reproducer.

But it did not affect all platforms equally. With the hardware on my desk it led to a slow memory leak and would crash after a month or more, on a particular customer's hardware it leaked all memory in an hour, and the customer had more memory than I. I don't remember why, maybe the different CPUs changed whether a race was lost/won? Anyway, I could have gone a year without noticing the bug in my office, but even on the same platform as I personally used, customers would have infrequent crashes.

So. Platform-dependent or not? It's hard to classify in those terms, don't you agree? And that's typical in my experience.

Yeah that makes sense, the same root cause can show different symptoms. Thing is, the triaging starts with the symptoms, and you might not know whether or not the root cause is platform-specific until you've spent a lot of time digging into it. So as far as the dev is concerned, maybe it's not an important bug if nobody on their big target platform is noticing it.

Depends on the type of software. I feel like PC games are on the extreme end of having lots of minor bugs and one very dominant platform.

In my experience it's mixed. Some bugs affect few people on the big platform, but the sheer size of the platform means that the absolute number of people affected is large, and the bad word of mouth then comes from the big platform. Others don't. Sigh. It's mixed.

Eliminating your main source of paid work sounds like a bad idea, if you like to eat that is.

Linux is a "nightmare" for some games developers since its fans will rush to ascribe malicious motives to them for the slightest suggestion that there are problems with supporting it; case in point.

It's not linux that's a nightmare. It's setting up a platform that matches the user's well enough to reproduce and analyse the reported bug.

Last week I had to set up a new debian with a combination of one really old package and one really new in order to work on a bug. Setting that up took more time than the bug itself. (The bug itself wasn't at all related to those packages or versions, BTW.)