Slashdot Mirror
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.
I'd have to disagree with the author of this essay. I'm not even sure if this should be called an essay or just a plain rant. His first mistake is using the word bounty and shows he doesn't fully understand what sourceXchange, CoSource, etc are really about. He explains it very simply, leaving out(or forgetting) what's going on between the developer and the company. It will not be a simple, post the problem and wait for someone to finish it and reward them. There will have to be a lot of communication between the developer and company. The company will have to assess the developer's skills, experience, work ethic, etc. In the end, the company will have the choice of accepting or rejecting the developer's application to work on the project.
"The bounty model encourages people to hide their work from one another."
This is patently false. For some projects, it may be in a company's best interests to choose a closed source license, but I think most companies coming to CoSource/SourceXChange are going to know off the bat that CoSource/SourceXChange encourage and prefer open source model license use. There are many more factors that need to be taken into account, that the author does not. A good reading of both CoSource/SourceXChange web sites(which I don't think the author did) explains this very well. He assumes, automatically, that because these projects are for the evil corporations, they'll be closed source, which is an incorrect assumption.
"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."
This is true, but again, it's the developer's choice to apply for the project. No one is going to be pressed into doing something they don't want to. Another thing that is mentioned quite a bit on CoSource/SourceXChange websites is that these projects are mostly things that the companies don't have the time or manpower to do. I also think that this is a boon to aspiring developers to gain recognition and add to their resume. I for one would enjoy being able to find something I would like to work on and do a good job on it. I often times have problems coming up with things, within my ability, to do. If this would help that problem, and I could get something(be it money, or hardware, or just experience) out of it, I'm all for it. Of course you're not going to see the next Perl or GCC compiler coming out of these projects but that's not the idea.
"The other motivation for writing free software which has been identified in a number of cases is the "scratch an itch" motivation"
Again, you're correct, but this is not free software development, in the traditional sense. This is someone(a company) posting what they need, and looking for someone to do it. That someone may have any number of motivations for doing the project. If the project turns sour, it's not that big of a deal and everyone learns from it. It's not that big of a deal, because, for one, the company is going to be posting critically needed projects, they'll use a more traditional approach to getting that done. Two, the only time wasted is by the developer. Companies aren't stupid, I doubt anyone is going to be paid until it's done, and done correctly. Again, this is all up to the contract between the company and developer.
"It's Not The Market's Model"
No, it's not, it's a NEW model. It's a model that's never been seen on this scale before. That's what the Internet is about, change. The author talks a lot about the best of the best programmers, but more than likely, they already have good jobs and may not be interested in this line of work. There may be terribly complex projects offered by these services, but there's a higher chance that there will be more smaller projects. The peer review process of SourceXChange sounds like it will alleviate the problems of just bad programming. A reviewer, of some expertise, will see how the project is going, and let the sponsor know if things are not up to par.
"5. It's Technically Difficult"
This point can't even stand on the legs the author tries to build it. These types of things have been done for a number of years now across the internet without problems. I wonder if the author has ever had to sign an NDA, or a contract with a company to develop software for their product. This can, and will be done over the Internet. It's cheaper, and faster. No telephone bills, no expensive plane flights, etc. I don't know if the author was serious about it or not, but I doubt anyone is going to depend on paying their rent with this system. At least not when it first starts. Who knows where the future will go though. Maybe someone does such a good job for a company, that they company ends up hiring them. A person just can't tell where this is going to go right now, it's so new.
Frankly, I think the author's "Another Approach" is a pipe dream. It's a fanciful idea but completely unworkable. I think that very few individual's interests would lie on the same track as a companies(unless they worked for that company, and then it's moot). Many ideas are posted on Usenet and mailing lists and webpages and I think that's those are appropriate places to post them. At least, these forums have a lot more bandwidth available than any end-all-be-all "I'll do it for a dollar" developer's idea website.
In closing, I think the author is viewing these services in an incorrect light. I think he feels threatened by them affecting the free/open source movements. He doesn't have anything to fear. Even if a project turns out to be a terrible program, there will be people out there, if they truly want to do something, that will develop a better program, in the spirit of open or free source.
Dodger_
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.
This is just like television, only you can see much further.
Maybe we shouldn't think of bounty software as open source. The essay compares it to open source and finds it lacking because it looks more like proprietary development in many ways. So, compare it to normal proprietary development.
In the end, you get open source software. That seems an improvement over normal closed development.
The quality may be better or worse, but the market will determine the price, and it will determine the winners and losers. If a company pays to have something developed that already exists out there, they lose. Simple, but not a problem. Companies will probably become more aware of what's out there.
And there's no reason to assume only individuals will bid. I would think, over time, market forces will select for good teams of developers that have a broader suite of skills. The lone "dime-a-dozens" will not be able to compete for coding projects.
And for the final alternative suggestion, it was my understanding cosource.com was going to have both developers and consumers initiate project ideas, which seemed to be the main point of the suggestion.
First, make it work, then make it right, then make it fast, then, make it bloated!
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.
But (imho), the difference is that many open-source projects (eg. the Linux kernel) don't need to be developed in a "closed" environment very long before they seem interesting to other developers. The so-called bounty model encourages companies to advertise for complete works - taking the same example, if Linux was developed under the bounty model to start with, the advert would read "Full Unix-like kernel to run on Intel hardware required". Even assuming that Linux 1.0 was good enough, would the development resulting from this have been as effective as the group effort that actually occurred?
I admit that there are some projects, such as those where a great deal of design and specification are needed, and those which just fill a not-very-interesting gap in a current package, which can benefit from the bounty model. But in general, I would say that the bazaar model would be far more productive (and enjoyable).
--
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:
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...
I'm a leaf on the wind. Watch how I soar.
I think every Hoare's aspect analysis will prove to be correct. Although I'd love to see OS developers to be rewarded financially for their work, money will change everything. I can't see a way to make it workable.
Perhaps the best way for corporations to support OS development is to migrate their "intellectual property" to an OS model.
I think that someone who spends 3 months writing the manual, then contacted the FSF and said "here it is! Pay me!" is not a very shrewd businessperson. Surely there would be arrangements made beforehand, perhaps a contract, based on the person's resume, ability, background, etc...
The email from RMS regarding the manual said that they would be willing to pay for the manual, but did not offer specifics. I am sure that there are lots of details which would need to be worked out before work began in earnest.
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
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).
This essay made many questionable assumptions and assertions; however, it made one excellent (as in, truly excellent point) about reversing the arrangement -- instead of offering a project w/ bounty and trying to find developers who are interested in it, offer developers' ideas and try to find sponsors for them. I think this model has the potential tpo combine the best of classic OSS development with the obvious benefits of the 'bounty model'.
Will it work? I certainly hope so. Has anyone tried something like this yet, the 'sponsor model' rather than the 'bounty model'?
--
--
Victor Danilchenko
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.
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)
#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!
Save the whales. Feed the hungry. Free the mallocs.
I agree that this is the biggest problem with the model and there are a lot of complexities which I think have been overlooked. The first thing that popped into my mind when I saw this model was if you have multiple people offering bounties for the same project (which would be necessary unless there's one big contributor or somebody who would have done it anyway) they are likely to have different requirements on what the finished project should look like. This complicates the programmer's life a lot if he has five different bosses to satisfy none of which are providing significant income by themselves. The other related big problem is that project requirements almost always change mid stream. Even if you can get five different companies to agree on a spec beforehand, it will be a royal pain when the project heads off in five different directions mid stream.
Don't get me wrong, I'd like to see this sort of thing succeed. I hope that somebody can come up with good solutions to these issues so that we have yet another model to work under.
-----
Free P2P Backup, Windows & Linux
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.
Geospatial Programmer for Rent
I can't take the time to dissect the article right now, but any developer experienced in writing both free and commercial software should be able to see that this person's arguments are way off base.
:-)
In my experience (and I have mentioned this in other discussions), the single biggest problem with the "Bounty Model" is getting someone to pay the bounty. That's it. It's not all the work that goes on after it, it's getting someone to pony up the dough.
You see, companies don't want to give things away. If they give you cash, they want you to give them, and only them, something in return. They don't give a damn about giving back to the "open source software community." In fact, not caring just makes good sense.
If a business sees an advantage in developing a piece of software, they are *not* going to pay to have it developed and then just give it freely to their competetors. That is the reality of the situation as I have seen it, and I've been trying to actually do this sort of thing for longer than the PR machines of sourcXchange (et al.) have been running.
The whole nature of the discussion changes, of course, when we move away from corporate participation to individual participation. Let's save that for another discussion.
Posted by Lulu of the Lotus-Eaters:
I agree this was an interesting article, although also one a little bit disappointing to me if true. I am in a position where I think I will be attempting to farm out some work on a project that I want to release in an OpenSource form. I won't directly be the deep pockets, but I will hopefully get a chunk of change from those pockets, and think that both my background and schedule suggest that I'd like to find some help on the project.
With that in mind, I looked very hopefully at some of these "Bounty" models that have been discussed and set up. I very much like the idea of offering up work in this form. The alternative, for me, I suppose is just a more old-fashioned sub-contracting. That can probably work too... but it doesn't have any of the feel of OpenSource in that aspect of the process, even if I then eventually release my final code in an OpenSource way.
Related to this though, I'd like to take exception to one point of the article. The author claims that 99.999% of programmers--like the same number of painters--suck. I think I might quibble with the precise degree of exclusion, but obviously there is more mediocrity than greatness in either arts or programming (arts). My reaction to this is "So what?!"
I think I myself am not in that 0.0001% of the great ones. I'm not even in a more generous 1% of the greatest programmers. But I'm adequate, even a bit good. And that is enough to write what it is I need to write. And that would be fine to write the rather boring project I want farm out. I don't need Linus, or RMS, or Larry Wall, to write something that tracks a few records in a database, and presents a few formatted screens in a web-browser. It is real workaday stuff, and mediocre is good enough to get this done. In fact, for medium-sized not-too-profound software projects, RMS is not even going to code them 10 or 100 times faster than I am. 50% faster, sure; maybe even twice as fast; but no orders of magnitude, and no 3x multiplicative factors even.
I think that projects like the one I have hinted at make up an awful lot of all software--even of OpenSource software that scratches some little itch. And I even think there is nothing wrong with that. For this sort of thing, the bounty method seems more reasonable than suggested.