Responsible for some vaults, a few ideas and no code.
Principles to believe in:
gameplay > interface > realism or flavour
console and tiles are equally important
long streaks are an indication the game might be too easy
open development is crucual, but design is not a democratic process
most options should go
These are some idle thoughts by a non-coding Crawl developer about open source (OS) and open development (OD) in the context of roguelikes. First, what is what, as there don't seem to be strict definitions around.
OS: The game's source is available.
OD: The developer(s) of the game react to input from players.
Obviously, OS is a binary concept, whereas OD comes in shades.
Here is my personal take on some well-known roguelikes:
It is obvious that OS has some immediate good consequences:
code-literate players will comment on bugs and sometimes send patches
in general, you will get more feedback about the code
you can ask interested players to code cool features (perhaps even ideas they proposed and fit the design vision)
if you abandon the game (something that can happen out of the blue), the game can move on, bugs can be fixed etc. (ADOM suffered from having the last version contain new, serious bugs.)
OS has one obvious disadvantage:
cannot make money off it (at least, not as easily as if the source is closed)
Dwarf Fortress is a good example: the two developers do make a living of it (from donations of players), so it seems very reasonable to have the game closed. On the other hand, development is very open, which presumably also leads to a tighter bond between players and their game, hence to more donations.)
And there is one implication of subjective value:
OS allows forking. This can be seen as good or bad. However, it is clearly good that a project can live on in a fork if the original developer(s) abandon it. Therefore, one would suggest that developers open the source before retiring — but this can be hard to achieve, as most projects probably fade into grey, rather than being abruptly abandoned.
Some feedback from Crawl's development:
Over time, very many ideas have been suggested on the trackers, some of them exceptionally good, many of them quite good. It turned out that there's no way the devteam could code all the outstanding ideas, let alone the ones which are only nifty. So we resorted to explicitly flagging some proposals as “patches wanted”. It was highly surprising how quickly content rolled in.
A slime god was discussed for some years already. When we made clear that the god would be used (by marking it with “patch welcome”), we got code within a single week. Testing and polishing took some time, but 0.6 saw the addition of Jiyva, the slime god.
Several developers are able to draw tiles for Crawl, but it seemed that tiles production would inevitably lag behind… given the onslaught of new monsters, portal vaults etc. After publicly announcing which tiles are missing, and how to make tiles, it took less than three months to catch up. This was only possible with a community effort.
We have learned a lot from these experiences. First, we've become much more generous with handing out commit rights (especially after we moved to git, so that branching became very easy). Second, we rely a lot more on outside code. Among others, the slow god, the starting screens and the better half of the Demonspawn revamping was made like this.
Given all these advantages, what are the reasons for some developers to forfeit open development/source? Here are some attempts to examine that:
Afraid of losing control of the project.
In principle, it could happen that upon releasing an open source project, someone else will make it his own, and fork it into something more popular, effectively “stealing” it from the originator.
Megalomania.
The belief that the developer knows best what's good for the game. This is hubris, because players inevitably will come up with awesome ideas. True, many ideas will be lackluster, absurd, incoherent etc. But rejecting the wealth of outside ideas completely just so one does not have to sort the wheat from the caff will lead to an inferior game.
Aiming for wealth and glory.
If one keeps the development to oneself, there might be a possibility to make money from it, at some point in the future. Also, by not sharing ideas and code with anybody else, you get all the praise yourself. However, it is highly unlikely to make money from a roguelike (it does work for Dwarf Fortress, which is not quite a roguelike; there are attempts like 100Rogues for the iPhone).
That said, I would summarise the matter as follows:
There can be good reasons to keep the source closed. However, there do not seem to be good reasons to keep development closed. Always listen to your players.
Going open source demands some responsibility from the developer(s): there may be patches that are good in intent and code, but you still have to reject them because they won't fit the longterm vision. For this, it's necessary to have a vision, of course. Ideally, communication can prevent such incidents. Generally, you will lose patchers (and often players) after rejecting patches.
Open development demands even more effort: you will now also have to cut down on proposals. The better you do that, the higher the quality of future proposals.
For example, in Crawl we have rejected some tiles, levels/vaults, patches and reasonable ideas over the years.
If you're starting out with a small roguelike game, it seems best to follow a policy like this (the following assumes you only care about the quality of the game):
Be open source from the start.
Have a bug tracker right away – it is much better to have players see a list of bugs (and they they're fixed!) on a web page than doing this by mail (hence secret). You will get more feedback this way.
Once your game has stabilised and is strong enough in flavour and whatever makes it special, consider asking players for feature requests. They will undoubtedly come up with some good ideas. You can ask for patches, if you like to split up the work.