Wait! Don't skip this article. I know you think this doesn't apply to you, after all you don't program for Linux. But there is a lot more to open source than just the penguin. Many companies are taking advantage of open source software, much in part to the increasing popularity of Linux. Open source has become a big buzzword, with many people not really understanding what it really is.
In fact, most people are using open source software and don't even realize it. When you are looking at a website or checking your email, chances are the inner-workings (the mail transports and web servers) are open source.
So where do we begin? Lets start with a little history lesson behind open source.
Sharing source goes back as early as the 1950's when the SHARE group was formed to exchange code for IBM mainframes. IBM released the source to the software for their mainframes, allowing changes for specific needs. This updated code was passed around the SHARE group, creating the earliest form of open source.
In 1985, The Free Sofware Foundation was formed by Richard Stallman, to to promote the freedom to distribute and modify computer software without restriction. Stallman had been working in the AI department at MIT and left in 1984 to began writing GNU free software. (GNU is pronounced "guh-NEW" and it stands for "GNU's Not Unix").
The Free Software Foundation (fsf.org) defines free software is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech," not as in "free beer." Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software.
In 1997, a paper written by Eric S. Raymond, The Cathedral and the Bazaar triggered a series of events that led to the forming of the Open Source Institute. One of the more significant events at the time was Netscape releasing the source to their browser. That project is still alive and well with various projects like the Firefox browser and the NVU (nvu.com) HTML editor. The OSI was jointly founded by Eric Raymond and Bruce Perens in late February 1998 , as a general educational and advocacy organization.
Next, it is necessary to understand what open source software is and what it is not. Open source in its purist sense is software that has the source code available to anyone who desires it. That individual is free to use the code as he sees fit, however any modifications to the code must be made available for everyone to use and modify, under the same conditions. According to opensource.org, "Open source promotes software reliability and quality by supporting independent peer review and rapid evolution of source code."
It's not source code that you download from a website with permission to redistribute and modify and also to add additional restrictions to it. It's not a free program like Artweaver (artweaver.de) that's made available to the public for free without the source code. It's not source code released into public domain where the rights to the code are forfeited. It is also not source code that's distributed freely with a clause saying it has to be non-profit. Open source creates a system of free access of information for the greater good of the project.
There are two categories of open source licenses, copyleft and permissive. A copyleft license is primarily concerned with preserving open software rights in forked versions of the project. It requires that any subsequent code be released and any finished products release the source code for the product. A permissive license places minimum restrictions on the source code. It can be modified without releasing the modifications. A permissive license can work hand-in-hand with closed, proprietary code.
Of the copyleft licenses, the most widely used is the GPL from the Free Software Foundation. It has a couple of variations, The LGPL and the AGPL. The LGPL (Lesser General Public License) makes a specific piece of code open source, but other parts of the project can be proprietary source code. The AGPL (Affero General Public License) focuses on software as a service and relaxes some restrictions on releasing the source to network clients. You can find out more about these licenses at gnu.org/licenses.
The BSD is a popular permissive license, in fact often a permissive license will be referred to as a “BSD type” license. There are a number of variations on each of these licenses. If you go to opensource.org/licenses, you can find a number of licenses approved by the OSI.
There is great debate about the various types of licenses and the impact of each. Some game developers shy away from a restrictive copyleft license. There are parts of games that sometimes need to be kept away from view. Sometimes to stop cheating, sometimes to create an edge in the market. Also, there is the perspective that a copyleft license doesn't provide true freedom. There is a great blog post on copyleft (GPL) licenses for games here on GameDev.net
Really, the choice in license is about what is best for your project. It may make more sense to have closed source or it may make sense to use open source and open your own source. There is a great overview of the legal aspects of open source licenses here.
There are several open source games available. Some games have been released as open source, some have become open after a commercial release. On Wikipedia is a list of open source games, I'll highlight a few here.
Parallel Realities has a number of open source games including Blob Wars: Metal Blob Solid a 2-D arcade game. A cool thing that Parallel Realties does is release the making-of for several games.
Alien Trap has released a 3D shooter called Nexuiz, a game that is built on the Darkplaces engine, a fork of the Quake 1 engine. There is a Super Mario Cart clone called SuperTuxKart. The site has a good bit of information about the workings of the game and how to create additional levels.
Vega Strike is a 3D Action-Space-Sim. The website has a great deal of documentation and a developers blog. Warzone 2100 is a real-time strategy game that was released commercially in 1999, then released as open source in 2004. All of these games (and there are many others) provide a good starting point for developing your own game and for seeing various ways to organize an open source game project.
There is also an open source game that is a joint venture between Blender and Crystal Space teams. The name for the project is Apricot and is worth checking out. Speaking of Crystal Space, there are a few commercially released games that were made from the CS engine, including Ice Land.
There are a few options for getting some funding for open source games. Right now Google has the Summer of Code that pays college students to develop open source software over the summer. There are a couple of other groups that provide funding to open source projects, one is Linux Fund and another is SPI. There is not a lot of funding money to go around, but every little bit helps. Another idea is to do like the Apricot project and pre-sell your final product. Some vendors may also donate hardware to an open source project.
There is a great number of tools available for about anything you need to do in creating a game. Using open source software can greatly reduce the cost of development. For example, you can use Eclipse for your IDE, Open Office for document writing, GIMP for editing raster graphics, Inkscape for vector editing, Blender for 3D modeling and Audacity for sound editing.
When using open source tools, at the very least, provide feedback. It will give you and the rest of the world a better product. If you have time to spare, write some code or documentation. It would still save money from buying the commercially available products.
Many think that the single greatest element in the rapid advancement of the gaming industry is the wide-open exchange of knowledge. There are many websites with gaming information, source code for games being released to be examined and studied, magazines and books giving anyone the ability to understand game making techniques. Open source also encourages and promotes this same information sharing.
Back in 2004, I started using the Mojavi framework for web development. I was able to get quite an education on the Model View Controller pattern from Sean Kerr, the developer of the framework, just by hitting the forums, IMing and volunteering to help out when possible. In return I wrote documentation and tutorials for the project. We both benefited (and so did the community) and as a bonus, I had the opportunity to get to know a great person. Unfortunately, Sean was unable to maintain Mojavi, but the project forked and now lives on in Agavi.
Using open source libraries is a great way to reduce time in a project, save money and have more developers working on making the best library possible. The many eyes on a project are one of the greatest strength of open source software.
There are a number of open source libraries available, doing a search for your need with the phrase “open source” opens a world of possibilities. A few libraries to consider are the Simple and Fast Multimedia Layer, a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick and networking. You could use the SQLite database in your game for data storage.
Do you need a game engine? You could use the Crystal Space engine (crystalspace3D.org). Is there a need to write a scripting language when you could use Python (python.org)? If you need an audio library then you could use OpenAL. Is it completely necessary to write a physics library when the Bullet library might work for you?
Imagine the ego trip for a hard core gamer to be able to say that he beta tested the newest RPG on the market. This alone will draw a number of contributors to an open source game project, especially if there is some credit in the finished game.
Having additional coders for fixing or improving code after an alpha or beta stage can be a great benefit to the project. Often times, as the project comes to a close, there is great pressure to hurry up and get the product finished. This is an area where open source can also be a benefit. The additional coders working on your project will be anxious to see the project finish and potentially increase their productivity.
I did an informal survey of developers on a couple of open source projects. I found, on average, the programmers that responded to the survey spent 87 hours a month writing code for various open source projects, the time spent ranged from 10 hours a month to about 350 hours a month. Look at it this way; if you had 4 outside developers (which is very realistic) spending an average of 87 hours a month on your project, you have picked up the equivalent of a full time programmer for the project without the added cost.
Additionally, just over half of those who responded say they make sure the code compiles and cleans up minor errors on a daily or bi-daily basis. Also, many developers spend time on documentations and product support.
A few years back, in writing a 3ds importer for the Crystal Space library, I felt like there could be a savings in time if I could find someone who had already done the dirty work of translating the 3ds information. I found lib3ds (lib3ds.sourceforge.net), which suited my needs, however I found that the I/O interface was specifically for disk access. Crystal Space uses a Virtual File System making it incompatible with lib3ds.
I sent an email to JE Hoffman, project leader of lib3ds and told him my dilemma. He gladly rewrote the interface to use any data format and it was integrated into Crystal Space. However, the story doesn't end here. Lib3ds was known to work only on Windows and Linux. Crystal Space covers many more platforms. I sent an email to the Crystal Space list asking for help for lib3ds to get it to work on other platforms. A Crystal Space developer, Eric Sunshine, responded and helped out on making lib3ds available for more platforms.
This was a win-win situation. Crystal Space got an importer; lib3ds was made available on more platforms. The programming community also benefits with having a more versatile library.
While this may not seem like the greatest example, how many trivial programming tasks consume parts of your day? Do you really need to write a compression library or will zlib work just as well for you?
Project stability could be the greatest case for using open source software. Open source software has been peer reviewed every step of the way. It has been tried in a number of environments and under a number of conditions. Just think of the number of machines with the wide variety of configurations that will be testing the product.
Mature open source code is as bulletproof as software ever gets. Why? It's always being looked over and compiled and tested. In my survey of open source developers, a number of developers spent a sizable percentage of their time making sure the code was in tip-top shape.
Why do game companies limit the number of platforms for which the product is available? Is it because they don't want that market share? Of course not. The reason is that that market share doesn't cover the costs of developing for that platform.
Would that platform be profitable if it could be added for next to nothing? Absolutely. This is another added benefit of open source; end users are often more than willing to do the necessary work to make a game work on their platform. Each added port is an added market for the game.
The additional exposure for the game generated by being an open source project can also help the project gain a greater market share. Anyone contributing code to the project would have an additional incentive to purchase the finished game.
There have been many lamentations lately for the solo game developer. Oh, the good ol' days of the past when you could write a game yourself, put it in a zip-lock bag and sell it at a computer show. I don't believe the days of the solo developer have to be a distant memory of the past.
Granted, a single developer will never put together a project with the scope of Scorched 3D, but a Zuma type game could be developed by a single developer. There are a number of open source tools and libraries available for creating Flash games or Java based games that be delivered across a number of platforms.
The first argument you will hear from businesses concerning open source is that you cannot make money with it. Au contraire. There are companies making money with open source and we'll look at a few and look at some ways that you can use open source to make money, making games.
The first thing I would recommend is heading over to pentaho.org/beekeeper to download and read the brilliant paper called The Beekeeper. It is a well thought out analogy on making money with open source and can provide great insight into how open source fits into a business model.
If your focus is making games and not creating technology, open source is an excellent way to focus more of your resources on the game play and less on the technology involved. A line of titles could be made from open source code, keeping the content of the game protected and making money from that as normal, just the cost of development would go down. I believe this would also help to shift the focus of games from eye-candy to content.
Dual licensing is the best of both worlds. This can be a working model for companies who make money from selling libraries. You have an open version, licensed with a GPL like license, that helps with development and finding bugs. With the GPL any additional work by other developers would go back to the project. However, if a company wanted to use the library as a base to start from, but not give back any new development back to the community, then you charge the developer for the same software under a different license.
Much of the money made in selling libraries is actually in the form of selling support. This is included in the initial cost of the library, however many have an additional fee for each continuing year after the first year. The same could be done with open source software. The support could include initial training for the product, setting up systems for the product, implementing specific changes to the software and telephone support.
Selling support doesn't have to be limited to software you have developed. Many open source projects fall short in documentation and support. You could step in to offer that service for companies trying to decrease the learning curve.
If you make the drivers for sound cards open source, you increase the potential of your hardware working on a greater number of platforms. With peripherals there is probably no revenue from the drivers so the cost of moving to open source is minimal.
Having the drivers readily available and modifiable encourages developers to add support for a product in the game. This increases the number of products and sub-sequentially the number of potential end users for their product.
In 2007 when AMD started opening up their graphics drivers, Novell released an alpha version of the ATI Radeon driver in just 8 days. It definitely makes more sense for developers who know an operating system to write a driver.
Who could better give a view of a project than one of its developers? There are many writing opportunities available. A book about using the software could be helpful to developers using the software. Magazine articles about the technology used in the software would help to give greater insight into the project and give back to the community.
While this isn't an option for everyone, there are those who could make money this way. A variation on this theme would be giving speeches about areas of the software.
As with any good thing, there are a few downsides as well. This is also true of open source. However, most of the downsides can be dealt with if enough thought and effort is put into it.
Often times group-designing ends up being more talk than action. Or if there weren't a unified direction, the project would end up going nowhere. Either of these could cause the project to go into a serious tailspin.
A cluster could be overcome by having a good design document. Another possible solution to this could be doing all of the engine design internally then opening the project up. It may even be a good idea to delay releasing the code until alpha release of the project.
This is a serious, legitimate concern. Cheaters take away from the enjoyment of other players. This concern already exists with proprietary source code, having the source wide open would make it easier for cheaters to see how to beat the system. This was a problem when the source for Quake was released as open source. Will this be the one area that makes open source difficult to use in the gaming industry?
One solution is to use a license, such as the BSD, that would allow for the non-distribution of sensitive client/server code.
Many companies feel that having the latest and greatest eye-candy gives them a competitive edge. Open source would take some of this away. Anyone using your code would have the same features. Even if they weren't using your code, they could see what is being implemented, describe it to another programmer and legally have the same features without deriving from the original work.
However, real competitive advantages do not come from having "cooler" graphics than the next game; it comes from having solid, creative game play. If the focus remains on game play and not on graphics, then someone getting your newest graphical feature becomes less of a concern.
Unfortunately, many developers are very dogmatic when it comes to open source software. So the flame wars about proprietary verses open source rage on. Then it becomes evil capitalist against dazed and confused socialist. All of this is counterproductive and takes away from making games.
It is best to remember that open source is a tool to make better software. Not everyone wants to use that tool. Some think that proprietary software is the way to go. Of course, everyone has the right to be wrong!
Seriously, determining if open source is right for a project has to be decided on an individual basis. Eric S. Raymond has said that open source is not for everyone. His writings are a good place to start in considering if open source is right for your project.
In the end, it's all about writing code and making games, and while healthy debates are good and very needed, open source shouldn't be treated like a religious experience.
In fact, most people are using open source software and don't even realize it. When you are looking at a website or checking your email, chances are the inner-workings (the mail transports and web servers) are open source.
So where do we begin? Lets start with a little history lesson behind open source.
Note:
This article was published on GameDev.net back in 2002. In 2008 it was revised by the original author and included in the book Business and Production: A GameDev.net Collection, which is one of 4 books collecting both popular GameDev.net articles and new original content in print format.
Sharing source goes back as early as the 1950's when the SHARE group was formed to exchange code for IBM mainframes. IBM released the source to the software for their mainframes, allowing changes for specific needs. This updated code was passed around the SHARE group, creating the earliest form of open source.
In 1985, The Free Sofware Foundation was formed by Richard Stallman, to to promote the freedom to distribute and modify computer software without restriction. Stallman had been working in the AI department at MIT and left in 1984 to began writing GNU free software. (GNU is pronounced "guh-NEW" and it stands for "GNU's Not Unix").
The Free Software Foundation (fsf.org) defines free software is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech," not as in "free beer." Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software.
In 1997, a paper written by Eric S. Raymond, The Cathedral and the Bazaar triggered a series of events that led to the forming of the Open Source Institute. One of the more significant events at the time was Netscape releasing the source to their browser. That project is still alive and well with various projects like the Firefox browser and the NVU (nvu.com) HTML editor. The OSI was jointly founded by Eric Raymond and Bruce Perens in late February 1998 , as a general educational and advocacy organization.
Next, it is necessary to understand what open source software is and what it is not. Open source in its purist sense is software that has the source code available to anyone who desires it. That individual is free to use the code as he sees fit, however any modifications to the code must be made available for everyone to use and modify, under the same conditions. According to opensource.org, "Open source promotes software reliability and quality by supporting independent peer review and rapid evolution of source code."
It's not source code that you download from a website with permission to redistribute and modify and also to add additional restrictions to it. It's not a free program like Artweaver (artweaver.de) that's made available to the public for free without the source code. It's not source code released into public domain where the rights to the code are forfeited. It is also not source code that's distributed freely with a clause saying it has to be non-profit. Open source creates a system of free access of information for the greater good of the project.
Types of Licenses
There are two categories of open source licenses, copyleft and permissive. A copyleft license is primarily concerned with preserving open software rights in forked versions of the project. It requires that any subsequent code be released and any finished products release the source code for the product. A permissive license places minimum restrictions on the source code. It can be modified without releasing the modifications. A permissive license can work hand-in-hand with closed, proprietary code.
Of the copyleft licenses, the most widely used is the GPL from the Free Software Foundation. It has a couple of variations, The LGPL and the AGPL. The LGPL (Lesser General Public License) makes a specific piece of code open source, but other parts of the project can be proprietary source code. The AGPL (Affero General Public License) focuses on software as a service and relaxes some restrictions on releasing the source to network clients. You can find out more about these licenses at gnu.org/licenses.
The BSD is a popular permissive license, in fact often a permissive license will be referred to as a “BSD type” license. There are a number of variations on each of these licenses. If you go to opensource.org/licenses, you can find a number of licenses approved by the OSI.
There is great debate about the various types of licenses and the impact of each. Some game developers shy away from a restrictive copyleft license. There are parts of games that sometimes need to be kept away from view. Sometimes to stop cheating, sometimes to create an edge in the market. Also, there is the perspective that a copyleft license doesn't provide true freedom. There is a great blog post on copyleft (GPL) licenses for games here on GameDev.net
Really, the choice in license is about what is best for your project. It may make more sense to have closed source or it may make sense to use open source and open your own source. There is a great overview of the legal aspects of open source licenses here.
Open Source Games
There are several open source games available. Some games have been released as open source, some have become open after a commercial release. On Wikipedia is a list of open source games, I'll highlight a few here.
Parallel Realities has a number of open source games including Blob Wars: Metal Blob Solid a 2-D arcade game. A cool thing that Parallel Realties does is release the making-of for several games.
Alien Trap has released a 3D shooter called Nexuiz, a game that is built on the Darkplaces engine, a fork of the Quake 1 engine. There is a Super Mario Cart clone called SuperTuxKart. The site has a good bit of information about the workings of the game and how to create additional levels.
Vega Strike is a 3D Action-Space-Sim. The website has a great deal of documentation and a developers blog. Warzone 2100 is a real-time strategy game that was released commercially in 1999, then released as open source in 2004. All of these games (and there are many others) provide a good starting point for developing your own game and for seeing various ways to organize an open source game project.
There is also an open source game that is a joint venture between Blender and Crystal Space teams. The name for the project is Apricot and is worth checking out. Speaking of Crystal Space, there are a few commercially released games that were made from the CS engine, including Ice Land.
How Open Source Helps the Gaming Industry
Funding
There are a few options for getting some funding for open source games. Right now Google has the Summer of Code that pays college students to develop open source software over the summer. There are a couple of other groups that provide funding to open source projects, one is Linux Fund and another is SPI. There is not a lot of funding money to go around, but every little bit helps. Another idea is to do like the Apricot project and pre-sell your final product. Some vendors may also donate hardware to an open source project.
Tools
There is a great number of tools available for about anything you need to do in creating a game. Using open source software can greatly reduce the cost of development. For example, you can use Eclipse for your IDE, Open Office for document writing, GIMP for editing raster graphics, Inkscape for vector editing, Blender for 3D modeling and Audacity for sound editing.
When using open source tools, at the very least, provide feedback. It will give you and the rest of the world a better product. If you have time to spare, write some code or documentation. It would still save money from buying the commercially available products.
Information Sharing
Many think that the single greatest element in the rapid advancement of the gaming industry is the wide-open exchange of knowledge. There are many websites with gaming information, source code for games being released to be examined and studied, magazines and books giving anyone the ability to understand game making techniques. Open source also encourages and promotes this same information sharing.
Back in 2004, I started using the Mojavi framework for web development. I was able to get quite an education on the Model View Controller pattern from Sean Kerr, the developer of the framework, just by hitting the forums, IMing and volunteering to help out when possible. In return I wrote documentation and tutorials for the project. We both benefited (and so did the community) and as a bonus, I had the opportunity to get to know a great person. Unfortunately, Sean was unable to maintain Mojavi, but the project forked and now lives on in Agavi.
Reduced Overhead
Using open source libraries is a great way to reduce time in a project, save money and have more developers working on making the best library possible. The many eyes on a project are one of the greatest strength of open source software.
There are a number of open source libraries available, doing a search for your need with the phrase “open source” opens a world of possibilities. A few libraries to consider are the Simple and Fast Multimedia Layer, a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick and networking. You could use the SQLite database in your game for data storage.
Do you need a game engine? You could use the Crystal Space engine (crystalspace3D.org). Is there a need to write a scripting language when you could use Python (python.org)? If you need an audio library then you could use OpenAL. Is it completely necessary to write a physics library when the Bullet library might work for you?
Development Speed
Imagine the ego trip for a hard core gamer to be able to say that he beta tested the newest RPG on the market. This alone will draw a number of contributors to an open source game project, especially if there is some credit in the finished game.
Having additional coders for fixing or improving code after an alpha or beta stage can be a great benefit to the project. Often times, as the project comes to a close, there is great pressure to hurry up and get the product finished. This is an area where open source can also be a benefit. The additional coders working on your project will be anxious to see the project finish and potentially increase their productivity.
I did an informal survey of developers on a couple of open source projects. I found, on average, the programmers that responded to the survey spent 87 hours a month writing code for various open source projects, the time spent ranged from 10 hours a month to about 350 hours a month. Look at it this way; if you had 4 outside developers (which is very realistic) spending an average of 87 hours a month on your project, you have picked up the equivalent of a full time programmer for the project without the added cost.
Additionally, just over half of those who responded say they make sure the code compiles and cleans up minor errors on a daily or bi-daily basis. Also, many developers spend time on documentations and product support.
Reduce Redundancy
A few years back, in writing a 3ds importer for the Crystal Space library, I felt like there could be a savings in time if I could find someone who had already done the dirty work of translating the 3ds information. I found lib3ds (lib3ds.sourceforge.net), which suited my needs, however I found that the I/O interface was specifically for disk access. Crystal Space uses a Virtual File System making it incompatible with lib3ds.
I sent an email to JE Hoffman, project leader of lib3ds and told him my dilemma. He gladly rewrote the interface to use any data format and it was integrated into Crystal Space. However, the story doesn't end here. Lib3ds was known to work only on Windows and Linux. Crystal Space covers many more platforms. I sent an email to the Crystal Space list asking for help for lib3ds to get it to work on other platforms. A Crystal Space developer, Eric Sunshine, responded and helped out on making lib3ds available for more platforms.
This was a win-win situation. Crystal Space got an importer; lib3ds was made available on more platforms. The programming community also benefits with having a more versatile library.
While this may not seem like the greatest example, how many trivial programming tasks consume parts of your day? Do you really need to write a compression library or will zlib work just as well for you?
Project Stability
Project stability could be the greatest case for using open source software. Open source software has been peer reviewed every step of the way. It has been tried in a number of environments and under a number of conditions. Just think of the number of machines with the wide variety of configurations that will be testing the product.
Mature open source code is as bulletproof as software ever gets. Why? It's always being looked over and compiled and tested. In my survey of open source developers, a number of developers spent a sizable percentage of their time making sure the code was in tip-top shape.
Broader Market
Why do game companies limit the number of platforms for which the product is available? Is it because they don't want that market share? Of course not. The reason is that that market share doesn't cover the costs of developing for that platform.
Would that platform be profitable if it could be added for next to nothing? Absolutely. This is another added benefit of open source; end users are often more than willing to do the necessary work to make a game work on their platform. Each added port is an added market for the game.
The additional exposure for the game generated by being an open source project can also help the project gain a greater market share. Anyone contributing code to the project would have an additional incentive to purchase the finished game.
Opportunity for Lone Gunmen
There have been many lamentations lately for the solo game developer. Oh, the good ol' days of the past when you could write a game yourself, put it in a zip-lock bag and sell it at a computer show. I don't believe the days of the solo developer have to be a distant memory of the past.
Granted, a single developer will never put together a project with the scope of Scorched 3D, but a Zuma type game could be developed by a single developer. There are a number of open source tools and libraries available for creating Flash games or Java based games that be delivered across a number of platforms.
Making money with Open Source
The first argument you will hear from businesses concerning open source is that you cannot make money with it. Au contraire. There are companies making money with open source and we'll look at a few and look at some ways that you can use open source to make money, making games.
The first thing I would recommend is heading over to pentaho.org/beekeeper to download and read the brilliant paper called The Beekeeper. It is a well thought out analogy on making money with open source and can provide great insight into how open source fits into a business model.
Creating Titles
If your focus is making games and not creating technology, open source is an excellent way to focus more of your resources on the game play and less on the technology involved. A line of titles could be made from open source code, keeping the content of the game protected and making money from that as normal, just the cost of development would go down. I believe this would also help to shift the focus of games from eye-candy to content.
Selling Libraries
Dual licensing is the best of both worlds. This can be a working model for companies who make money from selling libraries. You have an open version, licensed with a GPL like license, that helps with development and finding bugs. With the GPL any additional work by other developers would go back to the project. However, if a company wanted to use the library as a base to start from, but not give back any new development back to the community, then you charge the developer for the same software under a different license.
Selling Support
Much of the money made in selling libraries is actually in the form of selling support. This is included in the initial cost of the library, however many have an additional fee for each continuing year after the first year. The same could be done with open source software. The support could include initial training for the product, setting up systems for the product, implementing specific changes to the software and telephone support.
Selling support doesn't have to be limited to software you have developed. Many open source projects fall short in documentation and support. You could step in to offer that service for companies trying to decrease the learning curve.
Peripheral Makers
If you make the drivers for sound cards open source, you increase the potential of your hardware working on a greater number of platforms. With peripherals there is probably no revenue from the drivers so the cost of moving to open source is minimal.
Having the drivers readily available and modifiable encourages developers to add support for a product in the game. This increases the number of products and sub-sequentially the number of potential end users for their product.
In 2007 when AMD started opening up their graphics drivers, Novell released an alpha version of the ATI Radeon driver in just 8 days. It definitely makes more sense for developers who know an operating system to write a driver.
Writing
Who could better give a view of a project than one of its developers? There are many writing opportunities available. A book about using the software could be helpful to developers using the software. Magazine articles about the technology used in the software would help to give greater insight into the project and give back to the community.
While this isn't an option for everyone, there are those who could make money this way. A variation on this theme would be giving speeches about areas of the software.
Downsides
As with any good thing, there are a few downsides as well. This is also true of open source. However, most of the downsides can be dealt with if enough thought and effort is put into it.
Clusters
Often times group-designing ends up being more talk than action. Or if there weren't a unified direction, the project would end up going nowhere. Either of these could cause the project to go into a serious tailspin.
A cluster could be overcome by having a good design document. Another possible solution to this could be doing all of the engine design internally then opening the project up. It may even be a good idea to delay releasing the code until alpha release of the project.
Cheaters
This is a serious, legitimate concern. Cheaters take away from the enjoyment of other players. This concern already exists with proprietary source code, having the source wide open would make it easier for cheaters to see how to beat the system. This was a problem when the source for Quake was released as open source. Will this be the one area that makes open source difficult to use in the gaming industry?
One solution is to use a license, such as the BSD, that would allow for the non-distribution of sensitive client/server code.
The Competitive Edge
Many companies feel that having the latest and greatest eye-candy gives them a competitive edge. Open source would take some of this away. Anyone using your code would have the same features. Even if they weren't using your code, they could see what is being implemented, describe it to another programmer and legally have the same features without deriving from the original work.
However, real competitive advantages do not come from having "cooler" graphics than the next game; it comes from having solid, creative game play. If the focus remains on game play and not on graphics, then someone getting your newest graphical feature becomes less of a concern.
Conclusion
Unfortunately, many developers are very dogmatic when it comes to open source software. So the flame wars about proprietary verses open source rage on. Then it becomes evil capitalist against dazed and confused socialist. All of this is counterproductive and takes away from making games.
It is best to remember that open source is a tool to make better software. Not everyone wants to use that tool. Some think that proprietary software is the way to go. Of course, everyone has the right to be wrong!
Seriously, determining if open source is right for a project has to be decided on an individual basis. Eric S. Raymond has said that open source is not for everyone. His writings are a good place to start in considering if open source is right for your project.
In the end, it's all about writing code and making games, and while healthy debates are good and very needed, open source shouldn't be treated like a religious experience.