There's a new way of doing software contracting appearing on the horizon, and for lack of a better word, I'm going to call it "bounty hunter open source" or simply "the bounty model". If you've seen recent offerings for free documentation from the FSF, the volunteer-based Free Software Bazaar, or the recently opened CoSource and SourceXChange corporate ventures, you know what I'm talking about. The idea is that people who want software post "bounties" stating how much a particular module is worth to them, and then us hackers are supposed to sit there reloading the page looking for something tasty, and code it in order to get the reward. The bounty model was presumably arrived at after conventional software companies realized that most of the people working on free software have no formal connection to one another and do this stuff in a very haphazard, "do it when I get around to it" way. Perhaps it's just because Free Software is the current Great Hope for silicon valley that companies think this will work -- I don't think it's going to do what they think it will. I think they're mostly wasting their time.
The bounty model encourages people to hide their work from one another. One "Code Hunter" gets all the reward, whereas 2 or more have to split it. So the "many eyes to see bugs, many brains to see design problems" approach is defeated. It also introduces the concept of scarcity back into an otherwise bountiful domain, and this encourages people to "steal" work, i.e. take something someone else did and claim it's theirs in the first place. If the work was not widely released yet, it's one person's word against another. This means everyone participating has to use crypto on their CVS repositories and never discuss what they're doing with anyone, which frankly sucks ass, and is identical to working in a closed-source company up until the moment of release.
One of the chief reasons that free software is as good as it actually is, is that the developers work almost exclusively on things which they enjoy doing, taking the time to do each step of the process the right way, and under the auspices of making the program intrinsically better. Merely being told to do something because it will reward you, that works, but it produces mediocre results. As we've seen time and time again, the really insanely great, paradigm-shifting, everyone-has-to-have-it stuff comes from completely different motivation, and the bounty model doesn't capitalize on this fact at all.
The other motivation for writing free software which has been identified in a number of cases is the "scratch an itch" motivation -- i.e. a technically skilled user/programmer fixing something they have to use every day which doesn't quite work the way they like, and they're both picky enough to care and good enough to fix it properly. This element is entirely ignored by the bounty model.
I commonly hear non-programmers saying that "oh, well, programmers are a dime a dozen". I think in this case the analogy of programming-as-art is most appropriate. Painters are "a dime a dozen" as well, but there's one critical point you need to know: most painters suck. As in, 99.999% of them. Same goes for programming. Programming, creative writing, music -- all these are in principle accessible and enjoyable to anyone and everyone. Far be it for me to claim that "dime a dozen" people ought not to program, as it's a good exercize and extremely enjoyable, and serves as a reasonable career inside a well-manages programming team. But the fact is that the very best programmers who characterize the free software everyone's salivating over are dozens, perhaps hundreds of times more productive, insightful, clever, and just plain in sync with the machines they work on than the "dime a dozen" people. Most of these shining stars that companies want to pick out of the free software community already know how to get contracts. Contracts on stuff they like, in companies they like. The reason such programmers are active participants in the free software community is because they like to do it as a hobby, albeit an all-consuming one. Often times they are academics, who actively want to stay that way. So the financial incentive, which is really the only one the bounty model is working on, doesn't really exist for most of the talent. These people already have jobs. Talent scouts from every company large enough to employ 'em pick these people out of universities. Companies randomly solicit them trying to steal them away in the night, once they do pick a job. In other words, while it might look deceptively lucritive from the raw number of people, really high quality programming labour is decidedly a seller's market.
This is the final, and probably weakest point, but even still I think it's worth thinking about. The issues involved in contracting with a person you will never likely meet, making legally binding agreements through the network, transferring money, guaranteeing non-overlap in work, transmitting produced code, discussing requirements with clients, creating and mimicing build environments or custom software setups, etc. are decidedly nontrivial. They're bad enough when you're physically on-site, in the same country, using the same computers, on a payroll system, etc. When you have to improvise such arrangements through the internet, there is a much clearer cutoff point below which the payment will not actually cover the hassle of doing the work. If these bounty markets are expecting to farm out hundreds of "$50 - $100 fixes" to people, I think most programmers will try one or two, realize it took them 2 weeks to deal with all the extraneous technicalities, and realize they won't be able to pay rent on this kind of cash.
What I'd recommend doing, if you really want to fund the development of cool new free (speech not beer) software, is to put up a forum (with associated search engine, categorization system, history mechanism, etc) where free software developers can describe what they want to do, in their own terms, on their own schedules, with their own priorities and requirements, and then let companies who want some new products to sell bid on the opportunity to fund its development. This works both for inspired developers ("I want to rewrite the whole sound driver system to support multitrack buffered 20-bit audio!") to itch-scratchers ("this library is not threadsafe"). Whoever funds each such proposal gets to market it and trademark it and do whatever businessy things they like with the final product (I think it's been proven by now that this works), so long as the license is good and the developer gets to work in the open.
If you think about it, this makes much more sense. Whereas a single programmer will become sullen and bored if forced to work on something they do not like, a company which sees something as potentially profitable, even if it's novel and unlike their normal line of work, can easily work a new product (one which the programmer does want to make) into their product line. Furthermore, you will get a much better picture of what kind of a programmer you're looking at if you see them lay out their dreams and desires for new code and let you bid on it. Rather than guessing, hoping, and praying you got someone competent enough to do the job, you would be given the chance to evaluate their motivation, clarity of thought, and skill level. They would effectively be writing an "grant proposal" for each project, except there's a technology transfer afterwards. Since their proposals are publically seen and the subject of the bidding in the first place, you know the primary contact & inventor of the technology (no hiding, stealing or backstabbing). You still get the "split the money between the people" effect to deter other people joining a project though. I don't think you're going to get around it. But I think if you invert the relationships of the marketplace it's much more likely to work.