Making Money As An Open Source Game Developer? 63
Fastball asks: "I have a couple ideas for some web-based games that I'd like to develop. I'm an avid Linux, Perl, Apache, and MySQL user, and I believe in the GPL. However, I'm trying to figure out how I can develop these games as open source and still make a buck. It would be rewarding to produce them without seeing a profit, but I'd like to make enough money to get a company going and quit my current, uninspiring job. Can I get there via open source, would I be more profitable going closed source, or should I forget about make money altogether?"
Open engine, pay data (Score:1, Interesting)
Essentially do the same thing as id software does, but just release the source a lot sooner (at release time)
The short answer (Score:3, Interesting)
This isn't to say you can't capitalize on a novel idea, but those are hard to come by and most likely you'll get over-excited about your own project and release pure crap. Yes it happens to every one of us; you fall in love with your pet project so damned much that you fail to see how ugly and unfinished it really is. Then you expect everyone to wet their boxers the instant they witness your creation, and then you fall in a deep depression and start doing heroin when it's 2 years later and you haven't seen a dime from it.
Like anything in computers, if you want to do it right, do it for the hell of it. People who jump in "for the money" usually don't get very far, just think of all your former co-workers who had lame CS degrees from "ICS Remote learning" and you'll quickly remember the difference between a 'hacker' and a 'consultant'. Now which generalized term would you attibute to a game developer ? Ah-ha!
You just can't tell yet (Score:1, Interesting)
If you love this idea so much you are going to do it no matter what, it will probably turn out ok.
A strategy for open source game development (Score:2, Interesting)
The basic strategy I would see for open source game development would be to keep the data proprietary, similar to the current situation with Doom and the first two Quakes (and I think some others).
This is based on the idea that game engines resemble each others to some degree and that the differentiating factor will be the maps/levels/artwork/scripting and so on. You can thus get improvement done on the engine contributed back to you, and others can make their own original games with your engine, but nobody is playing your exact game for free.
This strategy, of course, supposes that there is some significant amount of non-code data involved. If this is a puzzle game whose's only non-engine resources are backdrop images, this strategy is not effective.
Remember to mark down contributions from the outside somehow, because you might want to relicense the engine under a non-open license (or maybe just change the license to another open source one), and you'll have to ask permission from the copyright owners of these patches (remember what is happening to Mozilla [mozilla.org]!). Having them assign copyright to you, having a "clean" codebase branch or keeping contact information are three possible approaches.
Also, if you have some truly innovative technology in the engine that you think nobody else has, it might make sense to hold off the release a bit, so that you can build a market lead on that technology, then as competitors come up with equivalent technology, you can then release the source code.
See Software Secrets: Do They Help or Hurt? [opensource.org].
I can't belive it's not been suggested much but... (Score:1, Interesting)
Ok, so I saw a couple people go over this, but, here is the crux of the matter with open source game development; Content Vs Code.
I too have been thinking a great deal about this, and here's the scheme I've thought of that would be both open source, and able to make money. In a nutshell, as someone else already suggested, release the engine, and keep the content under copyright. Now, here's the catch. Where do you draw the line with what's content, and what's code? Most would say, if it looks like code, it is, but I say that, if it's pure game logic, that's content. Lets say, for example, that, as most games with extensive in game AI or physics logic code do, you build a scripting engine into your game to drive the tweakable details. This is how a good number of game engines work, the Unreal engine being a good example. If you wish to open source your game, I'd say, open source the engine, and keep the game logic under the same 'pay for distrobution' licence as your content. Most likely best to provide it under a 'viewable source' licence, at least for the more basic/example logic, to encourage mods (good for any game), but aside from that, that type of code has more to do with your game design, the part you are trying to sell, than it does with the nuts and bolts part that everyone would benefit from having to use, like networking or graphics code.
Anyway, just my $0.02 ;p
Here's the approach I was going to make. (Score:2, Interesting)
Advertising (Score:2, Interesting)