Future_Suture: The subject of not enough resources and wanting to provide a quality service at all times actually came up
starting from here. Needless to say, apparently it's not as much effort as GOG likes to make it seem.
TheEnigmaticT: Making packages and distributing them? Yes, that's trivial. But what your poster in that thread doesn't account for is that we do a lot more than that with classic games. I'm not the guy in charge of testing, mastering, and building games, but let's just look at what *I* can think of that makes Linux release a very difficult proposition:
1:
Testing. What distros do we support? There are 10 "fairly common" ones (Ubuntu, Mint, OpenSuse, Fedora, CentOS, ArchLinux, Debian, Slackware, FreeBSD and, um, I've forgotten a couple). Hardware? What level of updates? Only FOSS drivers, or can we take some closed source stuff? Once we've decided on a test bed, we still have to check the games. Do they boot? What about oddball games like, say, Theme Hopsital? There's a version-specific DOSBox-related fix there. Does it in work in any distro? In all of 'em? Managing testing across the 3 OSes we support is tough and requires a lot of time, effort, and money. How much more complex will 10 more OSes make it?
2.
Support. Having problems getting your game running? We'll help you out. Contact Support and they'll try to diagnose your problem and offer a solution--but they only know how to fix common (and less common) Windows problems. LInux is famous as the hacker's OS--that is to say, the OS of people who like to do odd things with their hardware. If someone contacts Support because he can't get his copy of Fallout running on his Raspberry Pi with a video out that's connected to a six-panel e-ink display and he wants his money back, well, that puts us in a bad spot.
3.
Maintanence. Across those 10 common distros, how often does one of them update? Quarterly? Monthly? I don't know, but the answer is certainly "often". What do we do if slackware updates and breaks the functionality of a glide wrapper that we're using for all of our games? Or if FreeBSD removes a driver from the kernel that we depend upon in order to run some games? Just planning for Windows 8 is a minor headache--ask Tolya about his test plans if you want to hear an earful--but planning for a wide spectrum of OSes that have constantly changing sources and see major feature and bugfix releases more than once a year? Man, that's a Herculean labor.
This is a thumbnail sketch of the challenges that await a digital distributor who wants to release games on Linux and who also wants to provide proper support when doing so.
Of course, we could just release a client, sell the games, and figure that you can sort the rest out yourself--I'm sure some businesses may even consider that a successful business model--but that's not really the
GOG way of doing business. ;)
I really hope they've looked over a lot of these reasons since then because so many are just bull responses with very little research or logical reasoning.
1. What distros should you support? This is barely even something you have to worry about. Just package RPM or Deb packages and include the required software or libraries inside the package instead of relying on what the distro includes. Have it all go into the install directory instead of looking into /usr/share/lib and places like that. If a distro has DOSbox .6 or .74 when the game runs best on .71, then include DOSbox into the package. You already do this with Windows, there's no reason why you can't just continue doing it with linux packages. Only things you don't want to include are low level software, like XOrg and various drivers. You can get away with testing on one or two distros as well, include a disclaimer saying tested on such and such distro version, and if someone has a problem then they can just look at the software versions of important packages in those distros and see if they can compile those packages for their own system to get it working.
2. Linux may be the "Hacker OS", but you still can at very least lay down the hardware minimal requirements. The problem that was laid out, with the RPi and all that crap, is strictly hardware. Minimal requirements between windows and linux are practically the same. If a person is running an ARM processor when the compiled game needs an x86, that's their problem, and is not something you need to worry about. If they come to you, you can just say read the requirements.
Also, if someone is going as far as running an RPi with a 6-panel eink display, wanting to play Fallout, I can assure anyone that they're not so freakin' stupid as to want to want their money back because the game doesn't work.
3. Maintenance can easily just fall under when looking for distros to support, test the ones that have LTS releases, and have the disclaimer state that they were tested on those systems. Every two to four years, test again.
Linux isn't frighteningly different from Windows, and I hate it when people think it is. The biggest problem for older games is just writing .sh scripts to execute dosbox or scumvm with the old app, and new games just need to support having an OpenGL/AL renderer and sound support, most easily accomplished by using SDL2.
Distribution isn't as big a hurdle as people make it out to be.
