Difference between revisions of "Open Source"

From RogueBasin
Jump to navigation Jump to search
(This mark up language sucks)
Line 14: Line 14:


== Pros ==
== Pros ==
Let's look at all the good reasons to provide your source code...
# [[Portability]].  You do not need to own all the platforms that you want to port to.  People on those platforms can do their own ports and give you the needed changes.
# Preservation.  By releasing the source code, you insulate yourself against catastrophic data failure.  The GLQuake movement famously moved to GPL licenses after one of the key programs was lost in a hard drive crash.  To maximize this effect, it is recommended you include the source code in the standard download so as to ensure all players end up with a copy by default.
# Survivability.  If your roguelike only exists as a .exe, it will become harder and harder for future computers to run it.  Source code helps ensure native versions are available.
# Bug Fixes.  Ideally, when users encounter crashing bugs, they can give you the bug fix rather than just reporting the problem.
# New Features.  Eager users may develop patches that add cool new features that  you can then add to your game.
# Variants.  People may branch off producing entire new roguelikes with your system used as an engine, enriching the roguelike scene.
# Can use GPL code.  If you are releasing under GPL, you can use GPL code in your program.  This isn't so much a "Pro" as an forced prerequisite of using the code, however.


== Cons ==
== Cons ==

Revision as of 16:49, 23 May 2006

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.

Pros

Let's look at all the good reasons to provide your source code...

  1. Portability. You do not need to own all the platforms that you want to port to. People on those platforms can do their own ports and give you the needed changes.
  2. Preservation. By releasing the source code, you insulate yourself against catastrophic data failure. The GLQuake movement famously moved to GPL licenses after one of the key programs was lost in a hard drive crash. To maximize this effect, it is recommended you include the source code in the standard download so as to ensure all players end up with a copy by default.
  3. Survivability. If your roguelike only exists as a .exe, it will become harder and harder for future computers to run it. Source code helps ensure native versions are available.
  4. Bug Fixes. Ideally, when users encounter crashing bugs, they can give you the bug fix rather than just reporting the problem.
  5. New Features. Eager users may develop patches that add cool new features that you can then add to your game.
  6. Variants. People may branch off producing entire new roguelikes with your system used as an engine, enriching the roguelike scene.
  7. Can use GPL code. If you are releasing under GPL, you can use GPL code in your program. This isn't so much a "Pro" as an forced prerequisite of using the code, however.

Cons