The Problem With Bounty Software

Anonymous Piglet writes "Graydon Hoare has written a well thought-out essay on the problems with the bounty software model being promoted by organizations such as the Free Software Bazaar, sourceXchange, and CoSource. " Update: 06/11 12:23 by H : Norm J sent this tidbit our way: Cosource.com founders Bernie Thompson and Norm Jacobowitz have posted their responses to Graydon Hoare's Essay on the Problem with Bounty Software . It is available at the Cosource.com site.

Comments

Well, yeah, but he's still smokin crack . .

[alhaz]

What he fails to realize is that there's an awful lot of lone-horse open source programming going on.

This happens for a variety of reasons that have nothing to do with money.

First, and most common, is the back yard doghouse effect.

The community model has every one of us keeping our dogs in a big kennel in the park. This is what's most sociable, right? If you're a dog owner, I can tell you're probably shaking your head violently. Especially if yours is of the female persuasion.

Most people would prefer to keep their dog in their own back yard, separate from other peoples dogs. For the same reasons (purity, ownership, etc) many people prefer to write their own pet programs.

Second, ignorance. A lot of people falling into the "annoyed" model have no clue what anybody else is doing to solve the problem. I know this isn't often the case, but there are some apps for which there is no other conclusion.

My Completely Biased OpenSource Fragmentation Quotient (CBOSFQ) currently stands at 11. Checking FreshMeat's appindex today, there are 11 individually packaged ident servers. This does not include one program written to test ident servers, nor does it include a transparent irc proxy.

All of these ident servers have one or two of about 3 features (with the exception of pidentd) - they allow masqueraded ident (poorly), or they allow a specific false ident response (unwise), or they allow a random ident response (will get you kicked off a server)

The existance of eleven ident servers is inexcusable. This is a very simple service we're talking about.

The worst part is, all of the "advanced" ident servers with special features seem to be about half baked. Instead of one really good alternative ident server, we have 10 of them that are almost but not quite.

Anybody who thinks the open source movement represents some kind of utopian marxist society is smoking something. Nine out of ten open source users and programmers would settle for free beer.

I agree that the bounty method of encouraging open source development comes from a flawed concept, but the end result is no worse than what most people are churning out already. Probably better, because the guy signing the check probably wants a finished product.

Counterpoint

[bgarcia]

I've already posted a counterpoint to his article on Freshmeat. The original is here

But I'll reproduce it here as well:

Now, I don't believe that the bounty model is going to take the world by storm as the open-source model has, but I do think it'll survive as a niche.

I think there are two flawed assumptions made in this essay:

1) That software developed in this model is only developed in this model.

2) That open-source software must start out that way in order to be of high quality.

Point-by-point:

1: It's Not The Community Model

As Eric Raymond stated in The Cathedral and the Bazaar:

It's fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode.

That is, software can start being developed (indeed, must be developed) in some other model before being released into the bazaar. It must first be a runnable, testable program before people will come along and turn their eyes to it.

The new bounty model is a model that fits just this first step. The program gets written. After the bounty has been collected, the program is now open source, and has all the benefits that any other open source program has.

2: It's Not The Inspired Developer's Model

3: It's Not The Annoyed Developer's Model

That's right - it's a new model. While we have seen that the Inspired and Annoyed Developer models can work, that does not mean that other models don't work. Many problems in the world are solved by people who need something fixed, but don't have the skills or time needed to do it. So they pay someone else to do it. It's a time-tested model that works.

But again, once the program has been created and released, these Inspired and Annoyed Developer models will start to be applied, as people start to use the program and fix the things that bother them, re-write the things they believe could have been done better, and add functionality that will make the program even more useful.

5: It's Technically Difficult

It's funny that you called this your weakest point, but I actually believe it was your strongest. This model has never been tried before, and the logistics are going to take some time to iron out. It could fail simply because people are too afraid to make changes needed to make use of this new model.

Another Approach

I don't believe your forum model would work all that well. In your model, many developers will state what they wish to work on. Some will go ahead and do it anyhow. Others might simply be blowing hot air. Businesses will not want to wade through the hundreds of postings on such a site to see if anything comes close to matching their needs.

In the bounty model, there are fewer posts, because only a few companies that are seriously interested in seeing a project completed will post projects. Some developers will undoubtedly look through this list, and even though they aren't currently interested in something, might find something that sounds interesting and want to give it a shot.

99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again...

Scratching Itches

[purp]

It was, indeed, a well considered essay. However, I'm forced to disagree on a number of points.

Why assume greed?
Money hasn't been the motivator so far; why assume that once someone's thrown some cash into a bucket that this event is going to transform the community? It seems more likely that teams of college kids will band together to make enough money for a party/trip/whatever, or that LUG programming SIGs will look to this as a way to earn funding for the group. Some programmers may have a go at making this pay the bills; perhaps it will work. I don't think we're all going to drop what we're doing and become bounty coders.

What about peer review?
Both sourceXchange and CoSource have made peer review an integral part of the process -- and a bar that must be cleared before getting paid. I don't think that it would make good business sense for them to lower that bar any further than the project sponsor(s) want it to be set.

Inspired Annoyance
If people were already getting interested, there'd be no need for a bounty; in effect, these companies are saying, "We'll pay more if someone can do something which would benefit us in a timeframe we can accept." This doesn't mean that spare-time hackers like myself will flock to it because it's a paid project -- you might well find that the money convinces someone who was already a bit interested in the project's aims to rearrange their priorities in order to get paid to scratch their itch.

It's Still Open Source!
My final, and strongest, point: no matter what, the end result is open source. If you think the code's sloppy, pitch in and fix it; if there's not enough art in the crafted code, show them what Michaelangelo could have done with a keyboard. You've got the choice...and in the meantime, we've got the code.

I'd probably ramble more, but I've got to go to work. You get the idea.

--j

A little Diffrent?

[Q-bert][]

I think these web sites offering these 'bounties' shouldn't offer bounties on the actual code but instead on the programmer who's willing to write and also become a 'manager' of that code. This way the programmer could sign a contract with the company stating that he will write and also manage the code. Then the code could be released on a cvs server and anyone who wants it may have it and be able send in bug reports and patches to the hired manager. Basically what the company would be doing would be hiring someone who does what Linus does (not writing the kernel, but managing the kernel tree).

Potential problems

[Christopher Thomas]

This is an interesting take on the issue, and the proposed model has advantages (letting the programmers act creatively being one of them). However, there are problems with this approach too.

The main problem that I see is that there will be great pressure on the programmers to come up with projects that sponsors will like. This will be a market controlled by the buyers - projects that sponsors aren't interested in won't get funded, no matter how interesting or innovative they are. While the same is true in the bounty system described, this new approach doesn't alleviate it. IMO, neat but unprofitable work will continue to be done on spare time or by blue-sky development teams.

Secondly, I'd like to address the point re. bounty systems encouraging closed development. This can indeed happen - but it depends on how the bounty system is implemented. If I understand correctly, the newer schemes that have been proposed allow teams to bid on the jobs and sponsors to pick the teams that they like. Then the contract is finalized. If most work is done after the contract is in place, there isn't the duplication of effort that you get with the original bounty approach (six people writing something independently and only the first getting paid). You also don't have to get closed development - once the contract is in place, it doesn't matter if others can copy the work, because only the original group will get paid for it. The original group loses nothing by sharing. Finally, programmers would still have to work in groups under this system. A really large project just can't be handled by an individual. Smaller projects might be handled, but the sponsor may want it in a shorter length of time (though there are hard limits to how much a project can be shortened by adding developers). In short, I don't see a well-implemented bounty system hurting openness.

The one point which remains valid is that the software projects offered may not be very interesting or innovative. IMO, this is a tolerable tradeoff. Nothing prevents the programmers from doing something more useful in their free time; this is just a good way of arranging contract work so that the programmers can get paid.

There will also be pressures on sponsors to _make_ their projects interesting. If they present a project that nobody is interested in, they'll either have no takers, low quality takers, or have to jack up the price to unreasonably high levels. Employers presenting interesting, innovative projects will have the advantage in this regard, which is a Good Thing.

IMO, there's actually a place for both systems, but I feel that the modified bounty/work order system would be most practical in the near term.

a related idea: "source futures"

[stowaway]

Another idea for funding open-source software: A company C prints 10,000 certificates ("shares" of "software futures.") These "mature" when there exists some open-source software which meets some condition. For instance, there might be shares which mature when there is an Apache-licensed Java 2 implementation for Linux & FreeBSD which runs some benchmarks at some speed. (A company X, separate from C, is paid to act as a tester.)
Suppose Eliza buys 100 shares at $5 each. Then, she works on the Java3D implementation. This drives up the price. A sponser (say, Sun, or Fred, who wants to use the Java3D stuff) might be willing to buy shares for more than the trading price, say, $20 per share. This raises the price. Submitting bug fixes helps the developers, so users who have invested in a project have an incentive to submit bug reports.
When the testing company, X, downloads the package, installs it, and it finally passes, then C pays 1/10,000 of the total that people paid for that certificate (minus a profit), per share. Suppose that each share pays $15. Then Eliza has made money. Fred has lost money, but hey presto! the software he wanted now exists. So: it seems that there's no need to copy-protect, or even too much need to encrypt the CVS archives. Developers choose their level of commitment by deciding how much stock to buy. (You might say this idea is just "open-source stock options.") Developers who buy 100 shares presumably will have more incentive to work on a project than developers who only buy 10 shares. But developers can choose how hard they want to work on something. Clearly, the testing company, X, has to be trusted to certify the software if and only if it's good enough. Also, the spec has to be clear...not so easy...
Josh "stowaway" (jburdick@gradient.cis.upenn.edu)

You know

[DonkPunch]

#define COMMENT_TONE HUMOROUS /* So don't take me all serious and stuff */

You know you're reading a serious, thoughtful, and considered essay when the author uses the following description:

"...which frankly sucks ass"

I'll be sure to include that phrase in my next status report ("Dear Mr. Vice President: We have encountered some unforeseen problems in using the new network cards. They frankly suck ass.")

Yep, I think a big promotion is right around the corner! :)

Flawed Points

[Frank Warmerdam]

First let me say that I don't expect the bounty system to handle large amounts of money (ie greater than 100million/year) in the near future. However, I think it may make a significant contribution to the OpenSource arena.

I think that Graydon raises some issues; however, I think most of them are addressed by sourceXchange.

Code Hiding:

Once a project has been assigned to a project team there is no reason to hide code. I do think that bounties based on the ``present us a working solution, and then we will pay'' with no continuing arrangements isn't going to go anywhere for the various reasons given.

Thus I would claim that bounty software (ala sourceXchange) can be developed in a community manner. However, you may encounter the situation where people don't feel like helping if they aren't getting paid since they figure the guy getting paid should do all the work.

Sullen/Bored:

Graydon suggests that developers doing bounty projects will be sullen and bored because they don't really want to be doing the project they are working on. I see the bounty system as a way of getting funding for projects in people's areas of interest. If you don't like what you will be doing, don't go for the contract. Generally I don't think the bounties will be lucrative, but rather will give a moderate level of income while working on a desirable project.

Technically Difficult:

I agree, but I think that sourceXchange has come up with some excellent techniques to deal with these problems. It remains to be seen how well they will work, but they can. Of course, they won't work for little fixes.

Another Approach:

I do agree that a mechanism for proposing projects that developers want to do could have value. I am not sure how it could be best handled though. Generally this works best for people well enough connected and known within an industry that they can present unsolicited proposals to a bunch of vendors that might be willing to back the project.

At one point Graydon talks about how the companies funding such project could then market the product and make their money back. I think this is a flawed view of why companies will fund such work. I think it will usually be to fill a gap in a larger product (for instance improved web server software for company that fundamentally sells web server hardware, or a library for translating different file formats). While the work should help the vendor --- usually by avoiding the cost of developing the software themselves when it is not a key piece of IP, I don't imagine these things will often be marketted by themselves.

In closing:

I mostly do projects within a narrow industry (geomatics data translation) that could fall under the bounty system. Most of the issues are the same as those Graydon points out, and yet I do fine. I think I (and others with less connections) could do better if there was an easier way of identifying projects that people want done.

I wish sourceXchange well.