This article has since been revised and updated

Open Source and the Gaming Industry by [email="rds@rhinogames.com"]Richard D Shank[/email] 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 starting to take notice 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 inter-workings (the mail transports and web servers) are open source. So where so we begin? Lets start with a little history lesson behind open source. The earliest occurrence of open source was in 1977 when the first Berkeley Software Distribution version of Unix (BSD Unix) is released. Then in 1984 the movement of freely shared source code began. Actually, it had started years earlier when Richard Stallman was working in the AI department at MIT. He was part of a software-sharing community and developed the philosophy than sharing software "it is as old as computers, just as sharing of recipes is as old as cooking." In 1984 Stallman left MIT and began writing GNU free software. (GNU is pronounced "guh-NEW" and it stands for "GNU's Not Unix") The Free Software Foundation www.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. 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 www.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 utility like NSIS that's made available to the public for free without the source code. It's not 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. It's similar to all of that but much, much more. Types of Licenses There are primarily two types of free software licensing. One allows portions of code outside the open source to be made available, but any changes to the open source code must be made available. The other requires all code in a project to be available include the portions not related to the initial source code. The GPL (General Public License) license states that all source must be made freely available. There is a variant on the GPL; the LGPL (Lesser General Public License) that makes the specific piece of code open source, but other parts of the project can be proprietary source code. Both of these licenses are established by the Free Software Foundation. There are a number of variations on each of these licenses. If you go to www.opensource.org you can find a number of open source licenses. How Open Source Helps the Gaming Industry 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. Reduced Overhead You could lower the cost of the development of a project by using a pre-existing open source game library. Do you need a game engine? You could use the Crystal Space engine (www.crystalspace.org). Is there a need to write a scripting language when you could get Python (www.python.org)? If you need an audio library then you could use OpenAL (www.openal.org). Is it completely necessary to write a model editor when OpenFX (www.openfx.org) might work for you? Development Speed Imagine the ego trip for a hard core gamer to be able to say that he contributed code to the newest RPG on the market. This alone will draw a number of programmers to an open source game project, especially if the programmers get 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 project. Here's what I found. On average, the programmers that responded to the survey spent 87 hours a month writing code for various open source project, 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 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 (http://sourceforge.net/projects/lib3ds), 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 (http://www.gzip.org/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 generate 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 Gunman 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 computer show. I don't believe days of the solo developer have to be a distant memory of the past. Granted, it will take more work, more planning and a lot more ingenuity however, if someone can think outside of the box, it can be done. Open source software can go a long way toward making that happen. 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. 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 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 Libraries Dual licensing is the best of both worlds. This can be a working model for companies who make money from selling libraries. There are a couple of ways this could work. First you could all, you could charge for the licensing for the binary distribution if the developer chose not to have the entire source of their game freely distributed under a GPL license. Secondly, you could do like Garage Games (www.garagegames.com) with their Torque engine and maintain distribution rights to a finished game. However, to make either of these methods work, the code and the license must be controlled from the ground up. Sleepycat Software (www.sleepycat.com) is a great example of making money using a dual license. Sleepycat makes an embedded database system called Berkeley DB. Berkeley DB is a programmatic toolkit that provides fast, reliable, scalable and mission-critical database support to software developers. Sleepycat uses the GPL license with an added binary distribution clause. Basically, the clause says you make use the software freely as long as you make the source code freely available and redistributable by others. If you chose not to make it open source, then you can pay a licensing fee to SleepyCat. Redistribution is the key to making money this way. According to Sleepycat, the secret to making a dual licensing work is to own the licensing rights to all of the code. If a programmer wants to submit changes to the Berkeley DB toolkit, then the changes are given to an engineer board for review. If the code passes review, then the programmer is asked to give the licensing rights to Sleepycat. The code is then added to Berkeley and Sleepycat maintains total control over the licensing of the product. In addition to making money from the binary distribution, they also make about 25% of their revenue on support. On October 15, 1999 in a Slashdot (www.slashdot.org) interview, John Carmack said, "We make a fairly good chunk of income from technology licensing, so it would take some damn good arguments to convince everyone that giving it all away would be a good idea." Here is your damn good argument. Of course, these are easy arguments for me to make, I'm not the one to stand to loose a large chunk of my income by taking this risk. From what I have read, the majority of the companies that license technology from id or Epic, end up making modifications to the engine because they want that added edge in their game. I don't think this would change if the core of the technology were freely available. Companies would still want to keep the advances to the engine in their project only. A big upside for opening the source is the end user adding value to the engine. This has happened in the past for id. According to a Wired magazine article, when id released three levels of Quake on the Internet to be checked for bugs in the networking code, not only were the bugs found, but hackers also provided patches to fix the code. This even went as far as hackers finding non-functional features and activating them. Mike Wilson (then with id) was quoted, "The joke around here now is we can let the rest of the world finish Quake for us." This wouldn't be a joke with open source. Peripheral Makers If you make the drivers for soundcards or force-feedback joysticks 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. Nvidia does this type of thing, making source code specific to their product freely available, in order to create a greater demand for their product. Writing Who could better give a view of a project that 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 also. 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. Legal Issues There are a number of legal issues that could be involved in using open source software. Unfortunately, open source hasn't been tested in court yet. The bright side of this is the reason is probably because the outcome is known before litigation even starts. Open source is quite solid from a legal aspect. This brings up one of the problems with the GPL licensing. It may be too solid for games. Games differ from other types of software in that there is more involved than just the code and a few icons. There is a whole realm of graphics art, music and design that is involved. Dan Ravicher, a leading attorney in open source law and a member of Brobeck, Phleger & Harrison's Technology Group in New York, said in response to a recent Slashdot interview that the terms of the GPL may apply to sound and image files if they are part of a whole work that is based on a GPL licensed program. Section 2 of the GPL license states "If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." Therefore, under the GPL, if the non-source code files are "distributed as part of a whole which is a work based on the [GPL'd] program," then the whole application, including those non-source code files, must be distributed under the GPL. However, if the non-source code files are not "based on the [GPL'd] Program" and are "merely aggregated" with the GPL'd program for distribution, then those non-source code files do not have to be distributed under the GPL. This means that the issue lies in how the non-source code files are incorporated into or with the GPL'd program. According to Ravicher, there are also two other issues that you might want to think about. First, no court has yet ruled on the validity of the GPL. Therefore, the above section may be held unenforceable. Second, if you are the complete owner of all the copyrights in either the non-source code files or the program, you have the ability to license those copyrights under both the GPL and other licenses, if you so choose. Say for instance, a GPL'd game comes your way and you wish to add graphic X. You create graphic X in a way which creates in you all its copyrights. If you then incorporate graphic X into the game, the enhanced game must be distributed under the GPL. However, you can also distribute your graphic X under other licenses, including closed source. If you are working for a company and you wish to contribute code that you have written on their time to an open source project, you should have permission from the company before submitting the code. It would be best if you had written permission, in fact a number of open source projects require it. Ravicher says, "Requiring contributors to confirm that they have permission to release the code to your project helps to reduce your exposure to third party intellectual property infringement claims. In addition to having the agreement for legal reasons, it could also be helpful to also post a detailed FAQ about why such an agreement is needed and who a contributor can contact if they (or their employer) have issues or questions." If you are developing the code from the ground up, maintaining licensing control over the code, you can add a clause allowing artwork to be proprietary. If you are looking at using an outside open source project and they are using a GPL license, it would be best to see if an exception could be added to allow closed source on artwork before starting using that project. Cheaters This is a serious, legitimate concern. Cheaters take away from the enjoyment of other players. This concern 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 GPL license with a cheaters clause in it. This clause could allow for the non-distribution of sensitive client/server code. The Competitive Edge Many companies feel that have 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 to 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. Open Source as a Religion Unfortunately, many developers are very dogmatic when it comes to open source software. So the flame wars about proprietary verse 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, remember 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. Conclusion Open source software can add a lot to your project development. It should be looked at it as a serious option. It should be pursued and investigated just as you would any other tool available to you in developing you game. I would like to thank Dan Ravicher, Sleepycat and everyone who responded to my survey for their help in writing this article. You can find links to open source related sites at www.rhinogames.com/opensource.html.