Quoting: liamdawe

Quoting: Quote from TheEnigmaticTMaths stuff

I understand your reasoning now but I completely disagree, using market share like that (and a complete estimation of the actual marketshare which is heavily debated pretty much anywhere) should never be used like that.

Sure. Let me just add a coda here that, while I did not use any of our internal numbers for discussion here, we do know how many of our sales come from users who are on our website using Linux, and we were able to draw our own conclusions as to what expected growth we would see after we officially supported Linux--based on our own experience with MacOS--and while our numbers were quite different, the conclusions we reached are the ones I'm giving you.

View this comment - View article - View full comments

Quoting: liamdaweStill lost me sadly, I am not a businessman which is why unlike some other people I won't be calling you colourful names but if I spent $1,000 in time to fix a Linux issue on a game and made $2,000 from it, that's $1,000 in revenue.

Ah. Easy enough then. Let's say I am cost accounting--that is to say, trying to make sure that the things I spend money on are things that actually earn me money back. I spend $1,000 fixing a Linux bug.  Since Wikipedia suggests that Linux is 1.5% of the market, that means that for every $1,000 I sell, I assume that 1.5% of it is earned from Linux users. So for every $1,000 earned, I'm actually earning $15 from Linux users.  

Now, GOG.com receives 30% of the gross price of a game. So if I want to earn back the $1,000 of expenses, I need to gross $3,333 in sales. But I want to see if my expenditure of fixing this Linux bus is worth the money, so I want to project the overall revenue from the game to get a feeling if it is worth the money to fix. To have Linux gaming bring in $3,333, the percentages suggest I need to gross $3,333/.015. Which is $222,200. So to earn back a $1,000 expense on a Linux-specific bug fix, a (very) rough projection is that the overall gross revenue from the game should be assumed to be about $200,000.  Otherwise, the cost required to fix that Linux bug will, presumably, not recouped and, instead, I would have been better off putting that $1,000 elsewhere, regardless of whether or not the game itself was a success.

Does that make any more sense?

View this comment - View article - View full comments

Quoting: liamdawe

Quoting: Quote from TheEnigmaticTLinux, though? That's a bastard. For $1,000 in costs, we need to assume that the game will sell about $200,000 worth of games (x*3)/.015 before we've probably recouped the cost of the Linux effort. That's a whole lot of profit that we need to earn from a game--before we even know how well it will sell--before we can assume that we will make back the money invested in.

Sorry but now you have completely lost me.

I honestly don't get your math at all or your reasoning for why $1,000 of costs for a Linux version means you need to get $200,000 in sales?
I mean seriously come on, that's just a joke. If it costs you $1,000 you need to get $1,000 to break even, anything above that is revenue, revenue you wouldn't have gotten without it.

I may not have explained that fully. If I'm adding a cost for a specific project, I want to make sure that the costs from that project are worth it. So, given the size of the market share of Linux, if I'm spending $1,000 to fix a Linux issue, then I'd generally assume that the game will need to sell a heck of a lot of copies for it to actually recoup the Linux-specific costs.

EDIT: And, as a really rough back-of-the-envelope statistic, that means you need to sell enough copies of the game that, given the small market share, you assume that the percentage of people who bought it equated to your costs. In that case, my rough math was (1,000*3)/.015. 

On the other hand, I'm working on this in between other spreadsheets. I may have gotten the maths wrong?

View this comment - View article - View full comments

Quoting: SilviuThere's also the issue of who  the people that assess what needs to be done in order to provide proper support are. The way TeT describes the process was to throw PupEEE Linux and Mint on some machines and something something until something else broke. When it broke the conclusion was drawn that it sucks and does not warrant effort. The ones doing the assessments were people that don't seem to know much about how things are or can be done on Linux machines. A weekend (please tell me you did not waste a month banging your head against the all) project like the one TeT describes does not make it market / technology research. It's entertainment.

You're literally making stuff up.

For personal use, I use PupEEE Linux and Mint. For institutional research--as mentioned in the above--we evaluated Mint, Debian, and ChromeOS, and did do in depth. I don't know what you consider a sufficient audit, but I consider four people working for two weeks on researching build frequency, library deprecation, market share, bugs, immediate portability, etc. and etc. is sufficient for us to reach conclusions. I'm sorry that they're not the conclusions that you want, but please don't assume that our QA, IT, and dev teams are incompetent. We went about this seriously, we investigated it fully, and we continue to be evaluating this rationally and reasonably. As soon as this is a good move for us--whether because of something that we do on our end or some new technology that gets conceived--we will certainly be happy to add Linux support.

View this comment - View article - View full comments

Quoting: liamdaweWell 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 [External Link] 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?

For DOSBox and SCUMMVM, we have points of contact who are decision-makers in the project and who we established relationships with prior to launch. Also, those projects are substantially smaller-scope than creating an entire OS and maintaining it, so there's less likelihood that we'll see a catastrophic breakdown of the team maintaining it.

And you're right: we could just port our DOSBox games to Linux. The problem enters when we begin to look at cost-accounting. Let's talk about market share: http://en.wikipedia.org/wiki/Usage_share_of_operating_systems [External Link].

We've already publicly stated that we receive 30% of the revenue of a game's sale (http://www.gog.com/indie). Out of that comes costs, VAT, processing fees, and whatever the hell else goes on. I'm not gonna keep track of all of those, because it makes the math a pain in the butt. Let's stick with 30%, even though you should realize that our income is actually less than that for any given game sold. When we're looking at adding a cost associated with Windows OS for a game's release, that means that for a cost of x, we should assume that we will sell at least (x*3)/.9 worth of copies for it to work out. For $1,000 of expenses, we assume we'll need to sell about $3,333 worth of games. That's not hard to do at all.

For MacOS, this is tougher. The math there is (x*3)/.08 (using the math from wikipeida; I'm not gonna share internal revenue splits from GOG. :)). For $1,000 of Mac-related costs, we need to project that we expect to see a game sell about $37,500 for the Mac portion of the costs to recoup. That's challenging, but not impossible. 

Linux, though? That's a bastard. For $1,000 in costs, we need to assume that the game will sell about $200,000 worth of games (x*3)/.015 before we've probably recouped the cost of the Linux effort. That's a whole lot of profit that we need to earn from a game--before we even know how well it will sell--before we can assume that we will make back the money invested in.

Now, of course the math isn't quite that simple--Linux-specific fixes tend to drive Linux-specific revenue, after all. So let's just look at the math required to take an already released game and get it ready for Linux. As a completely wild guess, I'd estimate it takes about 100 - 150 hours of labor from "Hey, we would like to sell this classic game on GOG.com" to "released". This is true of DOSBox games, SCUMMVM, or any other classic release. We test every classic game we release, remaster it, jigger with the settings, and generally invest time in the games. This number isn't reduced substantially for adding a new OS to already-existing signed classic titles: we don't have rights to sell on that OS, we have done no testing, we haven't made any masters... it's not as simple as turning on a switch. So now consider: let's assume we want to launch with 60 games on Linux (that's the same number we had on Mac). 60 games * 150 hours * cost of labor....that's not cheap. Even if I assume US minimum wage for all of the labor employed, that's 60 * 150 * 8.75 * 3 = $236,250 USD games sold--Linux copies only, mind you--before it looks like this is a break-even point. The usual basis for "successful operation" is 300% revenue over costs, which means we'd need to believe that we will sell nearly a million dollars worth of Linux copies of those games for the effort to be considered "fiscally prudent." Keep in mind that none of the above numbers account for the costs associated with the fact that we would need to spend a lot of time and money learning how to actually handle releasing a game on Linux, hiring new staff, and et cetera. 

Now, others have mentioned that we sell games that right now support Linux and we don't sell Linux versions of those games. Part of that is because, again, we support our games. So many of the staffing costs associated with "adding Linux games" to GOG.com will be present whether we're re-mastering games ourselves or not. In either case, due to the fact that we're fundamentally a different business model than Steam or Desura, we must take a different approach to Linux support than they are. They can pawn you off on a developer and say, "This is not my problem." On GOG.com, it is our problem. 

All of this leads to a single point: the processes are not as simple as you think they are, and the risks are higher than you believe they are. We did not make the decision to move into the MacOS lightly, and it was something that took a lot of time and work to do. If we ever move into the Linux space, it will be because it looks like we have figured out how to add Linux support in a manner that is consistent with our core values, and something that we believe we can be proud of and you can enjoy.

View this comment - View article - View full comments

Quoting: liamdaweConsidering 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.

View this comment - View article - View full comments

Quoting: liamdaweI 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.  

View this comment - View article - View full comments