I work for CodeWeavers, a small US-based company that provides porting services for Windows-based software to Linux and Mac using the Wine project. Our employees contribute a large chunk of the changes to Wine.

Obviously this port was botched, and the article is right to be annoyed at such a low effort port. I'm here to say that it is a really hard problem, even for experienced porters like ourselves. Proprietary software, especially games, on an open source operating system is hard. You've got libraries changing underneath you in incompatible ways, so you've got to support both versions of the library, or even ship your own build of the library. You've got any number of different desktop environments, which makes integration with the native environment hard. You've got about the same number of different window managers, each of which handles window messaging, stacking, etc in different ways. Each operating system, and often even each operating system version, has different package names, making dependency resolution a special hell.

Shipping proprietary software on Linux is a Hard Problem. You can target specific distros, but you'll still have unhappy users who (rightly) want their distro supported. It's a very long tail.

This port was botched, but I bet they're trying to get in on the SteamOS wave. It's hard to blame them for wanting some nominal support for Linux, and thus SteamOS, but they clearly chose the wrong contractor to provide the service.

All that said, I do have one issue with this article:

> They did not communicate the fact that it was not a proper native version, but simply a wrapped Windows version. It was fully advertised as “now available for SteamOS”, giving the false impression it was recompiled for it. Not a very good idea to hide stuff like that.

We get this complaint a lot. When your application is built using DirectX and other Windows APIs, doing a native port to another platform's API can be very expensive. It's not as easy as switching the Linux switch and running make.

Properly done ports are nearly indistinguishable from a game built natively on Unix APIs. In a kind of perverse way, you can actually get better forwards compatibility with a non-native port like this. As the old binaries rot and fall out of compatibility with modern desktops, you can just pull out the Windows executables and run them in a modern version of Wine.

Think of Wine (or this Eon thing, if it were done properly) not as a wrapper, but as a library that the authors decided to target their application for. You can then upgrade your library and still run the application that targeted it.

> You've got libraries changing underneath you in incompatible ways, so you've got to support both versions of the library, or even ship your own build of the library.

I thought steam provided a runtime with libraries so that this isn't a problem?

> Shipping proprietary software on Linux is a Hard Problem.

I would think this is a hard problem for everyone except Steam, which happens to also be a digital distribution method.

> I thought steam provided a runtime with libraries so that this isn't a problem?

Nope. Steam provides some libraries to hook into their platform code, stuff like friends lists and multiplayer. But it's mostly just a delivery platform. The applications are just applications and can do whatever any other application can do, including rely on system libraries.

This isn't what the parent meant. He's talking about this: https://github.com/ValveSoftware/steam-runtime