Yes, that how it works for now. GOG's primary goals have changed, industry's changed too. I won't stay silent about it just because things are what they currently are. I made a statement from a customer's point of view.
I don't expect GOG to snap their fingers and start throwing Linux or Mac versions at us tomorrow. There are some developers who themselves sell a game for all platforms at one price, so it doesn't have to be an easy task but it's hardly an unresolvable problem.

I'm satisfied with GOG, so I'd naturally like to buy all games I'm interested in here.

Fun and silly fact: Just wanted to say that the request asking for Linux games to be sold on GOG now has more votes than the Steam group asking for a Linux client has members! Keep it up!

For Valve/Steam it's official now: http://blogs.valvesoftware.com/Linux

Will CDPR/GOG follow?

Testing on Linux is simple, only support X86-64/x86-32 platforms. Tell Raspberry Pi people they don't get support which is normal (non x86 users don't expect support for anything anyway) Don't support FreeBSD/DragonflyBSD/Solaris/Mac OSX/HP-UX etc as they are NOT Linux. They are other Operating Systems. Linux uses the Linux kernel. Statically compile your applications so that you don't have to worry about what the OS provides. Dosbox works on all distributions and version specific fixes work across all distributions. If you ship the libraries dosbox needs, statically compiled with the dosbox executable you won't have to worry about distro specific changes. Ship using self extracting executables pioneered by http://www.lokigames.com and if you need help with anything speak to Ryan Gordon at http://www.icculus.org he is hireable as a programmer and he has worked on about 80-90% of all commercial game titles on Linux. Linux is doable, a lot easier than you're thinking, and should be done. Distribution support is not a problem, people only think it's a problem. The issues were solved over a decade ago. Use their knowledge, everything you ship via dosbox already runs on Linux anyway.

You know why Ryan Gordon's name (only) is associated so strong with linux gaming and porting? Because he is one of only a handful people able to do so.... because porting to Linux IS extremly hard, and then it works only until the next distro upgrade (all loki installers are broken nowadays). And even with Ryan, if you followed the HIBs, the linux version of games had the most complaints ("broken with Ubuntu update x.xxx", "sound is not working") and required many updates after release to get them somewhat working on at least "many" distros.

Distribution support is one of the CORE problems of the (NON-existing) linux platform (second one missing stable binary APIs), read here what people which have to cope this crap have to say about it:

Ian murdock (debian founder and LSB boss then) -> gave up around 2006
http://ianmurdock.com/linux/software-installation-on-linux-today-it-sucks-part-1/
LSB -> no progess since 2006
http://www.linuxfordevices.com/c/a/News/Linux-Standard-Base-40-certifications-announced/ (fragmented ecosystem)

Miguel de Icaza (gnome founder)
[url=http://primates.ximian.com/~miguel/texts/linux-developers.html]http://primates.ximian.com/~miguel/texts/linux-developers.html[/url]
"the continuous breakage of the Linux development platform is hurting them. Linux is still a small market compared to the Windows and Mac markets. In most cases, the revenue opportunities for the small and medium ISVs are too small to make a Linux port worthwhile, and when it is, the staffing requirements for maintaining and testing their software for a dozen of distributions and release versions quickly becomes a big burden. "

Linux game publishing
http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/

Ingo Molnar (kernel devloper)
https://plus.google.com/109922199462633401279/posts/HgdeFDfRzNe
(describes why third party software support (like for games) is so hard on the linux desktop)

Osmos linux port/support experience
http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/
"Didn’t Love: Supporting multiple Distros/DEs/WMs/drivers/etc. The #1 obstacle to getting more games on Linux is that it’s very difficult to get your game working correctly and acceptably on all machines. It’s really hard to guarantee a smooth experience for all players when there’s a combinatorial explosion of possible distributions, desktop environments, window managers, driver/hardware versions — each with their own unique foibles, bugs, and undocumented behaviours. It’s the classic PC gaming problem, but magnified."

The Future of Packaging Software in Linux (on the unsolved deploment hell)
http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/

"Shot of Jaq" on serious game developing problems with linux
http://shotofjaq.org/2010/06/the-indie-revolution/

...also, your recommendation "just link it statically", it's not (simply) working technically
http://www.evanjones.ca/portable-linux-binaries.html and is not supported by community.
http://web.archive.org/web/20100527213559/http://people.redhat.com/drepper/no_static_linking.html

So, first deployment hell and missing binary compatiblity on the fragmented linux ecosystem needs to be fixed, then we will see maybe more gaming support for Linux.

Ryan Gordon's an awesome guy, but he's not Superman, and it'd ludicrous to expect that he'd take on the onerous task of porting GOG's catalog to Linux.

If GOG were to partner up with an outside party it'd have to be with an actual shop with a dedicated and experienced set of Linux programmers for ports. Sadly, that was what Loki Games was, but they went bankrupt because they weren't making any money.

Not to mention that for the ports he's done, he's been provided with the source code by the developers under licence. For much of GOG's catalogue, the source code is either lost or kept under wraps.

I don't think this is about porting anything. We are talking about first adding titles which already release(d) native Linux version to GOG. Porting is a much harder and involved task. Let the simpler step work first, and if it'll succeed GOG can think about getting involved in porting old titles.

So this is about the "simple" software deployment and support of the "linux platform" (only)?

Sadly, this is the hard part. Again, there is no standard way and and no stable linux platform, see the now all broken loki installers and the amount of packages the HIB has to provide and the many updates afterwards...
Also, there is sadly nothing like binary packed "native software for linux" (it's a kernel not an OS/platform) there is only software specific to the myriad of incompatible distro variants. Which needs to be adapted every distro update. -> So GOG can't rely on already existing binary packages (what your suggestion was).

Even with availabilty of already packed linux software, (long time) linux support means effectivly "porting" a software to every specific linux distro variant. E.g. Ubuntu made an update? Port and adapt the sofrware again.Test and check the behaviour of the updated libraries and drivers whcih exhibiting behaviour onyl common on this distro variant, every distro behaves subtle different....

it's a well know mess and the hard part on the linux support.

PS: here the experience of indie game developer motivated to support linux: http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/
"Didn’t Love: Supporting multiple Distros/DEs/WMs/drivers/etc. The #1 obstacle to getting more games on Linux is that it’s very difficult to get your game working correctly and acceptably on all machines. It’s really hard to guarantee a smooth experience for all players when there’s a combinatorial explosion of possible distributions, desktop environments, window managers, driver/hardware versions — each with their own unique foibles, bugs, and undocumented behaviours. It’s the classic PC gaming problem, but magnified."

Nonsense. Many packages are released universally. I already brought you examples (Mozilla, Libre Office, Qt SDK and etc.). As a very radical way you can always release something using chroot approach - then only kernel compatibility will bother you. Even more - you can release a VM image for VirtualBox and etc. Then nothing except hardware capability for virtualization will bother you.

What that developer is talking about is related to drivers, not to distributions. Games using standard things like OpenGL, SDL and etc. won't depend on desktop environment.

If someone doesn't know how to avoid dependencies pitfalls - of course there is no one else to blame, except oneself.

Old releases can become obsolete. So they should be rebuilt for newer kernels and etc. There are systems which keep compatibility much better (Solaris for example), but that's not the biggest obstacle for Linux releases, not at all.

"Many" is plainly wrong. Your quoted examples are very seldom examples of major projects (even not game one) which have enough "mass" and developer to do so. Not more then a dozen. As popular counter example for games, look on the Humble indie bundle V (if you bought it), they adress "Lone Survivor" (linux version) on the downlaod page with 7 separated packages, "Limbo" has 6 (with ubuntu download center), windows is fine with 1. From the 8 games in the HIB5 , 5 linux versions already needed to be hotfixed, compared to only 1 game with a windows version update.

Virtualization surely is a kind of solution (with a cost and downsides), but then, why we need Linux, if it fails to provide the most basic OS functionality... to be a platform for applications.
Yeah, maybe you are right open source enthusiasts should shift to technical feasible solutions like Reactos (http://www.reactos.org/), might have more future, then the "unix" approach. Unix failed in the 80s, so why it should work now?

The Osmos developer indeed spoke also about the myriad of distros (and the technical consequences), read the interview and his blog again: "Didn’t Love: Supporting multiple Distros [...]"

About "OpenGL, SDL and etc.won't depend on desktop environment." if there would be a solution for the missing stuff you didn't mentioned.. e.g. a distro agnostic way of create simple dialog boxes: "Didn’t Love: No OS-level GUI layer for simple dialogs. This is something of a minor point compared to the above, but I want to mention it because it comes up often enough in cross-platform development. Because Linux has no OS-level GUI layer, games that need any kind of UI must link against heavy-weight UI libraries (GTK, QT, etc) which typically impose some kind of application framework. Common examples of the usage of UI in the gaming world would be a dialog that prompts the user for input the first time a game is run (e.g. “Launch in fullscreen?”) or that displays a message when an app terminates unexpectedly. " (again, Burke)

Overall, there is not coherent solution for gaming and multimedia application creation, support and deployment available among the linux distros. Only parts... like OpenGL, SDL ...etc as APIs, nothing as distro agnostic installer and finally no long time binary compatiblity.

"one just needs to know how to approach them. " ... sure, a good engineer can solve even the nastiest problem. But a platform/OS should reduce the problem domain of deploying, creating and supporting software not increasing it exponential! By that characteristic the linux ecosystem failed considerable compared to other OSes.

Also, I consider excessiv virtualization as symptom of a failed platform, not as a superior solution (it has severe UX down sides!).

Even Solaris which has a much better than Linux backward compatibility support provides Containers and Zones as system level virtualization. I wouldn't call such option an indication of the failed platform - on the contrary, it's a sign of mature platform which gives great flexibility for you to do whatever you want.

Such kind of solutions are of course for worst cases, when it's impossible to install something on the system directly for whatever reason (legacy applications and so on). Most cases never come to this, but such option is still available.

Agreed, sometimes there are good reasons for system level virtualization.