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.