> "Free software changes more often, but when it does, it is not that big of a problem because you have both control over code and the code that your code interacts with, because all code is accessible."

This is akin to saying "When you're bleeding internally it's not that bad because all of your blood is still on the inside."

Games are a hit-driven industry. In most cases, it is strictly better to be working on a new game than to improve incredibly niche support for existing products. It would be one thing if fixing Linux bugs effectively future-proofed it from more bugs down the line, but that does not seem to be the case for most of the devs I know who've shipped on Linux.

> it is strictly better to be working on a new game than to improve incredibly niche support for existing products

I'm not sure about this one. Compare Ferals and Ubers approach as two data points.

AAA games rely on a single purchase fee for revenue. Once sales taper off because the game isn't hot and new anymore, there's nothing to be gained from further investment. (Ever notice how games steadily decrease in price the first few years after release?)

Uber gets recurring revenue from their app, so expecting them to provide updates is like expecting a rental property owner to maintain the property--entirely reasonable. Expecting a game developer to release patches years later is like a homeowner calling up the original real estate developer and demanding improvements. Not gonna happen.

(With the obvious caveat that homeowners are allowed to do the work themselves without the original developer's permission, but this about economics, not the absurdities of software licensing.)

This advice is only strictly true for AAA games. From what I've read from the more indie side of the games industry, there seems to be a common thread where the more time spent working on features for a game, the fatter the long tail became, and the spikier the stegosaurus tail tended to become. There seems to be advice that simply adding support for random steam features lead to sales (think things like trading cards, achievements, badges...). Language support can be a really unexpected big one as well. What's also counter intuitive is that porting games to other systems tends to increase existing sales channels.

Now, it's not entirely clear from what I've read, if working on all these extended features for a game have the highest expected value, since it really is a hit driven industry, but they seem to be lower effort work, and are definitely worth it from a lowered risk payout point of view, particularly for a small dev shop that can't risk too many failures.

The original post in the thread basically said that Linux support is easy if you just make a new release every time the libraries you depend on make a breaking change. (Or a GCC update breaks binary compatibility for everything.)

Even if an initial release of a Linux game is flawless, it tends to stop working with the next major distro release. (Unless it's statically linked to everything, or uses something like Flatpack to distribute all its own dependencies. Both options have their own disadvantages.)

You also have to understand that, from a business perspective, game companies have much more in common with a Hollywood studio than a normal software company.

Movies don't get patches. Occasionally they get re-releases for new formats, but at that point consumers are expected to go pay for it again.

None of that applies to today's slot machine^H^H mobile game companies that rely on in-app purchases, or MMOs that rely on monthly subscriptions. The former would never survive in the Linux world anyway, and the latter are often quite successful on Linux, even if it's only in the form of official support for Wine/Cedega.

I understand the business aspect that the Hollywood model is possibly incompatible with games in free software systems (i.e. "Linux"). There are other business models to make games, though.

The problems are real and I think it is natural that they are there, because the movie model is suboptimal. I see similar pains with Android device manufacturers and updates to released devices. That pain is because they are doing it wrong (i.e. not mainlining and doing things binary). That pain is a feature, not a bug. It is a constant reminder that the approach is wrong.

Ignoring that most publishers will recoil in horror if you suggest open sourcing their product, there's two problems your post fails to address:

1. The game industry is stuck on a "release and forget" model. Except for games designed up-front to have some recurring revenue component, few get more than a couple token patches after release. (There are lots of industry horror stories about studios that find out that they can't even compile a game anymore two years after release.)

2. Most games today rely on proprietary middleware, and the industry is steadily moving farther in that direction. Expecting anyone who wants to rebuild the game to pony up for a site license sounds like a nonstarter. In fact, even sharing information on the middleware is sometimes an NDA violation (everything related to consoles is shrouded in an absurd amount of secrecy) so the codebase might have to be scrubbed of all comments prior to release. I'm sure the games community will be thrilled.

What I think we really need is for someone to revive the Loki model where a studio dedicates itself to publishing Linux ports of existing games. At this point, I'd be willing to pay a company like that a lump up-front fee for a game that includes, say, a year of bug fixes/upgrades, and some recurring fee after that for compatibility updates.

> Free software changes more often, but when it does, it is not that big of a problem because you have both control over code and the code that your code interacts with, because all code is accessible.

Except for video drivers. And, as the tweet notes, the bulk of their issues on Linux were related to graphics.

Why except video drivers? Both AMD's and Intel's drivers are free and open, as is mesa. The other closed drivers are alien to a free software system anyways.

What was your expectation? That they would find a bug and submit/fix it to Debian and then walk through the contribution process so it makes it into the next stable Debian release?

No. I expected them to compile their game for the system and try to run it. If it didn't, it would be immediately obvious because the issues were so obvious.

The next step would be to upgrade the system to Debian testing, and then check again. If it still doesn't work, upgrade to Debian Sid, and then check again.

If it worked on any of those, report that and everybody knows in what version the issues will be fixed. If it doesn't work in any of those, go over your marketing and remove claims about linux compatibility. The engineering side of this is less than one work day of one developer. It's literally installing, compiling, starting, upgrading, compiling, starting, upgrading, compiling, starting.

The next step is to figure out in what component an error is, and get the latest upstream version of that component. Then, if the problem still persists, file a bug report against upstream, not against Debian. At that point, you are mostly done, and can at least claim to having done your part.

This isn't magic, nor is it difficult nor time-consuming. Heck, I would do it for free on some weekend if I were given access.

Nobody's going to do that, they'll just say "Use ubuntu" and close your ticket.

I _know_. That stone-walling is a reason why they have so many issues. I'd rethink that approach, and consider the cost of the ticket answers and marketing efforts to fight the flames vs that one day of a developer.

I don't understand why they wouldn't do it, though. I see no plausible explanation.

However, what if it doesn't work on Ubuntu either?

>I don't understand why they wouldn't do it, though. I see no plausible explanation.

Money seems like a good reason. If a tiny fraction of your sales and a large fraction of your bugs are from a particular subset of those users, you don't want those users. They are too expensive.

> Money seems like a good reason.

I'd get that argument when the question is whether to make a linux version or not (using the 'movie model'). But my non-understanding was regarding Uber's refusal to spend the work day of one developer to do the right thing (you don't even need a trained developer for most of that work). If it doesn't work on either version of Debian, it is pretty safe to claim that it won't work on Ubuntu, now or soon in the future.

My principal point is that games on linux can be made just fine, but it must be done differently than for propietary systems. If you try it without changing the approach, there will be pain. And people will complain. Rightfully so.