GOG.com Don't Plan On Introducing Linux Support In The Foreseeable Future UPDATED

I understand that you're all fans of the OS and you're part of an active community that is passionate and dedicated--all things that have gotten GOG.com where we are today--but you're also part of a *small* community.

I'm also part of the ScummVM team*, one of the legs you base your business on. And I'm telling you, you're talking bullshit.


*) Of course, I'm only talking for myself here
*) And while we're at that topic, I'm still not happy about how you handle ScummVM and DOSBox integration: I'd wish you'd advertise on the game page when you're using ScummVM or DOSBox. For both other-OS-compatibility questions and, well, "proselytising", for the lack of a better word, about FLOSS. I'm aware that legally, per the GPL, you need to do no such thing, but I do find it quite sad how well you hide that you're using FLOSS. /tangent

Considering the comments we have explaining how easy it actually would be for you guys to support us (didn't realise you worked for GOG.com hello!) I see it a cop out. 

I don't want to re-post them as they all explained it better than me.

There's no nice way to say this, but I'm going to try: you are all thinking like Linux fans, not business people. You're only looking at upsides and positives, not the potential downsides and negatives. Let me explain:

Let's take an answer like helsinki_harbor's from right above me: these are all generally community-run projects. Let's suppose that we roll out Linux support and rely on one of those community-run projects to help us support GOG.com's Linux release. What happens if the community behind it decides it's sick of it and gives up? What happens if the project runs into idealogical problems and splits into two projects, each of which focuses on one particular area, but we need the output of both?

Linux is community-run, and that's awesome. But a business needs to evaluate things from a risk-avoidance standpoint. Let's not think about profit numbers, here. Think about this from a human standpoint. Let's prognosticate: It's 2014 and GOG.com hires five people to help us pipeline Linux game support; we use portable linux games to help manage how we're porting these over. Things go great, everyone's happy. Flash forward to 2015: the portablelinuxapps.org team splits up, though, due to reasons. Then a new update rolls out for Mint that requires a lot of work and we don't have the hours of community labor to help make Linux support viable for GOG. After 6 months of trying to figure out what the heck we're gonna do, we decide we can't support Mint and also realize that the other distros will probably merge in that same upstream code that's causing us problems. We shutter support for all Linux but, because we're good guys, also feel that we have to offer refunds to anyone who bought a game from us because of Linux support since we launched. Then, since we don't have a use for them, we fire those same five people we hired a year ago.

Is this likely? No, I don't think so. Is it possible? Certainly. When you run a business, you don't take on that kind of financial risk--let's suppose we get 5% of our sales from the Linux community from that year--and that kind of personal risk unless you can control some of the vectors of risk, there. It's entirely possible that a sufficiently poorly-thought out Linux rollout could cost GOG.com millions of dollars. Gambling with that kind of money is stupid. That's why the solution for this comes from our end--from us learning how to automate better--rather than the community end. If we can control that, then suddenly the risk becomes manageable, and then you'll see us willing to try.

There's a reason why Steam is willing to support Ubuntu, and it's the same reason that many of the Linux community aren't happy with the OS anymore: there's a single point of contact (i.e, Canonical) who is responsible for decisions that are made, and the organization is required to think of long-term goals and support precisely to help businesses mitigate risk. 

You're right: we could roll out Ubuntu support and offer a service that is similar to (or possibly slightly worse than) Steam's. But I do not believe that GOG.com has gotten where we are today by aspiring to copy Steam. We want to be better than them, and here's a case where, unfortunately, the fact that we don't have their staff and their money means that it takes us time to remain true to our vision and our purpose.

Considering the comments we have explaining how easy it actually would be for you guys to support us (didn't realise you worked for GOG.com hello!) I see it a cop out. 

I don't want to re-post them as they all explained it better than me.

There's no nice way to say this, but I'm going to try: you are all thinking like Linux fans, not business people. You're only looking at upsides and positives, not the potential downsides and negatives. Let me explain:

Let's take an answer like helsinki_harbor's from right above me: these are all generally community-run projects. Let's suppose that we roll out Linux support and rely on one of those community-run projects to help us support GOG.com's Linux release. What happens if the community behind it decides it's sick of it and gives up? What happens if the project runs into idealogical problems and splits into two projects, each of which focuses on one particular area, but we need the output of both?

Well of course we are users not businessmen (most of us). We are trying to show you ways you can support us and trying to get you to see you can and will earn money from us.

You rely on dosbox and ScummVM for some games don't you? Aren't those community run projects? How is that different than using another one? What if no one maintains those projects for a while and updates in say Windows and Mac break them and no one is around to update those projects for GOG?

The linux support vote here: http://www.gog.com/wishlist/site/add_linux_versions_of_games has nearly 12,000 votes on it, are those masses of people not a big enough percentage of your userbase to work with and earn money from?

The point is you don't need to support every game on GOG under Linux, hell you sure don't for Mac. Why not even for now to dip your toes in use the dosbox and ScummVM games? What is the problem with them? As you surely can't think you would have more issues with those projects on Linux than you would on Windows or Mac?

You're right: we could roll out Ubuntu support and offer a service that is similar to (or possibly slightly worse than) Steam's. But I do not believe that GOG.com has gotten where we are today by aspiring to copy Steam. We want to be better than them, and here's a case where, unfortunately, the fact that we don't have their staff and their money means that it takes us time to remain true to our vision and our purpose.

Hi Enigmatic, thanks for getting in directing contact with the linux crowd.

I think GOG was always better not because it was technical superior (it's also good in that sense) but because of a far better ideological philosophy behind. Technically, I agree that the Linux ecosystem can be a pain in the ass to support (no SDK/no binary compatiblity/not platform in general to address)... therefore also Steam struggles here, nearly 1000 issues despite only addressing Ubuntu and not "linux" (https://github.com/ValveSoftware/steam-for-linux/issues?state=open). Steam might be technical one step ahead before gog, but their approach is pretty small minded by implementing a walled garden and taking away by that much of the power and freedom it offers for their users.

A better pilosophical open platform & community driven approach, which respects the users, will be cheered by especially the linux users. Technical superiority can come over time...

You know I find it interesting we have people who basically call something bullshit without actually looking at it from the other side of the argument. First let me give some people here my Linux background (Yes LINUX not GNU/Linux which I know someone will inevitably bring up.) My first *nix distro was Mandrake 6.1. I have bounced back and forth between Windows, OS X, and a variety of Linux distros (currently running Kanotix) I work in the gaming industry doing much what Liam does here. However, instead of taking a one-sided approach which is seeming to be done here. Why not just ask the hard technical question. Ask actual developers whether or not having the various API's, Desktop Environments, Packaging formats etc. actually matter. 

I know for a fact those are the type of questions that I have actually asked in my interviews with Unknown Worlds, Muse Game etc. For those who want to know what games those companies have put out they are Natural Selection 2, and Guns of Icarus Online. The simple fact is Linux does not currently fit into GOG's business model. They want to ensure that games run on the widest selection of stuff that most regular users use. I hate to break it the 2%-3% market share that desktop linux has is not enough to justify jumping into Linux for them. You can argue that Valve hitched their wagon to Ubuntu and that is the core distro they support. Well how many people have read the Steam TOS? Do you know that you can only get a one time no questions asked refund? GOG is doing just the complete opposite of that. In order to do that they are ensuring the platforms they support are limited.

You guys want to see linux games from GOG? Then show them a reason to acting like a bunch of typical erhmahgerd linux user is not and will not work. Now, the argument could be that GOG loads games with its own self contained package with separate libraries from the system library. This would make games run on all *nix distros which would present a more distro agnostic approach that some would like to see. I will say the following though the Linux communities typical RTFM (which some have shown in this comment section) is not conducive to actually being able to have a good solid MERIT based conversation on technology.

The simple fact that a GOG rep even took the time to even come and respond to the comments section or this article along should show that they are true to what they are saying about at least looking at Linux as a possiblity. Or maybe it is just me seeing both sides of the argument. Because while I am a *nix gamer I obviously dont have the option to support GOG as they do not offer *nix games. So I choice to be on the services that do. Steam, Desura, GamersGate(limited), Humble Bundle (when they have them.) use the ones that support your said platform of choice whatever that maybe. Also just give a little comparison in company size CDprojektRed has 112 employees (take the numbers for the following with a grain of salt as the numbers are from Wikipedia) Valve by comparison have over 400. 

So I would recommend that GOL start actively asking developers their opinions on developing on Linux. I know in my upcoming interview with Hugh Jeremy from Unknown Worlds. Here is just one example of the questions I asked. 


There have been some developers who have brought their games over from Windows to Linux. Some of these developers have complained specifically about the debugging process using GDB (GNU Project Debugger) and the lack of good interfacing IDE's being the biggest determent to bringing games to Linux. Whats your take on the subject?


For those that don't know this was a very specific complaint from Jonathon Blow(creator of Braid.) If Linux gamers and community want to see games on Linux then address the problems that people see in the platform, and do not pretend like they don't exist.

Let's take an answer like helsinki_harbor's from right above me: these are all generally community-run projects. Let's suppose that we roll out Linux support and rely on one of those community-run projects to help us support GOG.com's Linux release. What happens if the community behind it decides it's sick of it and gives up? What happens if the project runs into idealogical problems and splits into two projects, each of which focuses on one particular area, but we need the output of both?

As technical note: this approaches are meant as much as possible robust bundle approaches which should need zero adaption on distro progress or distro variations. So no adaptions from GOG or a community side should be needed on created packages, exactly the solution you are looking for for direct deployment of binary software. 

you are all thinking like Linux fans, not business people. You're only looking at upsides and positives, not the potential downsides and negatives

Oh, yes, the almighty business person explains the world to the proles.

Let's take an answer like helsinki_harbor's from right above me: these are all generally community-run projects.

You know what else are community-run projects? ScummVM. And DOSBox.

Let's suppose ScummVM pulls an FFmpeg and splits down the middle.

Hell, there have been daydreams about splitting off a ScummVM-core for use in other projects on the mailing list for years now. Are they substantive? Do I think it's likely? Do I think the project as such would not live through such a change? No³. But it's possible.

Another thing: Unfortunately, many of our awesome porters are busy with their real life (no one will fault them for that, of course). Now suppose that we suddenly can't provide Mac OS X binaries anymore. And thanks to some oversight, the codebase doesn't even compile or work on Mac OS X either. Likely? It's possible.

So when it comes to silly presupposition such as these, you are already "gambling with money".

It's entirely possible that a sufficiently poorly-thought out Linux rollout could cost GOG.com millions of dollars

Any sufficiently poorly though-out decision will cost you money. The solution is to think things through, not to sit on your thumbs!
I'm sure entering this whole "old games" business in the first place was a calculated risk. Did you go "Oh, it's possible no one wants to buy those old games. Or no one would give use the rights to sell them. So let's forget about it."? No, of course not.

it's the same reason that many of the Linux community aren't happy with the OS anymore: there's a single point of contact (i.e, Canonical)

The issues people have with Canonical are far more complex. You have no idea what you're talking about.

But I do not believe that GOG.com has gotten where we are today by aspiring to copy Steam. We want to be better than them

...So, because you don't think you can be better than Steam, you choose to be worse?

Actually, Mr Longino, I'm not a fan of either OSes or services. I'm a user, a pragmatist and use whatever works better for me. In this case Linux does for about 90% of the stuff that I do. I've been using it since it wasn't  cool (late 90's) like it is today on my crappy 486 machine alongside Windows 98.

You complained that Linux changes too fast, yes? Mint 13 is one of the LTS releases (based on Ubuntu 12.04 LTS), will be supported until 2017 and the base won't ever change. Only security updates will trickle down. No new features, no new bugs. Debian Stable changes once every 2 years (so next release is in 2015). Google seem to be fine with changes that happen every 2 years (there's a UDS keynote from them). There is no reason not to choose the stable, long-term releases if changes to the OS core is what you people are afraid of. That is what these kinds of releases are out for. Businesses. The community around the Debian project knows this. There are many people there that are either employed by or run their own businesses and know how important a stable OS base is. Ditto for Canonical, RedHat and SuSE.

From everything you said I take it that the only evaluation of what can or cannot be done has been done in-house by staff that apparently lack knowledge. It's normal, from a business p.o.v. attempt to do things in-house, with what you already got, at first. However, since there are clear signals that you went at it the wrong way, a consultant with experience could be brought in to allow you people to properly evaluate the situation with a fresh new perspective on things.

I'm really curious about how GoG are going to cope now that MS have announced that they'll hasten their pace and try to come up with a new version of Windows yearly. Of course, Windows will retain most of the old code and most stuff will keep working, but the same can be said about Linux distributions.

My point is that the reasons you guys provided are those of, please excuse me, ignorant people taking a stab at things during a weekend project. That's not how business decisions are made either. Sorry.

As for not copying Steam, heh, there are ideas worth copying everywhere. Like Apple copied what Xerox PARC had and computers started to have beautiful, intuitive GUIs.Those early GUI ideas have been copied and modified and adapted over the years on a plethora of systems. Copying good ideas is a good thing. It's even better to improve upon them. You also mentioned that some communities are angry at Canonical. Well, part of that is that they're accused of suffering from the NIH (Not Invented Here) syndrome and spun off competing projects like the recent Mir display server. Looks to me like GoG is affected the the NIH syndrome too.

LE: You guys seem to think that for whatever reason, when attempting to support DOSbox or ScummVM titles on linux you're somehow stuck to the versions provided by the distro repositories. This is weird as you seem to be fine to distribute your own versions of the VMs with your Windows and Mac OS installers. Why should Linux be any different? Provide your own copies of DOSbox/ScummVM compiled against a set of libs that you have control of (and which you'll bundle) and job's done.

I have updated with the next answer, I have to agree now they are basically doing a cop-out and using any reason they can not to support us considering what they just said.

EDIT: Let me note: I'm Trevor Longino from GOG.com, in case you don't recognise the user name from our forums. 

Okay, I'll bite. How is that a cop out? You're a fan of Linux, I get it. I have two computers which use Linux--PupEEE Linux and a Mint one--so it's not like I'm opposed to the OS. 

The answer I gave wasn't "marketing B.S." It was the truth. The economics don't work out. I understand that you're all fans of the OS and you're part of an active community that is passionate and dedicated--all things that have gotten GOG.com where we are today--but you're also part of a *small* community. And until we create a better way to actually scale the labor required to test and master builds, it's not economically feasible for us to support even *one* Linux distribution, much less the three that we've targeted as providing a broad enough reach to make us feel happy about moving into the space and doing it right.

I'll admit that this is disappointing news for you guys, I'm sure, but I don't see why it's a source of vitriol.  I would think the fact that we've clearly thought about this in depth--and that we have a pathway for what we need to do in order to implement Linux support--should be more promising than discouraging. Sure, it's not Linux support today, but I think that our investigations and attention in this matter show that, while we're still a small company that's trying to make the best use of our limited staff that we can, this is definitely something that we believe is worth figuring out.  

Trevor, thanks for having the guts to step into the lions den so to speak.

As a linux user I am natually disapointed, but as a linux user I also found the areas on you forum to help me see if the game might run on wine or via dosbox or scummvm on linux, maybe you guys should start with a special forum for that, so those of us who can/want to risk it can post there or get help from others

If i step away from my linux system for a minute and read your posts I appreciate your honest answer, gog is not a charity and if you do not see a valid buisness case then I have to learn to live with that even if I dont like it.

Out of intrest, say the linux distro world stays as it is, you maybe start using things like osb.org to make texting distro's and can automate a bit, how big should the linux market become to make it a good buisness case (lets take steam % for now, maybe they off a bit but they probably the best we have now)

For those that don't know this was a very specific complaint from Jonathon Blow(creator of Braid.) If Linux gamers and community want to see games on Linux then address the problems that people see in the platform, and do not pretend like they don't exist.

Good point, there are many things to address in the linux ecosystem (to make it gaming platform). Here is another good feedback from the developer of Osmos, Dave Burke: 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. Linux loves freedom and choice, which I applaud — but some amount of standardization, collaboration and “Let’s work together”-ness is required for the platform to be friendly to application developers."

Some of these developers have complained specifically about the debugging process using GDB (GNU Project Debugger)

Funny, whenever I have to use Windows, I bemoan the lack of great debugging tools like valgrind.

So I would recommend that GOL start actively asking developers their opinions on developing on Linux. I know in my upcoming interview with Hugh Jeremy from Unknown Worlds. Here is just one example of the questions I asked. 


There have been some developers who have brought their games over from Windows to Linux. Some of these developers have complained specifically about the debugging process using GDB (GNU Project Debugger) and the lack of good interfacing IDE's being the biggest determent to bringing games to Linux. Whats your take on the subject?

I may be mistaken here but why is developing directly on Linux coming into question? This isn't about making games on Linux directly but about supporting games that do run on Linux already.

A valid question to ask for another subject (creating games on Linux) but it's not really to do with this discussion.

Let's take an answer like helsinki_harbor's from right above me: these are all generally community-run projects.

You know what else are community-run projects? ScummVM. And DOSBox.
 
 Let's suppose ScummVM pulls an FFmpeg and splits down the middle.

Exactly what I pointed out in an earlier comment, waiting for a reply on that one too.

You complained that Linux changes too fast, yes? Mint 13 is one of the LTS releases (based on Ubuntu 12.04 LTS), will be supported until 2017 and the base won't ever change. Only security updates will trickle down. No new features, no new bugs.

It's only frozen (apps too)...and still it's only one distro, the distro/DE/etc fragmentation problem is not solved.

The real solution for the ugly compromise of "app-bleeding-edgeness" and system stability is to separate the upgrade cycles of core system (slow) and apps (fast) by a half rolling release model. For that also a stable interfaces between both needs to be defined which would be an opportunity of fixing the distro fragmentation in general.

The distro fragmentation is not a problem it's a feature and it's strength. There is a purpose for everything in the "chaos". There is a purpose to testbeds such as OpenSuSE and Fedora. There is a purpose to the "nutters" running a rolling distro such as Gentoo or Arch just as there is a purpose to Mint, Ubuntu and others. None of those projects are out there because some nerd wanted a bigger e-peen.

The "fragmentation" has already been mostly settled with people choosing Ubuntu and its derivatives. Look at the HW survey on Steam if you don't believe me. Ubuntu won, for better or worse.

Note that various "frozen" distros have ways to unfreeze and refresh applications (even parts of the core if someone so desires). OpenSuSE's build service and Ubuntu with its PPAs come to mind.

I'll stick with Steam anyway. I can get Steam running no matter if I use Arch, Chakra or Debian (hopefully soon Tanglu), and distributions get the things running on the different Distributions, as we can see on Steam.

This is basically what the LSB and Steam Runtime, and sonames are for.

Steam Runtime is a set of standard libraries you can ship against and even redistribute yourself for non steam builds. They are guaranteed to always have a version that is compatible with the version you shipped. If there are specific problems with the binary versions on certain systems the run-time can be recompiled for different distributions whilst still maintaining the same binary compatibility to the shipped Program.

The LSB is a guarantee that a set of specific libraries will be available on any conforming Linux Distribution and between versions of that Distribution (which is a huge set) that nothing will become incompatible or deprecated. Any Library not in the LSB you statically link against or dynamically link and redistribute.

There is nothing stopping GOG providing their own Steam Runtime.

The "fragmentation" has already been mostly settled with people choosing Ubuntu and its derivatives. Look at the HW survey on Steam if you don't believe me. Ubuntu won, for better or worse.

Note that various "frozen" distros have ways to unfreeze and refresh applications (even parts of the core if someone so desires). OpenSuSE's build service and Ubuntu with its PPAs come to mind.

The distro fragmentation is no strength at all. The choice which is important for users is the choice on apps and not the choice on distros. And the distro concept limits the app selection in several ways, one mechanism is that the infrastructure stops scaling around 10,000 apps (ingo molnar Technology: What ails the Linux desktop? Part I. in contrast to a platform structure with ISVs which can easily have millions. See this talk Bringing great apps to ubuntu (around third minute)

Actually I'm not the type to comment on topics like this, but I'll go out of my way this time around. I'm new to this site, no native english speaker and this is my first english post in quite a long time as well so bear with me.

I use Linux OS like Kubuntu and arch with KDE for about 4 years now and am studying computer engineering. Even so, it is obvious to me that i don't quite know a lot about Linux in comparison to some of you guys. So please help me out if I am missing something here.

Reading all this I know one thing for sure:
We have to look at this from both sides of the coin...

This whole topic is not about *we* as a small community against them as businessmen. Being pissed at their decision won't get us anywhere. We are the ones who want something from them, while they are making their decisions, after all. We want more support from them, so we, as gamers, can enjoy what we want to enjoy the most: Games.

Therefore neither a flamewar nor a counter to every argument will get us anywhere. TheEnigmatic came to us after all, even though he knew something like that was coming up. Wouldn't it be wiser to analyze what was said? Actio et Reatio...

Example:
For them, this decision obviously NEEDS to be about money. It simply is their job after all. But there is much more to this: Even IF we have the necessary amount of interest in games AND the necessary amount of money to make them interested, the whole process of support OBVIOUSLY is the actual issue here.

As was said way earlier (too lazy to quote/cite this) we as a community are united AND divided. Our freedom of choice (actually the current system behind it) simply is a curse and a gift at the same time. This whole issue obviously is about the "curse" part right there.

This is basically what the LSB and Steam Runtime, and sonames are for.

Steam Runtime is a set of standard libraries you can ship against and even redistribute yourself for non steam builds. They are guaranteed to always have a version that is compatible with the version you shipped. If there are specific problems with the binary versions on certain systems the run-time can be recompiled for different distributions whilst still maintaining the same binary compatibility to the shipped Program.

The LSB is a guarantee that a set of specific libraries will be available on any conforming Linux Distribution and between versions of that Distribution (which is a huge set) that nothing will become incompatible or deprecated. Any Library not in the LSB you statically link against or dynamically link and redistribute.

There is nothing stopping GOG providing their own Steam Runtime.

Sadly, the LSB has failed since 2006 to enforce a standard platform among the distros, binary deployment of software is still a pain.

Bundleing is nice approach but would need support by the distros... who hate it with passion as such distro agnostic approaches questions their role as central control instance.

Bundleing is nice approach but would need support by the distros... who hate it with passion as such distro agnostic approaches questions their role as central control instance.

What the? Since when do I need to ask anyone anything about bundling libs in my tarballs/installers? Seriously, WTF? Nobody needs to ask distros for anything. That is the whole point of a bundle.