Open Source

A question that arises for any roguelike developer is: "Should I release my game?" This leads to another, corresponding, question of "Should I release my source code?"

This page is a foolish attempt to present the pros and cons of releasing source code.

Open Source Definition

First, consider the various choices for open source. These are covered in brief under Licensing.

1. Source code available, but remains copywritten. While people have access to the source code (so they can do ports, preserve the work, etc), they do not have permission to produce derivative works (make variants, sell for profit, etc). While this may seem to be a safe middle of the road choice, in practice you should not expect your wishes to be followed. If your game is popular enough to spawn variants, people will write them despite your wishes. It is thus suggested you save yourself the heartache and either resign yourself to "Hack With Space Orcs" being written or keep it closed source.
2. Source code available, can make derivatives, but must release new source. This is the GPL "viral" interpretation of open source. When applied to a finished game, this restricts third parties ability to repackage and resell your game. Any repackaging they do must be made available for you to reintegrate into the main baseline, preserving your ability to have the definitive version.
3. Source code available, can make derivatives, little other restrictions. This is the BSD interpretation of open source. Note it allows a third party to release a closed source version of your game, hiding from you and others any changes they performed. This is a useful option if you produce an engine where you see the majority of the work being done by the secondary developer. It then lets the person who does the most work decide on licensing.

Having listed those choices, we will make no further reference to them. We will instead discuss pros and cons for releasing source code at all, regardless of the method.