Free for All by Peter Wayner (good books to read for young adults .TXT) 📕

who can see deeply into the problems and provide a fair solution is close to a myth. Judging takes time. SourceXchange promises that these peer reviewers will be paid, and this money will probably have to come from the people offering the bounty. They're the only ones putting money into the system in the long run. Plus, the system must make the people offering bounties happy in the long run or it will fail.

The CoSource project suggests that the developers must come up with their own authority who will judge the end of the job and present this person with their bid. The sponsors then decide whether to trust the peer reviewer when they okay the job. The authorities will be judged like the developers, and summaries of their reputation will be posted on the site. While it isn't clear how the reviewers will be paid, it is not too much to expect that there will be some people out there who will do it just for the pleasure of having their finger in the stew. They might, for instance, want to offer the bounty themselves but be unable to put up much money. Acting as a reviewer would give them the chance to make sure the software did what they wanted without putting up much cash.

One of the most difficult questions is how to run the marketplace. A wide-open solution would let the sponsors pay when the job was done satisfactorily. The first person to the door with running code that met the specs would be the one to be paid. Any other team that showed up later would get nothing.

This approach would offer the greatest guarantees of creating well-running code as quickly as possible. The programmers would have a strong incentive to meet the specs quickly in order to win the cash. The downside is that the price would be driven up because the programmers would be taking on more risk. They would need to capitalize their own development and take the chance that someone might beat them to the door. Anxious sponsors who need some code quickly should be willing to pay the price.

Another solution is to award contracts before any work is done. Developers would essentially bid on the project and the sponsor would choose one to start work. The process would be fairly formal and favor the seasoned, connected programmers. A couple of kids working in their spare time might be able to win an open bounty, but they would be at a great disadvantage in this system. Both CoSource and SourceXchange say that they'll favor this sort of preliminary negotiation.

If the contracts are awarded before work begins, the bounty system looks less like a wild free-for-all and more like just a neutral marketplace for contract programmers to make their deals. Companies like Cygnus already bid to be paid for jobs that produce open source. These market-places for bounties will need to provide some structure and efficiencies to make it worth people's time to use them.

One possible benefit of the bounty system is to aggregate the desires of many small groups. While some bounties will only serve the person who asks for them, many have the potential to help people who are willing to pay. An efficient system should be able to join these people together into one group and put their money into one pot.

CoSource says that it will try to put together the bounties of many small groups and allow people to pay them with credit cards. It uses the example of a group of Linux developers who would gather together to fund the creation of an open source version of their favorite game. They would each chip in $10, $20, or $50 and when the pot got big enough, someone would step forward. Creating a cohesive political group that could effectively offer a large bounty is a great job for these sites.

Of course, there are deeper questions about the flow of capital and the nature of risks in these bounty-based approaches. In traditional software development, one group pays for the creation of the software in the hope that they'll be able to sell it for more than it cost to create. Here, the programmer would be guaranteed a fixed payment if he accomplished the job. The developer's risk is not completely eliminated because the job might take longer than they expected, but there is little of the traditional risk of a start-up firm. It may not be a good idea to separate the risk-taking from the people doing the work. That is often the best way to keep people focused and devoted.

Each of these three systems shows how hard the free software industry is working at finding a way for people to pay their bills and share information successfully. Companies like Cygnus or BitKeeper are real efforts built by serious people who can't live off the largesse of a university or a steady stream of government grants. Their success shows that it is quite possible to make money and give the source code away for free, but it isn't easy.

Still, there is no way to know how well these companies will survive the brutal competition that comes from the free flow of the source code. There are no barriers to entry, so each corporation must be constantly on its toes. The business becomes one of service, not manufacturing, and that changes everything. There are no grand slam home runs in that world. There are no billion-dollar explosions. Service businesses grow by careful attention to detail and plenty of focused effort.

FORK

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.

18.1 FORKS AND THE THREAT OF DISUNITY

.....................................

Eric Raymond once got in a big fight with Richard Stallman about the structure of Emacs Lisp. Raymond said, "The Lisp libraries were in bad shape in a number of ways. They were poorly documented. There was a lot of work that had gone on outside the FSF that should be integrated and I wanted to merge in the best work from outside."

The problem is that Stallman didn't want any part of Raymond's work. "He just said, 'I won't take those changes into the distribution.' That's his privilege to do," Raymond said.

That put Raymond in an awkward position. He could continue to do the work, create his own distribution of Emacs, and publicly break with Stallman. If he were right and the Lisp code really needed work, then he would probably find more than a few folks who would cheer his work. They might start following him by downloading his distribution and sending their bug fixes his way. Of course, if he were wrong, he would set up his own web server, do all the work, put his Lisp fixes out there,