Some thoughts on commercial FOSS game development
It's been a while since I last stirred up controversy on the freegamer blog, so I thought today I'd talk about -- gasp -- developing FOSS games commercially.
There's a common misconception out there (although I'm guessing a majority of the readers of this blog are aware of it) that software can't be both libre and commercial (I use libre here instead of free to make it clear that I'm referring to free as in speech and not as in beer). This is a problem that the FOSS community has struggled with since the very beginning. Writing FOSS full time is difficult because, let's face it, your internet connection costs money (not to mention other minor things like food and rent). As such, a lot of FOSS development, particularly game development, is done as a hobby.
The Open Source development model is somewhat difficult for a small developer (such as an indie game studio) to make money at. The current practice is to make the game code open and keep the game content (graphics, sound, levels, etc) non-libre in some way. This is a known business model that's being used right now, so I'm not going to discuss it in great detail in this particular blog post.
Instead, I'll be asking this: How close can we get to a 100% libre game and still make money while we're developing it?
The big problem here is that people tend to be more willing to spend money if they get something immediate in return. Take, for instance, the first Humble Bundle, which made over a million dollars. A fairly significant portion of that money was from people who wanted to see the code for the games contained into the bundle open sourced. On the other hand, open source projects that accept donations tend to get a slow trickle of cash (if any at all) -- certainly not enough to fund a single full-time developer, let alone several. Yet, if you consider it, the folks who work on FOSS projects have already put the time and effort into building their games. Aren't they equally deserving of payment?
Now, I'm not trying to guilt anyone into running out and donating to FOSS game projects (although I'm sure a lot of them would appreciate the help). The point I'm trying to make here is about human nature -- if you want sustained, significant income, people need to receive something in return when they give you money. Unfortunately, open source software is somewhat resistant to this kind of business model. While you're not technically obligated to give your source code to anyone who wants it, you are obligated to give it to anyone you give an executable to. Then, that person is free to distribute the source code that you gave them. Hence, one person could buy your code from you and then give it away to everyone else. And as a FOSS enthusiast myself, that's how I prefer things to be.
So, to summarize thus far, in order to pay the rent, you have to make money. In order to make money, you have to sell something. In order to viably sell something in any reasonable volume, the thing you're selling can't be libre. So where does that leave us?
I've been pondering some ideas for a while ago, and I wanted to throw them out there and get an honest discussion of their advantages and disadvantages.
My first thought is that a commercial FOSS game developer could release both their game and their game media (graphics and sound) into the libre ecosystem, but keep their glue code (game scripts, levels, plot, etc) non-libre. This method allows people to build whatever mods they want, and use your code and media to create their own games, while still putting you in a position to sell the substance of your game. The disadvantage here is that there's still a fairly significant portion of code and data that's not really free -- so you miss out on the benefits of having a completely libre game. For one thing, if you do this, you can't get your game into a number of major Linux distributions. The other issue is that people will be less likely to submit patches for your glue code if that code isn't really FOSS. So, while you've established a revenue stream, you lose out on certain benefits because your game isn't 100% libre in all respects.
Another possibility is the idea of a source ransom. Let's say I write a game (including the game data, glue code, and media) and release it all under the GPL. At this point the game is fully playable, but there are definitely some places where new features could be added. If I wanted to follow a ransom model, I could code up version 1.1 and not release it immediately. Instead, I would release screenshots and preview videos of it, then ask people to pay some arbitrary sum of money for the version I just created. Since the code is 100% mine, I'm not bound by the GPL, so I can send them the binary (or even the source code) under a more restrictive license, preventing them from distributing it. When the number of donations reaches a set amount, the new version is released under the GPL. Rinse, repeat. Any user who has already paid for the software receives the new version early, and the source is released when you recoup your development costs.
Doing the above, we've solved the issue of getting into the major linux distros (although the latest version wouldn't be eligible), but we've essentially closed ourselves off from outside contributions, since we have to own the copyright on all of the code in order to keep it closed, even for a limited time. Outside contributors could still contribute, provided they signed the copyright over to the main developer, or contributed the code with a BSD-style license that doesn't have a share-alike requirement.
As a variant of the above, you could accept GPLed patches from people and simply not release the code to anyone until the funding goal has been reached. The downside to this, though, is that you still can't really get outside help developing the latest version.
Understandably, there's always a lot of suspicion when dealing with commercial interests. As such, I imagine the reaction to this sort of development model wouldn't be uniformly positive. However, I'd like to point out an up side that people may not have considered: FOSS game development, as I said, is a hobby for most people. If you're lucky, you can spend maybe 5-20 hours per week doing it, often with long periods of downtime when real life happens. As such, FOSS game development is often slow, and the developers themselves tend to come and go, sometimes taking promising projects with them. On the other hand, if you can turn it into a viable business model, you can suddenly reliably spend 40-60 hours per week working on your project, which opens up a world of possibilities. With enough cash flow, you can even hire additional full time artists and developers, and build games that are much larger in magnitude than normally possible under the traditional FOSS devlopment model. And while this may require that you keep the most recent version closed source, the overall benefit to the community may be much higher, since your game will most likely progress far faster than it otherwise would, meaning that more code and media would be released into the libre ecosystem sooner.
Anyway, that's it for today. I'd be curious to hear what people think. If this ruffles your feathers, please be very specific as to why. If you have more ideas, I'd love to hear them. If you see problems making the above ideas work, tell me about them.
Peace,
Bart K.
There's a common misconception out there (although I'm guessing a majority of the readers of this blog are aware of it) that software can't be both libre and commercial (I use libre here instead of free to make it clear that I'm referring to free as in speech and not as in beer). This is a problem that the FOSS community has struggled with since the very beginning. Writing FOSS full time is difficult because, let's face it, your internet connection costs money (not to mention other minor things like food and rent). As such, a lot of FOSS development, particularly game development, is done as a hobby.
The Open Source development model is somewhat difficult for a small developer (such as an indie game studio) to make money at. The current practice is to make the game code open and keep the game content (graphics, sound, levels, etc) non-libre in some way. This is a known business model that's being used right now, so I'm not going to discuss it in great detail in this particular blog post.
Instead, I'll be asking this: How close can we get to a 100% libre game and still make money while we're developing it?
The big problem here is that people tend to be more willing to spend money if they get something immediate in return. Take, for instance, the first Humble Bundle, which made over a million dollars. A fairly significant portion of that money was from people who wanted to see the code for the games contained into the bundle open sourced. On the other hand, open source projects that accept donations tend to get a slow trickle of cash (if any at all) -- certainly not enough to fund a single full-time developer, let alone several. Yet, if you consider it, the folks who work on FOSS projects have already put the time and effort into building their games. Aren't they equally deserving of payment?
Now, I'm not trying to guilt anyone into running out and donating to FOSS game projects (although I'm sure a lot of them would appreciate the help). The point I'm trying to make here is about human nature -- if you want sustained, significant income, people need to receive something in return when they give you money. Unfortunately, open source software is somewhat resistant to this kind of business model. While you're not technically obligated to give your source code to anyone who wants it, you are obligated to give it to anyone you give an executable to. Then, that person is free to distribute the source code that you gave them. Hence, one person could buy your code from you and then give it away to everyone else. And as a FOSS enthusiast myself, that's how I prefer things to be.
So, to summarize thus far, in order to pay the rent, you have to make money. In order to make money, you have to sell something. In order to viably sell something in any reasonable volume, the thing you're selling can't be libre. So where does that leave us?
I've been pondering some ideas for a while ago, and I wanted to throw them out there and get an honest discussion of their advantages and disadvantages.
My first thought is that a commercial FOSS game developer could release both their game and their game media (graphics and sound) into the libre ecosystem, but keep their glue code (game scripts, levels, plot, etc) non-libre. This method allows people to build whatever mods they want, and use your code and media to create their own games, while still putting you in a position to sell the substance of your game. The disadvantage here is that there's still a fairly significant portion of code and data that's not really free -- so you miss out on the benefits of having a completely libre game. For one thing, if you do this, you can't get your game into a number of major Linux distributions. The other issue is that people will be less likely to submit patches for your glue code if that code isn't really FOSS. So, while you've established a revenue stream, you lose out on certain benefits because your game isn't 100% libre in all respects.
Another possibility is the idea of a source ransom. Let's say I write a game (including the game data, glue code, and media) and release it all under the GPL. At this point the game is fully playable, but there are definitely some places where new features could be added. If I wanted to follow a ransom model, I could code up version 1.1 and not release it immediately. Instead, I would release screenshots and preview videos of it, then ask people to pay some arbitrary sum of money for the version I just created. Since the code is 100% mine, I'm not bound by the GPL, so I can send them the binary (or even the source code) under a more restrictive license, preventing them from distributing it. When the number of donations reaches a set amount, the new version is released under the GPL. Rinse, repeat. Any user who has already paid for the software receives the new version early, and the source is released when you recoup your development costs.
Doing the above, we've solved the issue of getting into the major linux distros (although the latest version wouldn't be eligible), but we've essentially closed ourselves off from outside contributions, since we have to own the copyright on all of the code in order to keep it closed, even for a limited time. Outside contributors could still contribute, provided they signed the copyright over to the main developer, or contributed the code with a BSD-style license that doesn't have a share-alike requirement.
As a variant of the above, you could accept GPLed patches from people and simply not release the code to anyone until the funding goal has been reached. The downside to this, though, is that you still can't really get outside help developing the latest version.
Understandably, there's always a lot of suspicion when dealing with commercial interests. As such, I imagine the reaction to this sort of development model wouldn't be uniformly positive. However, I'd like to point out an up side that people may not have considered: FOSS game development, as I said, is a hobby for most people. If you're lucky, you can spend maybe 5-20 hours per week doing it, often with long periods of downtime when real life happens. As such, FOSS game development is often slow, and the developers themselves tend to come and go, sometimes taking promising projects with them. On the other hand, if you can turn it into a viable business model, you can suddenly reliably spend 40-60 hours per week working on your project, which opens up a world of possibilities. With enough cash flow, you can even hire additional full time artists and developers, and build games that are much larger in magnitude than normally possible under the traditional FOSS devlopment model. And while this may require that you keep the most recent version closed source, the overall benefit to the community may be much higher, since your game will most likely progress far faster than it otherwise would, meaning that more code and media would be released into the libre ecosystem sooner.
Anyway, that's it for today. I'd be curious to hear what people think. If this ruffles your feathers, please be very specific as to why. If you have more ideas, I'd love to hear them. If you see problems making the above ideas work, tell me about them.
Peace,
Bart K.
Comments
Post a Comment