[throwaway9524]

Seems this sentiment is coming up in every recent Proton related thread. Despite all the counterarguments offered each time.

The simple reality is that there are decades worth of Windows games that will never have a Linux version. Because of the studios being gone. Because of the source code being lost. Because of the licensing issues for dependencies, assets, music. If not for the Valve efforts people would always need a copy of Windows to play a good chunk of their libraries. At which point why bother with Linux? But with Proton the calculus changes. Most of those Windows-only games are now fully playable on Linux. Many people no longer need Windows and that's a huge win for desktop Linux adoption.

By this logic Apple should not have developed x86 translation for its latest Macs because it showed they are not serious about the platform and disincentivized devs from providing native Arm ports. Except we know that's not what happened.

[pjmlp]

Apple developed the x86 translation layer for its own OS, not a third party OS.

[throwaway9524]

I get the reasoning from your other replies. If Microsoft extends Win32 with some new API that cannot be reimplemented in Proton then Valve is screwed. So you want them to require a native Linux version from every game published on Steam.

However I really do not think Valve is in a position to dictate such terms. They have multiple competitors both in distribution and console space. Big names are already publishing on their own stores. Small indies can move to itch.io. Everyone else can switch to Epic. Steam Deck is already underpowered compared to recent Windows based handhelds. If it stops supporting Windows games via Proton then it is as good as dead.

I understand your idealism. But a step like this would kill gaming on Linux much quicker than anything Microsoft could do. Because Valve is the only big distributor even remotely interested in it. In contrast Epic is absolutely hostile to Linux. And they're the ones to gain the most users in case Steam fails.