Gaming is just one subsection of the Win32 API that doesn't touch on all parts of said API. Proton basically has a bunch of extra patches that might introduce a regression in upstream Wine but won't in the context of videogames.

Proton patches also usually get upstreamed when they reach "proper" maturity/are fully tested if I'm not mistaken so long-term, Proton benefits the rest of the wine ecosystem too. As for the open source contributors - Valve iirc just hired some of the previously self-employed wine developers and the guy who got I think it was a Vulkan compat layer working on Linux.

I'm pretty sure Codeweavers has the same model although I don't think they upstream patches nearly as much? They're also very much more targeting business customers on Apple devices who need to run some obscure (usually old) Windows program rather than the entire scope of Win32 software.

Basically it's best to look at proton the way you sometimes get a "next generation" fork of a popular piece of FOSS - higher dev speed and more features, however more focused into keeping a single area working than on the overall health of the upstream (which does get contributed back to for the features that help the upstream).

According to Wikipedia "all changes made to the Wine source code are covered by the LGPL and publicly available", but I don't really know from first-hand experience.

btw: i consider codeweaver somewhat the unsung hero of the linux desktop.

there is no other company in this world that stakes their success entirely on the success of the linux desktop, or maybe on the demise on the windows desktop, because wine is the only software tool that will never ever be useful running on windows.

Intel was actually including Wine code in their Arc graphics drivers to translate DirectX 9 calls to Vulkan, because they didn't have performant native DirectX 9 drivers. It's a pretty common trick for Arc users to drop the latest DXVK DLL into the directory of a game that is having issues with the graphics card.

Using Wine DLLs is also a good way to resurrect games built on the obsolete DirectDraw API on modern versions of Windows.

That's the thing with desktop linux: almost everything already exists. But there's always an extra mile to go. Sometimes it's tiny bugs, sometimes it's bad default settings, sometimes it's questionnable UI... all things that may not be a problem for tweakers but will stop people that want a good out-of-the-box experience. I'm glad commercial companies go that extra mile.

But yes, props to wine devs. Well deserved.

It's easy to offer a better experience if you also own the actual storefront; that was kind of my point.

And as I said, I'm sure Valve contributes; but describing wine as some sort of semi-usable half-working project before their involvement is rather inaccurate.

i disagree. wine worked, but many games didn't. fixing that is mostly valve's doing. and in my opinion the wine experience is still inferior compared to steam.

the problem is very much one of perception. 90% of the work that went into wine was already there. but the remaining 10% of work that was missing make up 90% of the impression of how well it is working. (the numbers are made up, but i hope you get my idea. it's the general linux desktop problem. the desktop is functional and stable, but the impression of it isn't because of a few small issues that just seem to bother many people)

so by attacking these remaining issues, valve is making a significant contribution.

i think it is also important that valve is able to apply patches before they make it into wine, because that means these patches see way more testing than the wine project probably would be capable of on their own. which is another reason that makes vales work significant.

The proton work is open source (and readily installable without using the storefront), so you can actually just look and see that they did, in fact, fix many little bugs that break games - perhaps only many hundreds, rather than thousands.

last time i tried that, i could not figure out how. any pointers?

It should be noted that it's perfectly possible to release your game on steam in a way where the steam client doesn't even need to be running in order to launch the game. The choice to tie Steam's service into the ability to run the software you purchase /seems/ to be a decision made entirely by the people publishing their games.

If that's the case, you should really be more concerned about that behavior rather than Steam's DRM existing. Don't buy games whose behaviors you disagree with!