Free for All by Peter Wayner (great books to read .txt) 📖

hope that they'll pay you. This is an important point I learned consulting at Schwab and Morgan Stanley. They insist that they pay for the software they get. They don't want to pay nothing. I used to think that they were idiots. Now I think they're very smart," he says.

The matter is simple economics, he explains. "They believe that if enough money is going to their supplier, it won't be a total disaster. I call this an insurance model of software."

Companies that pay for the privacy with BitKeeper will also be funding further development. The work won't be done in someone's spare time between exams and the homecoming game. It won't be done between keeping the network running and helping the new secretary learn Microsoft Word. It will be developed by folks who get paid to do the work.

"There's enough money going back to the corporation so it can be supported," McVoy says. "This is the crux of the problem with the open source model. It's possible to abuse the proprietary model, too. They get you in there, they lock you in, and then they rape you. This business of hoping that it will be okay is unacceptable. You need to have a lock. The MIS directors insist you have a lock."

He has a point. Linux is a lot of fun to play with and it is now a very stable OS, but it took a fair number of years to get to this point. Many folks in the free source world like to say things like, "It used to be that the most fun in Linux was just getting it to work." Companies like Morgan Stanley, Schwab, American Airlines, and most others live and die on the quality of their computer systems. They're quite willing to pay money if it helps ensure that things don't go wrong.

McVoy's solution hasn't rubbed everyone the right way. The Open Source Initiative doesn't include his snitchware license in a list of acceptable solutions. "The consensus of the license police is that my license is NOT open source," he says. "The consensus of my lawyer is that it is. But I don't call it open source anymore."

He's going his own way. "I made my own determination of what people value in the OS community: they have to be able to get the source, modify the source, and redistribute the source for no fee. All of the other crap is yeah, yeah whatever," he says.

"The problem with the GPL is the GPL has an ax to grind, and in order to grind that ax it takes away all of the rights of the person who wrote the code. It serves the need of everyone in the community except the person who wrote it."

McVoy has also considered a number of other alternatives. Instead of taking away something that the free software folks don't value, he considered putting in something that the businesses would pay to get rid of. The product could show ads it downloaded from a central location. This solution is already well known on the Internet, where companies give away e-mail, searching solutions, directories, and tons of information in order to sell ads. This solution, however, tends to wreck the usability of the software. Eudora, the popular e-mail program, is distributed with this option.

McVoy also considered finding a way to charge for changes and support to BitKeeper. "The Cygnus model isn't working well because it turns them into a contracting shop. That means you actually have to do something for every hour of work."

To him, writing software and charging for each version can generate money without work--that is, without doing further work. The support house has to have someone answering the phone every moment. A company that is selling shrink-wrapped software can collect money as people buy new copies. McVoy doesn't want this cash to spend tipping bartenders on cruise ships, although he doesn't rule it out. He wants the capital to reinvest in other neat ideas. He wants to have some cash coming in so he can start up development teams looking at new and bigger projects.

The Cygnus model is too constraining for him. He argues that a company relying on support contracts must look for a customer to fund each project. Cygnus, for instance, had to convince Intel that they could do a good job porting the GCC to the i960. They found few people interested in general support of GNU, so they ended up concentrating on GCC.

McVoy argues that it's the engineers who come up with the dreams first. The customers are often more conservative and less able to see how some new tool or piece of software could be really useful. Someone needs to hole up in a garage for a bit to create a convincing demonstration of the idea. Funding a dream takes capital.

To him, the absence of money in the free software world can be a real limitation because money is a way to store value. It's not just about affording a new Range Rover and balsamic vinegars that cost more than cocaine by weight. Money can be a nice way to store up effort and transport it across time. Someone can work like a dog for a six months, turn out a great product, and sell it for a pile of cash. Ten years later, the cash can be spent on something else. The work is effectively stored for the future.

Of course, this vision isn't exactly true. Cygnus has managed to charge enough for their contracts to fund the development of extra tools. Adding new features and rolling them out into the general distribution of some GNU tool is part of the job that the Cygnus team took on for themselves. These new features also mean that the users need more support. On one level, it's not much different from a traditional software development cycle. Cygnus is doing its work by subscription while a traditional house is creating its new features on spec.

In fact, Cygnus did so well over such a long period of time that it found it could raise capital. "Once Cygnus had a track record of making money and delivering on time, investors wanted a piece of it," says Gilmore.

Red Hat has managed to sell enough CD-ROM disks to fund the development of new projects. They've created a good selection of installation tools that make it relatively easy for people to use Linux. They also help pay salaries for people like Alan Cox who contribute a great deal to the evolution of the kernel. They do all of this while others are free to copy their distribution disks verbatim.

McVoy doesn't argue with these facts, but feels that they're just a temporary occurrence. The huge growth of interest in Linux means that many new folks are exploring the operating system. There's a great demand for the hand-holding and packaging that Red Hat offers. In time, though, everyone will figure out how to use the product and the revenue stream should disappear as competition drives out the ability to charge $50 for each disk.

Of course, the folks at Cygnus or Red Hat might not disagree with McVoy either. They know it's a competitive world and they figure that their only choice is to remain competitive by finding something that people will want to pay for. They've done it in the past and they should probably be able to do it in the future. There are always new features.

17.4 BOUNTIES FOR QUICKER TYPER-UPPERS

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

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