CodeWeavers do submit their changes back to the main source tree though, IIRC. CrossOver is great if you're trying to run a variety of applications, but it may not necessarily be the best tool for the job if you're trying to fine-tune it specifically for only one application. And as anyone who's worked with WINE knows all too well, there are no guarantees with Windows compatibility.

But I'd argue that that's something you have to do anyway if you've purchased games across multiple distribution platforms (e.g. HIB, Desura, IndieVania, Steam, GamersGate, etc.) - there's absolutely nothing wrong with insisting on going GOG-only, but I would think that the most effective way to ensure that native game development continues is to directly support the developers, by buying straight from them. With a niche platform like Linux or OS X, that would be especially important, given the often dubious financial gains to be had by devoting extra time and resources to doing a Linux/Mac port.

You may not see it that way (and indeed neither would I) but to copyright lawyers it may be a different story. You could possibly liken it to the MPAA/RIAA's disputes over Fair Use laws, where they would see a copy you purchase for your own use as differentiated between copies you'd have on CD, a copy you'd have on your computer, a copy you'd have on your car, etc.

I'm not a legal expert, and this is all purely conjecture on my part but it's been stated earlier by TheEnigmaticT that it's all fuzzy and there are no clear terms on what the publishers/IP holders would say. If GOG decided to just release zip files with the clear intention that they'd be intended for cross-platform installation, they could open themselves and their customers up to a lot of potential problems.

When it comes to legal nonsense, everything matters, and if a right has not been specifically spelled out in an agreement then the door is wide open to have some IP holder get in a twist about it. You don't even have to be doing anything wrong. Just smearing the line enough that somebody thinks you might have crossed it could be enough to make life very complicated. Given the level GOG is playing on, legal paranoia is probably a good practice.

That said would one or two IP holders sign off on a zip package (or even Linux installer) for old DOS games if asked, without it being a big production? Maybe, but then none of us have any clue what its like to negotiate distribution rights for these games, and to say it would be difficult, not worth it, impossible, or no big deal is all rampant speculation.

All we can really say is we have notice some places are doing some things that are cool, and it might be nice if we saw them done here as well.

Yey, a new topic. CodeWeavers offer a professional 'porting' service where they build a wrapper around a particular game. I'm not sure if they typically require the source and use winelibs or if they're willing to work with the binary, but they did e.g. Limbo for the Humble Bundle. (http://www.codeweavers.com/services/) I imagine using their expertise would cost money though which would have to be passed to the consumer.

but sadly, the limbo codeweaver port is also an example of how inhomogeneous the linux community is. While some accepted it as good, reasonable solution for bringing limbo to linux, some unthankful "traditionalist" started a petition against the port and HIBV for being not native enough (http://www.indiegamemag.com/linux-users-petition-against-humble-bundle-v-due-to-non-native-version-of-limbo/). The linux community can be sometimes very hard to cope with. :/

And technically spoken, supporting the wide and fragmented linux ecosystem is pretty hard. For example there is still no compatible and (longtme) stable, distribution independent way of deploying binary software for all (or at least the majority) of distros. Everything is focussed around the specific distro repositories. (recently Ingo Molanr spoke about this missing capability https://plus.google.com/109922199462633401279/posts/VSdDJnscewS and argued this is the major obstacle for the linux desktop)

Even the well made Humble Bundle linux support had to provide various packages and still many of them broke already on latest distro upgrades. Supporting the linux ecosystem is much harder then supporting windows or even mac which form a stable platform... unlike the linux ecosystem sadly :( (noticed by a mozilla developer already years ago http://benjamin.smedbergs.us/blog/2006-10-04/is-ubuntu-an-operating-system/ or by the freesoftwaremagazin http://www.freesoftwaremagazine.com/articles/2009_software_installation_linux_broken_and_path_fixing_it)

I'm convinced we would see much more linux support in the gaming domain if a convenient, binary (guaranteed backward compatiblity) distro-agnostic way for software deployment would exist for ISVs (gog is somehow one too)...like in Windows (and Mac) known for great binary compatiblity.

Technical solutions and initatives are (or were) available, like the autopackage (http://web.archive.org/web/20080331092730/http://www.linux.com/articles/60124), http://0install.de/?lang=en or http://portablelinuxapps.org/ , just the distros have to agree and support them, then linux support would be easier and therefore more common.

(PS: here some description through what hoops a ISV has to jump if he wants to create a distributable solution, even WITH sourcecode http://www.mygamecompany.com/articles/linuxgamedevelopment2.htm)

Yet, classic methods like tarballs and self extracting archives work across many dsitros pretty well. Mozilla for example provides generic tarballs which are usable on wide variety of distros. Of course if you plan to depend on more distro specific libraries, it's more complicated.

This seems to be a minor issue in comparison with fear to invest into small market. If market is big enough, such kind of considerations are simply ignored. And again - there is no uniform deployment method if you target multiple repositories. If you deploy in repo agnostic way (as self contained package), then it's easy and seamless. It's up to developers to decide which path is preferable, since both have pluses and minuses.

tarballs are normally a way of source distribution it's not (or seldom) an option for ISVs. It's the last fallback solution. practical all consumer distros nowadays are binary package based. User hate source distribution for good reasons, as CLI compiling is ugly, time consuming, error prone. (and you are right Mozilla is more open & active in direction of building binary platforms... but they are a exception and also get blamed for such approaches as being not enough "the unix way")

Back to the problem: There is no widley available, distro supported and simple way of adressing multiple distros (and their variants, versions) in a binary and compatible way ... statical linking is HARD (or near to impossible) and other helping approaches like autopackage, zeroinstall, CDE, portable linux apps, FatELF were ignored and not supported.

I agree, the size of the market is another big problem. But here I see a connection: if the market is small and the risk high, at least the entrance in the market should be easy and cheap. It should not be vice versa. The linux ecosystem is the most complicated and hard to support ecosystem/platform for multiple reasons, compared to already much bigger markets Windows and Mac.

Also, Mac OS was in a similar situation too, some time ago but was able to break this chicken and egg circle. I think because they made the entry in the market as EASY as possible. Providing a stable platform, complete tool-chains, complete multimeda APIs, binary compatibility over many years (even unversal binaries!)... something a developer and ISV can rely on. Linux has to go this way too!

This was an issue that was (and to some extent still is) seen among the Mac gaming community; it was especially strong several years ago when a sizeable and very vocal minority were screaming stuff generally along the lines of "Native ports NAO or GTFO". While there were some very poor WINE-based ports out there (like the original port of X3: Terran Conflict) a lot of people seemed to forget that there were some very good WINE-based ports like HOMMV and C&C3, and that the Mac gaming market has seen a lot of really badly handled native ports.

We're pretty much at the state right now with hardware and software that WINE is "good enough" for a lot of games, and while I wouldn't cut a lot of slack for say, a AAA developer, I'd totally understand it if an indie or AA development house with a very limited amount of time/money/talent resorted to using WINE to port their games...it means that it helps them secure enough sales to (a) make their next game, and (b) ensure that their future development will be platform agnostic.

The people who started that petition say that they don't want to start boycotts or slur the name of Humble Bundle, but it almost sounds that that's what they're trying to do. Like with the Mac, I wonder if the people shouting for native ports really have an appreciation for just how much work that entails, especially for games coded after the fact using a lot of Windows-specific APIs.

The Mac actually had these qualities for years - the main problem was whether or not it would be profitable to use them, at least for AAA IP. The recent growth of the Mac and the explosion of distribution methods like Steam, and the App Store has only recently made it financially feasible. Hence why out of the original array of Mac porting houses and publishers that were around several years ago, only Aspyr and Feral still exist for AAA-level IP.

Consider the source: perhaps the most unreliable, rumor-mongering site and "reporter" on the Internet. He probably just saw one the threads about community efforts to get GOG games running on Linux (several Linux downloader and installer projects are in progress) and is twisting it to sound like GOG is going to officially support Linux.

I understand that one of GOG's priorities is the after-release support. Yet the current situation is that more of new releases - either old or newer games - are sold by other parties as a part of bundle, thus I as a customer loose a reason to buy here in these cases. Amanita Design's games are a prime example.

I use Linux on the main working station, notebook. I also have Windows installed on my gaming PC (I like to nickname it as "my console" :)). For AAA releases it's a fine solution but for others - which have official Linux alternatives - it's an overkill. I can imagine Linux an existing installation packages could be added as a bonus material of a release without an additional support and let's a customer decide.

For now at least. There's no denying that both Linux and Mac desktop marketshare have been enjoying some nice gains lately (one source claims a 50% jump in 2011), and the repeated visibility of threads like this are sending a clear message to the GOG leadership that there is a demand for cross-platform compatibility.

I do agree that it's pointless to propose half-assed "solutions" to this, but I actually do predict that one of the major things we'll see in 2013 is the release of at least one cross-platform game on GOG as an experiment to test the waters.

For now, agreed. Linux definitely has been making gains, but it needs to make much, much larger gains than it has for it to be viable as a business decision. A 50% increase just takes us from 2% to 3% market share (at most, percentages are never consistent), and not everyone in that 3% is a gamer.

A test of some kind wouldn't surprise me, but I would expect a Mac test, not a Linux test.

First of all some experts consider this 1-2% to be a severe underestimation, PRed by Microsoft. Secondly, others weren't intimidated, and successfully publish Linux games. So it's not a clear cut risk. I personally don't pay attention to this 1% idea. This number is rather off mark. Out of curiosity, may be GOG can publish visitors statistics by OS? That won't of course accurately reflect the global situation, but will give some rough idea bout GOG visitors at least.

If they'd be making such test they could as well include Linux right away.

Because having to provide support for 1 extra OS is the same as having to provide support for 2 extra OS?

If they'd be testing less supported option, having 2 instead of 1 won't cause major overhead. Otherwise it won't be a test, but a full blown feature addition.