Hmm. Can't say I agree. There are right times to fork, but in most cases, it's not the best thing. Read on for explanation.
Jastiv {l Wrote}:Proprietary game companies frequently come out with a game, and make more and more sequels of this great game. Gamers like this because they know if they liked the first one, the next one will be similar so they will be more likely to buy then next one. Thus you have popular series such as Ultima, Final Fantasy, Heroes of Might and Magic, Super Mario etc.
The thing is, most sequels are created either because they are continuing a story or because of the market dynamics of the gaming market. Games make almost all of their sales in the first 3 months of their release. You could introduce a new IP but it's a bigger risk to extending a pre-existing game with DLC (if the game is successful and popular, though you
will be restricted to the pool of people who already have your game) or just make a sequel, which is much less of a risk, both in development methodology (you have a clear idea of where you want to go with it) and in sales (if the game is good, people want more!).
This is not to say that open source games should not receive sequels or spin-offs, but there just aren't many story-based open source games out there which are the ones where a fork can be justified. But more so, I think we really need to see the first open source spinoff. What about an action-adventure Battle for Wesnoth, or a 3D Hedgewars? Marketing should not be a bad word in open source and by building on an existing brand, you are bound to be more successful.
Jastiv {l Wrote}:Free software projects on the hand, are afraid of the Fork! If there is game one in the successful free software games, one of two things will happen. The original team will keep trying to improve it, not just maintain it so it continues to run on newer computers (like when libraries get out of date) So eventually with all the new features it will play like a different game. (example, crossfire, battle for wesnoth) Or even if it doesn't play different, it will look significantly different and have features and game balance changes the original did not have.
This is my biggest problem with this post. What you're really talking about here is a
bad development method. You
must have a clear idea of where you are going with the game and have an absolute 'finished' state. Your project can't go on forever. Granted, Wesnoth has become the Emacs of TBS games being basically implemented in its own scripting language (and a little Lua), but the fact is, they made a universe, built a TBS game with
well-defined and thought-out gameplay and they
didn't stray from the original concept. I would argue that BfW is a bad example for this.
If the bus factor dropped to 0 tomorrow, someone could still theoretically pick it up and make it the way it was originally intended. The author is the master of their work and they know best how it's going to be implemented. If they put the word out from the start that they want their game to ultimately play
this and not
that way, it's probably the best way, to be honest. But they have to have a clear design from the start. Examples in open source software of this are Inkscape and Tomahawk Player. Examples in open source games are Battle for Wesnoth, Lips of Suna and perhaps above all, 0 A.D.
Jastiv {l Wrote}:On the other hand, they often just abandon it, so it get forks, multiple forks, many of these forks don't even work on the platform the game originally worked on, and then there is the question of what is the real fork if people didn't change the project name. (IVAN, also known as iter vehehims. ad neccam)
Abandonment is a different thing. The problem with roguelikes is that there has always been a strong open source community around them, which doesn't really 'get' the open source
development model (beyond just the licensing). They will usually work on things their own, that is. In case of abandonment, a fork is appropriate, as in the case of Glest. It wasn't the cleanest of forking processes as development split in two, GAE and MegaGlest. But both formed communities from the pre-existing Glest community, which is a success in my mind. Unvanquished is another example of a successful fork. TremZ was killed off and just about all developers moved over to Unvanquished.
---
Cases where a fork usually
is appropriate are almost always down to poor project management in my opinion. That not only includes not setting a vision for your software or game project, but also interacting with other developers (code or not) and the community
the right way.
Another case is when you want to make a
separate game or simply continue a dead project. However, if you do want to fork a stagnant codebase, at least talk to the last maintainer. If you get far enough (remember, at least work on it first), ask them if they'll sell the domain name to you. If you are a maintainer or a dying project, please do the right thing and leave the option open for anyone to contact you if they wish to continue the project.
Aside from that, I believe it's always better to improve another project until you are influential enough to push your changes through. But for heaven's sake, please run it through with the players first and don't make top-down decisions about everything.
To Julius: can you please allow the horizontal rule (<hr /> in HTML) on the forum? I swear I've seen another phpBB forum support it. I will love you forever.
You just wasted 3 seconds of your life reading this.