18. Fork

Free For All. Go to the Table of Contents. Vist the Gifcom.

A T-shirt once offered this wisdom to the world: "If you love someone, set them free. If they come back to you, it was meant to be. If they don't come back, hunt them down and kill them." The world of free software revolves around letting your source code go off into the world. If things go well, others will love the source code, shower it with bug fixes, and send all of this hard work flowing back to you. It will be a shining example of harmony and another reason why the free software world is great. But if things don't work out, someone might fork you and there's nothing you can do about it.

"Fork" is a UNIX command that allows you to split a job in half. UNIX is an operating system that allows several people to use the same computer to do different tasks, and the operating system pretends to run them simultaneously by quickly jumping from task to task. A typical UNIX computer has at least 100 different tasks running. Some watch the network for incoming data, some run programs for the user, some watch over the file system, and others do many menial tasks.

If you "fork a job," you arrange to split it into two parts that the computer treats as two separate jobs. This can be quite useful if both jobs are often interrupted, because one can continue while the other one stalls. This solution is great if two tasks, A and B, need to be accomplished independently of each other. If you use one task and try to accomplish A first, then B won't start until A finishes. This can be quite inefficient if A stalls. A better solution is to fork the job and treat A and B as two separate tasks.

Most programmers don't spend much time talking about these kinds of forks. They're mainly concerned about forks in the political process.

Programmers use "fork" to describe a similar process in the organization of a project, but the meaning is quite different. Forks of a team mean that the group splits and goes in different directions. One part might concentrate on adding support for buzzword Alpha while the other might aim for full buzzword Beta compatibility.

In some cases, there are deep divisions behind the decision to fork. One group thinks buzzword Alpha is a sloppy, brain-dead kludge job that's going to blow up in a few years. The other group hates buzzword Beta with a passion. Disputes like this happen all the time. They often get resolved peacefully when someone comes up with buzzword Gamma, which eclipses them both. When no Gamma arrives, people start talking about going their separate ways and forking the source. If the dust settles, two different versions start appearing on the Net competing with each other for the hearts and CPUs of the folks out there. Sometimes the differences between the versions are great and sometimes they're small. But there's now a fork in the evolution of the source code, and people have to start making choices.

The free software community has a strange attitude toward forks. On one hand, forking is the whole reason Stallman wrote the free software manifesto. He wanted the right and the ability to mess around with the software on his computer. He wanted to be free to change it, modify it, and tear it to shreds if he felt like doing it one afternoon. No one should be able to stop him from doing that. He wanted to be totally free.

On the other hand, forking can hurt the community by duplicating efforts, splitting alliances, and sowing confusion in the minds of users. If Bob starts writing and publishing his own version of Linux out of his house, then he's taking some energy away from the main version. People start wondering if the version they're running is the Missouri Synod version of Emacs or the Christian Baptist version. Where do they send bug fixes? Who's in charge? Distribution groups like Debian or Red Hat have to spend a few moments trying to decide whether they want to include one version or the other. If they include both, they have to choose one as the default. Sometimes they just throw up their hands and forget about both. It's a civil war, and those are always worse than a plain old war.

Some forks evolve out of personalities that just rub each other the wrong way. I've heard time and time again, "Oh, we had to kick him out of the group because he was offending people." Many members of the community consider this kind of forking bad. They use the same tone of voice to describe a fork of the source code as they use to describe the breakup of two lovers. It is sad, unfortunate, unpleasant, and something we'll never really understand because we weren't there. Sometimes people take sides because they have a strong opinion about who is right. They'll usually go off and start contributing to that code fork. In other cases, people don't know which to pick and they just close their eyes and join the one with the cutest logo.