State of the Pack II: Attack of the Forks

After posting my initial commentary on what I believe should be discussed, I got a few interesting comments from a variety of people.

First, kirindave suggested that I think about a code of conduct of sorts, that is what is good and bad to do by a modder - especially after various issues with hidden code in Greg’s and Reika’s mods, as well as the Pixelmon blacklist story. The problem is that honestly, I don’t care. I believe that modders should be able to do whatever they want as long as nobody gets harmed and that the actions of the community should decide what is right or not. We cannot enforce rules on hobbyists - we can only make suggestions or show our opinion in behaviour.

Second:

Nobody has the time or desire to fork and develop multiple branches so everything old becomes obsolete and un-touched at worst and at best all new work is done only on the latest.

To be honest, that’s exactly the problem. When Forge moves to a new version, the old versions are automatically abandoned, forcing modders to move to the new to enjoy new bugfixes and features; in addition, nobody will agree to fork Forge for 1.6.4 because it’s not official. I will get to the subject of forks in a moment, though, so let’s leave it here for now.

Third, the accusations about me being obsessive about permissions. To be honest, I don't care a lot about permissions. I just follow a simple rule: if someone goes out of their way to forbid me from using their mod, they're likely a person I wouldn't want to work with anyway… and if they don't, I use it and cooperate.

I got a lot more comments on the post, but most of them were properly answered on Reddit and don’t really need further explanation. Now, time for the actual topic of the post:

The Attack of the Forks.

What IS a fork? A fork, in software engineering, is taking a copy of the source code and starting independent development on it. It doesn’t always cause a re-merging, though. Sometimes, it becomes a sort of schism.

There are four possible outcomes of a fork:

1. The death of the fork. It’s the most common case, because few people have the energy to continue independently developing one and merging patches back from the original.
2. A re-merging of the fork. That’s what happens with pull requests - you create a fork, you add a few features or fix a few bugs, and you request that your fork be merged back into the master repository.
3. The death of the original version. All developers move on to the fork, as it is superior in certain ways.
4. Successful branching and differentiation, where each fork lives on to have its own features.

Now, there is serious stigma about forking projects. It is widely believed as detrimental to the goals of the community as a whole and generally harmful. A discussion on IRC revealed that many people believe forking should only be done if the original author disappears. They complained that it’s an asshole way to do things and that mods should rather be rewritten with a different design goal in mind and NOT forked. I don’t believe that to be true, especially as many forks have happened in the Minecraft community over the years and few people really cared. No drama was created and everything went on smoothly. Here are a few examples:

• Chisel. Chisel’s author, AUTOMATIC_MAIDEN, has disappeared from the face of the planet. This means that someone has to go and fork it if we are to get any updates. As of right now, there are three distinct forks of Chisel:
  • Technic’s fork, which few people even noticed. It only fixes bugs with Chisel and Technic’s packs, though, so it is not really a big deal,
  • my fork, which is focused on fixing bugs that are found. I originally ported it to 1.7.2, then backported some of the changes to 1.6.4 on request by TPPI,
  • delta534’s fork, which is a more bleeding-edge release and introduces a lot of new features (proper FMP support, automatic chiseling, etc.).

This is an example of the fourth route - the forks successfully fill each other’s niche. Will they merge back into one? Nobody really knows yet.

Now, you might ask, why didn’t everyone just move to delta’s fork? It seems like the best fork and develops the fastest. There is a problem, though. Some people disagree with being bleeding-edge, as it inevitably causes a lot of bugs that need to be ironed out over time. The other forks created a stable alternative for it, and that’s what TPPI moved to.

That is the purpose forks serve! If a certain group of people has different goals from the other group, they can just fork off! Let’s look at another example.

• Project: Red. What few people know is that Project: Red was originally a fork of RedLogic - in the 3.x.x branch for Minecraft 1.5.2. Later on, ChickenBones came in and did an (almost) complete rewrite of the codebase to faciliate compatibility with Forge MultiPart. The fact still stands, though - it was originally a fork of a project whose author did not abandon the project. Did it harm anyone? No! Almost everyone moved to the fork because it was superior - it had support for Forge MultiPart.
• MineFactory Reloaded had two forks for 1.6.x: one by samrg472 and one by skyboy. Eventually, after a while of both developing each other’s forks, a decision was made for sam to maintain PowerConverters and for skyboy to maintain MineFactory Reloaded and Nether Ores.

There is another way that the social stigma of forking harms mod development in. It revolves around reinventing the wheel. In essence, if we fork a mod, we can spend time actually adding new features and not rewriting existing ones. That means the community progresses faster. In addition, by letting developers choose different goals, forks encourage innovation.

There are some groups who encourage forks, like BuildCraft developers - I have asked SpaceToad and he said he is perfectly fine with forking off his mod if I have different goals, and I’m glad of that. In general, though, I believe that the ability to create your own version of something if you have different goals is the main reason for the existence of free, open source software in general. Not everyone has to agree, and forks are a great way to let people express their own opinion on a mod’s direction.

To mod developers, you have to face it: open source is a double-edged sword. It gives you the freedom of giving the development to the community, but it gives the community the freedom of taking the development from you. Don’t be scared, though, as open source gives you one additional right:

If someone else makes something inspired by your work, and adds a cool feature, you can just take the changes BACK into your own code. (In some open source licenses - like the LGPL and GPL. Some people opt to go further and give other people the right to change the license, like with the MIT license. I might write a short post on what each licensing method means for the players later on)

That means that, unlike a full rewrite, you have full rights to integrate the fork back. Everyone benefits! Less time is wasted, more features are introduced and players get to play on the best version of the mod ever.

PS. Greetings to 4chan’s Minecraft General! Admittedly, I find the fight between my „supporters” and my „haters” quite funny. For those of you who are wondering, the reason I like Nichijou so much is because of its completely absurd humor, and I actually like absurd humor and complete randomness. Entertainment will forever remain a subjective experience and I hope my taste won’t get in the way of my mod development.