Yes, Steamworks has its own lock-in, same as Windows with their APIs.

Somehow, you are right... If MS would push NOW DX and win32 I would not support it.

But as it is reality now, with a successful history of approx. 20 years as open platform (everything open beside code), without inherently included DRM (unlike steamworks), I think supporting WINE (and the underlying win32 + DX) is a better idea than supporting steam.

I expect better from GabeN who likes to talk about open platforms!

Surely there is no need to support Steam as in Steamworks. Wine as a project is OK to support of course - it's very useful. But it's wrong to encourage developers to use DirectX instead of OpenGL + SDL and etc. thinking that Wine should be the primary target. I know Carmack said that, but I completely disagree.

Fixing bugs in existing titles to work better with Wine is another story, I'm all for it. But for new titles? It's better to use cross platform, open and non patent encumbered technologies to begin with.

Ha, Wine. Any next release of Wine can break compatibility completely, developers will be insane to rely on Wine.

As currently every release of everything on linux. I would consider Wine among the more stable possibilities for binary software distribution on the linux ecosystem. Currently, we don't have something like directX+win32 with a stable API/ABI, only subsets or unstable alternatives. Steam builds a platform now up from the ground... why was the community unable of doing it themself...why??? :(

Nitpicking on whether particular title is formally not affected by Steam DRM is pointless, since Steam doesn't care to make it easy for you to discover it. At most it can be considered a bypassing of Steam's DRM in that case. It's enough for me not to use Steam at all anyway. Their whole attitude is way too pro DRM to excuse it with existence of some defacto DRM-free options there.

Please understand that I'm not defending Steam. I wouldn't let that garbage within 10 feet of my PC.

My point is that, if you call "no standalone installer" DRM, then you can make a case that the Windows Registry, pre-web-download era Desura, broken installers, and many other things are DRM.

There's a difference between DRM (an active measure to limit how you can use what you've paid for) and a decision to use certain technologies which complicates user freedom as a side-effect.

How is the Linux community akin to English workmen who destroyed labor saving machinery in the 19th century?

Luddite (noun)
derogatory a person opposed to increased industrialization or new technology:
"a small-minded Luddite resisting progress"

Origin:
perhaps named after Ned Lud, a participant in the destruction of machinery, + -ite1.

Doesn't that actually mean that GOG is the luddite one since they seem to be afraid of Linux? :-)

If you followed for instance the systemd debate on the debian mailing-list (and especially the reactions after the decision), you found a strong traditionalist faction with a indeed luddite mindset: "Destroy/prevent all innovations, beyond the holy posix/unix layout from the last century!" Infact, I was positive surprised that his time the progressive faction got the upper hand. If you look on the rejections of many other technological innovations in the linux ecosystem (e.g. FatELF) clearly the luddits were very successful in the last 15 years.

PS: and systemd indeed acts as "labor saving machine" by providing better automatisation in contrast to the "manual" written script/hacks with sysVinit ;)

GOG had that advantage for about a week, now they have regional pricing, too. LOL

So for European Linux gamers there is now absolutely no reason to consider GOG again.

I agree, it's not a proper DRM free release, nothing in Steam is.

But as I already have the game on Steam, I'll use the opportunity to zip it up for future use. Of course once it's out of the beta stage.

Systemd is quite irrelevant to Linux gaming, because Ubuntu 12.04 LTS is the de-facto standard platform set by Steam for years to come. It uses upstart. SteamOS currently runs on sysvinit.