17.4 Bounties for Quicker Typer Uppers

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


Some developers are starting to explore a third way of blending capital with open source development by trying to let companies and people put bounties out on source code. The concept is pretty simple and tuned to the open software world. Let's say you have an annoying habit of placing French bon mots in the middle of sentences. Although this looks stupide to your friends, you think it's quite chic. The problem is that your old word processor's spell checker isn't quite la mode and it only operates avec une seule langue. The problem is that you've spent too much time studying fran ais and drinking de caf and not enough time studying Java, the programming language. You're tr s d sol by your word processor's inability to grok just how BCBG you can be and spell-check in deux languages.


The bounty system could be your savior. You would post a message saying, "Attention! I will reward with a check for $100 anyone who creates a two-language spell-checker." If you're lucky, someone who knows something about the spell-checker's source code will add the feature in a few minutes. One hundred dollars for a few minutes' work isn't too shabby.


It is entirely possible that another person out there is having the same problem getting their word processor to verstehen their needs. They might chip in $50 to the pool. If the problem is truly grande, then the pot could grow quite large.


This solution is blessed with the wide-open, free-market sensibility that many people in the open software community like. The bounties are posted in the open and anyone is free to try to claim the bounties by going to work. Ideally, the most knowledgeable will be the first to complete the job and nab the payoff.


Several developers are trying to create a firm infrastructure for the plan. Brian Behlendorf, one of the founding members of the Apache web server development team, is working with Tim O'Reilly's company to build a website known as SourceXchange. Another group known as CoSource is led by Bernie Thompson and his wife, Laurie. Both will work to create more software that is released with free source.


Of course, these projects are more than websites. They're really a process, and how the process will work is still unclear right now. While it is easy to circulate a notice that some guy will pay some money for some software, it is another thing to actually make it work. Writing software is a frustrating process and there are many chances for disagreement. The biggest question on every developer's mind is "How can I be sure I'll be paid?" and the biggest question on every sugar daddy's mind is "How can I be sure that the software works?"


These questions are part of any software development experience. There is often a large gap between the expectations of the person commissioning the software and the person writing the code. In this shadow are confusion, betrayal, and turmoil.


The normal solution is to break the project up into milestones and require payment after each milestone passes. If the coder is doing something unsatisfactory, the message is transmitted when payment doesn't arrive. Both SourceXchange and CoSource plan on carrying over the same structure to the world of bounty-hunting programmers. Each project might be broken into a number of different steps and a price for each step might be posted in advance.


Both systems try to alleviate the danger of nonpayment by requiring that someone step in and referee the end of the project. A peer reviewer must be able to look over the specs of the project and the final code and then determine whether money should be paid. Ideally, this person should be someone both sides respect.


A neutral party with the ability to make respectable decisions is something many programmers and consultants would welcome. In many normal situations, the contractors can only turn to the courts to solve disagreements, and the legal system is not really schooled in making these kinds of decisions. The company with the money is often able to dangle payment in front of the programmers and use this as a lever to extract more work. Many programmers have at least one horror story to tell about overly ambitious expectations.


Of course, the existence of a wise neutral party 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.