Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Almighty Buck

The Problem With Bounty Software 85

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: 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 site.
This discussion has been archived. No new comments can be posted.

The Problem With Bounty Software

Comments Filter:
    • Why assume greed?
      Humans are naturally greedy

      Basically, if the bounty makes no difference to you, then why offer it?
      If it does, then your plans will be skewed so as to maximise your chances of achieving the bounty (i.e. minimally satisfying, minimal time).
      In either case, nothing good is added.

    That said, I think that your arguments in favour can be summed up in the argument that it should be possible for companies to provide a financial catalyst to the development of a particular solution to a particular problem, because THEY NEED IT. And it is true that there isn't much of an alternative as to how to satisfy this need.

    Conclusion: We'll see...

  • 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.
  • Getting companies to pay for development certainly is a problem (hell, getting a customer to pay for development is often a problem...) but its not the obstacle you make it out to be.

    Something like 80% (does anyone have a citable stat for this?) of the money spent on software development is for customized vertical applications. I've happily worked for almost 10 years in the industry and never once considered working for a company that produced a mass-market product. Look at the traditional sources of UNIX development: the telecom industry, defence industry, universities and scientific research organizations. If they feel that its worthwhile to pay you to develop some tool or module, they'll pay to get it done. If you write a perl module and work for Alcatel or Cisco, they aren't going to spend the money trying to market and sell it to the world. Will they care if you GPL it? Usually not. It's good PR.

    If the software needs to be built, it will be built. A lot of times it will be paid for and built by companies that don't sell software. It doesn't affect them one way or another if you give it away.

    True there are some companies that specialize in developing software and will go to great lengths to protect any development they do. But many companies develop software even though they don't compete in the software development market. Its just a means to an end and it doesn't hurt them a bit to give it away.
  • The reason I believe the bounty is cool is that not everyones inspiration, or itch, is what anyone wants or needs. I can see a business etc needing something done that no-one has undertaken because it doesn't strike their fancy. Lets look at the plethoria of MP3 players and dearth of spreadsheets (quick name 3) much less all the other stuff that makes for a rich environment. Overall $$ make the world work.

    The biggest problem and the largest strength from being part of the OS thing is that everyone bitches and questions everything. There is room for every grey area in the software world from RSF and his software utopia to the iron fist of M$ (well maybe not) but that's the thing that makes us great, If you don't like it don't participate, if enough people agree it will wither and die. But don't try and tell me not to if I so choose this is my world as well as yours and I believe less rhetoric and more code will make it a happier one.

  • While the bounty or sponsor model have commercial overtones, I would suggest that the {rich individual | corporate} patron model so prevalent in the Renaisance era is closer to the gift economy that Raymond espouses. This is where the patron demonstrates their {benevolance | lucre} by funding artistic works for public display (Sistine chapel, etc). Given that the highest levels of programming is more akin to art rather than engineering, I would speculate this may be more attractive to the highly talented segment of the hacker community.

    The biggest problem I see is that in a rather large but closed world, it takes a while for "names" to be recognised as stellar qualities (e.g. Linus) and the reputation takes a long time to build up. But maybe this can be viewed as an incentive for people to contribute to OpenSource in that by associating a name with a successful project, they can effectively provide an open job resume to the world? Much like the journey-man stage of publicly displaying goods for review by the customer, it can be viewed as a necessary stage of development towards mastering a field. I can forsee the day when employees hand-pick programmers based on recognised contributions to an OpenSource program which clearly demonstrates their level of skill. To support this model does require some work in that OpenSource projects have a clear attribution history of contributors and their degree of worth (e.g. hacker X contributed n% to the design and high-level coding).

    The biggest hinderance is that nobody has resolved the inherent conflicts with existing commercial models.

  • How can you say in the same note that 80% of development is for vertical market apps and that it doesn't hurt companies to give it away if they aren't in the software business? If Walmart develops a program to make their cashiers and customer service personnel five times more productive, do you honestly think giving it away improves their position in the marketplace? They will care like hell if you burn a CD and ship it off to Kmart, let alone open source the product to every single one of their competetors.

    Why do you assume that they are willing to give it away if they aren't willing to market it? This is about business, and it takes money to run a business. That is why companies are so eager to use free software, but so unwilling to fund free software. Honestly, how much open source do you see carrying the copyright of a company vs. an individual? Where are your PR machines announcing the selfless efforts of Alcatel and Cisco? While companies like Apple are trying to be more open with their (internally developed) source, they don't like the standard GPL, so the lawyers start twisting . . .

    Every time these pie-in-the-sky "companies might pay for free software" discussions come up, the usually fail to answer the overwhelming question that is of concern to the companies involved: How does funding open source give my business an advantage in the marketplace? If the advantage is provided by software, bought or built, they will do everything they can to keep others from realizing the same advantage. Until that one question can be adequately answered, the only pay-for-free future open source will have is through individual donations, and the companies will continue on the ride at no cost.

  • I think there's the beginnings of a good idea in here, but not as you've described it. "Source futures" sound like an excellent way to renegotiate bounty-type contracts after they have been made.

    I can imagine it working like this: sponsor X is willing to issue 1000 shares (I hope you'll excuse me if I'm not familiar with trading terminology) for the completion of project X, and promises to pay $10 per share when it is done. A group of programmers apply, and the company, after negotiation, agrees to give some of these programmers various amounts of shares. They may assign specific roles to each programmer. All programmers will be paid out on their shares when the project is complete.

    As I understand it, this is not far from how sourceXchane and coSource and so on work now. It's not incompatbale with ideas of partial payment at milestones. The beauty of using a "share" or "futures" arrangement though is that the original programmers can use their shares to sub-contract other programmers to complete parts of the product.

    For example: a programmer offering X shares to another to build a component; one person given all the shares and asked to manage the entire CVS tree at her discretion, and subcontract off parts of the program; a programmer offer a patch in exchange for X shares; a programmer might even advertise for sub-contractors though sourceXchange or coSource. Sponsors could encourage development by increasing the payout of the shares, offerig bonuses for early completion, or issueing more shares. New sponsors could offer to increase the price of the shares if the project appeared to be floundering. You could imagine paying someone a fee to get the shares and take over a partially completed project.

    This is simple, in the sense that everyone is familiar with the share-market metaphor, and programmers are motivated to keep their source open and to encourage contributions. The most obvious problem is free-rider behaviour; there's nothing to stop a poor programmer obtaining shares and doing nothing, then being rewarded at the end. I guess reputation is the only solution to this problem.

    There are two problems I think any system like coSource and sourcExchange will encounter: administration overhead, and resentment from programmers who did not get selected for a project or who have a solution for the project but do not want to release it because it will immediately financially benefit somebody else.

    It will be interesting to see what happens to both sourcExchange and coSource. On a philosophical level, I don't know that I want them to succeed--open source is doing fine without many dollars changing hands, and the love of money is the root of all evil, as others before I have observed. On a practical level, I can imagine trying to make a living as an open source programmer myself one day.

  • I appreciate all the comments that have been posted, particularly those from Frank Warmerdam and _Dodger. BTW, I'm the Brian involved with sXc, under my posting identity on /..

    Most of the points I was going to make have been made; particularly the point about the fact that we are not a bounty system, but a project-based system, which means that the developer and sponsor agree to work together at the beginning, rather than the end, of the development cycle, and that the developer is paid according to a series of milestones in the project. This is the only sane way to do larger projects, and I think it addresses some of the original essay's author's comments.

    Also, since announcing sXc, the single most often asked question, one way or another, is, "can developers (or anyone else) propose projects that can get funded". As time has gone on, we've realized this could actually be a much more effective way of generating funded RFP's - rather than trying to guess which companies would have projects they'd want to fund, we'd look at projects that the developers have identified as crucial, and try and figure out who we could convince to fund them. In our old thinking, this was the tail wagging the dog, but we now see this as really the dog wagging its tail.

    And of course, long-term, the real funds for projects will come from the end-users who aggregate their funds for projects. Think about this - a conservative estimate on the size of the Linux user base is 12 million users. Imagine if each of them were to contribute $40 towards the evolution & development of Linux-related software (the kernel, utilities, graphical apps, etc) over the course of a year. That would be $480 million dollars available for projects!

    Finally... keep in mind that there is tremendous flexibility for what can constitute a "milestone" in a project, and what a project itself can fund. It can be source code, but it can also be documentation, test suites, UI/installation, quality assurance... all those things that tranditionally haven't been done by developers because, frankly, they're usually pretty boring to do. We can also have projects for which each milestone is simply a marker in time: for example, let's say the project is "to monitor and maintain the 3C509 network card driver family in *BSD over the next 6 months". Let's say each milestone was simply that every two weeks, developer would report to sponsor what they did to fulfill that directive. Maybe there was a kernel change that mandated a patch; maybe there was a new model of a card released; maybe there was a new bug posted that needed addressing. This is a much looser kind of project, but it could be exactly what is needed to help make sure that card family doesn't suffer from bitrot long-term.

    At any rate, this is definitely a new space that CoSource, sXc, and other efforts are entering, and we're going to make mistakes no doubt - but every day I get more optimistic that this is actually going to work. =)

    Thanks for the comments, all.


    p.s. - the first draft of the sXc developer agreement is now online. Comments welcome. [].
  • A point of sale system for Walmart would generally give only a modest boost in productivity over whatever is in place. Having a good PoS system in place is important, but any given one won't be that much better than another.

    PoS systems are also not very industry specific. In addition to Kmart, stores that don't compete to a significant degree with Walmart would benefit. A given competitor, like Kmart will generally not be positioned to adopt the system in the short term anyways.

    However, you are right that some companies will be irked to see a competitor be able to take advantage of the work they funded. To make up for this it is often necessary to identify benefits for the original funding company to going OpenSource. Such as, they will benefit from improvements that others incorporate, or perhaps that the developers will work cheaper on an OpenSource solution.

    I usually give a modest discount on OpenSource work, because it gives me a code base to work on for the next project I bid. And when I bid the next project I can charge a premium because I know the underlying technology better than anyone (I wrote it), and because I have the technology to leverage in doing the next customers project more cheaply than would normally be the case.
  • This is actually a very good point. A project done on a bounty may become orphaned once completed. Of course this can happen to any OpenSource project, but it is moreso of a problem in this case, because it isn't obvious that the original development team loves the work enough to maintain it after finishing.

    On the other hand, the original funding developer does have some impetous to do maintenance, and if done well, and provided as OpenSource anyone who is interested can take on maintenance.

    Nevertheless, this is a risk worth taking. I think that vendors may also select for teams that they believe will maintain the product after initial completion.
  • by alhaz ( 11039 ) on Thursday June 10, 1999 @07:54AM (#1857262) Homepage
    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.
  • Here is another thought, How bout at the end of a certain time period (say, 6 months) Everyone is given a forum in which to present their work. The community could then vote on who gets the cash. I suppose ballot stuffing would be a big concern. Perhaps the org. that offered the money would decide which is the best. Just an idea...
  • sure looks like the old guard is confused/afraid about what to do re: the "new" software/business paradigm.

    some evidence is the volitility in the DivertOurWealth markets.

    also, quite interesting to note: when the market index drops below a certain level (usually around 100 pts.), they forums at the NYT shut down until the index "stabilizes". usually from 1-2 hrs. what a pathetic sham the bulk of the BSmediaHYPE deceitmachine is.
  • 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 was going to have both developers and consumers initiate project ideas, which seemed to be the main point of the suggestion.
  • 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.

    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).


  • It's a great essay with a lot of well-considered points. The incentive to conceal part of one's work is worrisome. The grant-proposal model addresses some very valid concerns, and if I were trying to make a living as an OS author, I think I'd prefer it to the bounty model. It certainly offers more creative freedom.

    Getting back to the incentive to conceal, would such concealment be more of a threat to the open source movement than the existence of purely proprietary software? It would mean that some valuable work would fail to be disclosed, and that's a shame. But realistically, proprietary software will continue so that is inevitable.

    Maybe it's good to try several different OS development models at once, and let the controversy play itself out. The temptation to select "the right model" and discard the rest makes the presumption that people in the future will either be dumber or they'll lose the passion for free speech. Better to present them with historical empirical evidence of what worked.

    It would definitely be a good thing if the grant-proposal model were pursued. Maybe the existing websites could be add a grant proposal area.

  • Graydon's essay is interesting, but definitely not a new proposal. Allowing talented developers to post info on areas they are working in or are interested in working in and having companies purchase the rights to the completed work by funding it is something we tried several years ago.

    We termed it the "rock band" approach to software development. Like a good band, you get some of the best musicians (developers) together, come up with some good music (software), and find a record label to produce and publish it. You get all the creative aspects of coming up with your own stuff and all the benefits of having someone pay you to do it. It was a win-win because companies only sponsored/funded/bought stuff that fit in with their business directions and the developers got to build stuff that they owned if no one else wanted to buy it.

    Unfortunately, every single company we talked to (and we talked to a LOT, from Adobe, Apple, and Microsoft, to IBM, Dell, and NASA) not only failed to see the benefits of this arrangement, but actually thought it was such an alien concept that they generally dismissed it out of hand.

    The 2 barriers seemed to be the need for some serious marketing horsepower on the part of the "rock band" and a fundamental shift in how companies acquire software engineered outside the narrow confines of their own organizations.

    In short, Graydon's proposal (and the "rock band") will only work if the developers' reputations are sufficiently high that the quality of the product can be guaranteed, if there is sufficient marketing muscle behind the developers to get the word out about the new approach to developing outsourced code, and a sufficient number of companies decide to adopt the new approach. Otherwise, this is just another nice idea to be dismissed out of hand (again.)
  • While I aggree with most of what the author has said here, there are Times when only money is going to motivate programers GOOD programers to work on that problem. For instance, I have a want for a piece of software, that I don't know how to write... or how to approach to write. What I'm looking for is A Microsoft Proxy Client for Linux. I don't know of any Linux programers willing to work on this, and I've been looking for 4 months... However I think that if I offered some cash for it, maybe I could find someone who would be able to write such a client. Another example was for the longest time, Word processors. We as a linux comunity Needed a good office suite and for a long time, no one would write one, because office suites are boring to code, a pain to debug, and overall just not much fun.
  • While I think that the essay makes some very good points, I think his solution is no better. The average company expects results from their money and without a guarentee that this will happen, no one is going to fund hackers to just do what they want on the hopes that it will be useful to the funders.

    The problem really is cultural - propertarian models are fundamentally different from non-propertarian and no amount of window-dressing will change this.
  • This is simply not true, as is clear from the WalMart/Amazon lawsuit. WalMart claimed that Amazon hired away their data warehousing team and thereby stole trade secrets. Amazon eventually settled by removing this team from anything having to do with this aspect of their business. No software was even involved, just the contents of some people's heads. You can be damn sure that they are not interested in open sourcing their software - they consider it a crucial competetive advantage (and having talked to the team leader I believe it).
  • OK, the single-word response was enjoyable, but now I've given this a little more thought, and here's a more detailed response. Yeah, I know, who the hell is going to read a dead slashdot discussion? Well, you. ;-) Get a life.

    Most companies, particularly small ones, have a set of "crown jewels" written by the founders and/or key employees, representing some sort of "core competency". Ick. Hate that phrase, but it fits. Anyway, they usually don't hire contractors to work on that stuff. They hire the contractors to work on stuff at the periphery, often the scutwork, often maintaining the worst ugliest pieces of code around. Contractors are called upon to hack on broken pieces of an inconsistent whole, with requirements coming from panicked managers who have to ship something this month. Most good programmers couldn't be lured into such an environment for any amount of money.

    Successful contracting is as much about marketing as about anything technical. Contractors have to network, so they go to trade shows and hang out online and have elaborate web pages. They overstate their accomplishments because that's part of the job, so PHBs and the terminally naive think they're big shots, but the claim is most likely to be nothing more than hot air. Sure, contractors can make a lot of money, but that doesn't make them good programmers. If I wanted to find a good programmer I'd look in the back rooms of startups (the front-room guys are just like the contractors).
  • "but if you get paid less than some slacker.. that will create some serious problems"

    I get paid less than certain slackers here in
    the corporate world. What's unique here?
  • I'm not sure quite what to think of this trend. I'm not convinced it's an entirely bad thing. The latest FSF offer for a manual is probably the only way such a manual will get written. Frankly the people with the knowledge to write it don't want to spend all that programming time writing documentation. That's unfortunate, but it's how it is. So in order to get such documentation someone will probably have to pay for it, as the FSF is offering to do.

    How else would we get the documentation? Perhaps FSF could hire a single writer instead of a bounty, but it's mostly the same thing.

    On the other hand... What happens if 8 people spend the next 3 months writing the manual. One of the 8 gets there first and collects the $20k (assuming all 8 are equal quality; though I'm not sure that provision exists in FSF's offer)... Will those 7 likely work on other offers? It seems a pretty quick way to burn bridges.

    Oh well, some thoughts anyways. What do you all think?
  • by bgarcia ( 33222 ) on Thursday June 10, 1999 @06:44AM (#1857278) Homepage Journal
    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.


    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...

  • I agree with Graydon's observation about the bounty thing not working. I think it would cause free software developers to compete with each other to the point of hiding information, and that isn't what's gotten free software as far as it is. I also like his idea about setting up a web page with offers and ideas; sounds sort of like those pages where you bid for an airline ticket and agents compete to get you the lowest price, in a way.
    I think the FSF idea about manual-writing is well-intentioned but you're right, it will burn a lot of bridges if multiple people work on it and only one person gets paid. It might be better to decide ahead of time who gets to do it... but then it becomes more like a contractor situation, and FSF becomes a "corporate" sort of entity. Still, in terms of not pissing people off, I think it might be better that way...
  • If 8 people want to write something, they
    should cooperate, collaborate, and share,
    or else what the hell do they think they're
    doing in the free software community?

    The culture where people work in secrecy and
    don't share, is the very problem that the free
    software community is working to avoid.

    If you start working on this project, you should
    make every revision available to the public.
    If you're afraid somebody will steal your (published, copyright) work in progress and
    submit it to the FSF, you probably would be
    happier working on something else...

  • 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.
  • Indeed. This "article" is anything but well thought out. It completely misrepresents the entire mechanism that SourceExchange is using. It makes accusations but doesn't bother to even hint at a justification for the accusation. Its unfortunate that garbage like this gets published on otherwise respectable forums like Slashdot and Freshmeat when it should be, at best, regulated to an alt.* group on UseNet.
  • 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.
  • by purp ( 12986 ) on Thursday June 10, 1999 @06:54AM (#1857285) Homepage
    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.

  • by Q-bert][ ( 21619 ) on Thursday June 10, 1999 @06:51AM (#1857286)
    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).
  • At the end Graydon suggests another model for contracting software that still has the limitation of the split the money effect.

    I can see two possible work around for this.

    1. pay per line of code, this has the disadvantage of code bloat, but if multiple people work on a project each gets compensated for their work in a semi fair manner.
    2. The other method that could be best illistrated by continuing on the "this library is not threadsafe" example would be give a bounty for each api, you get the same effect of people not sharing the work, but in this case the code chunk they would be producing would be so small that sharing would have little advantage. The company would still be able to post a bounty for the whole lib, and bonuses for multiple api's, but those would only endcourage the interested developers to code more.

    both of these options should have the effect of allowing the developers to use peer review, without the penalty of loss of compensation.
  • If the company offering the bounty demanded that

    1. Source code is available to the public at all times during development
    2. The code is offered under the GPL license
    it would encourage developers to cooperate on one solution rather than compete with individual projects.
  • 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'?


  • by Christopher Thomas ( 11717 ) on Thursday June 10, 1999 @06:56AM (#1857291)
    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.

  • I think it would cause free software developers to compete with each other to the point of hiding information, and that isn't what's gotten free software as far as it is.
    But it would only be hidden until the project was complete enough to collect the bounty. At that point, it comes out of hiding and becomes open-source.
    I think the FSF idea about manual-writing is well-intentioned but you're right, it will burn a lot of bridges if multiple people work on it and only one person gets paid.
    Again, I think the idea is to make some sort of agreement ahead of time that you would be the only one (or the only group of people) working on the project, and no other team could simply show up without prior arrangements and take the bounty from under you.

    99 little bugs in the code, 99 bugs in the code,
    fix one bug, compile it again...
  • The whole point of these 'new' (I have no idea how old the oldest is) systems is that they provide a method for buisness to get the features they want.

    One of the bigest gripes that I hear being repeated all over the place is that free software does not have a defined development path.

    I also don't think that these contracts are going to be in the $50-100 range. Try adding a zero to those figures and you are looking at costs comparable to one day of a contracters time - given that this would be a fixed price contract this could represent quite a cost saving.

    Particually as the sucess or not of a project would be judged by a third party - to a student $1000 could easily be worth a week of work to acomplish - and would look great on a CV.

    Now I'm not about to suggest that this sort of sponsered development could become the norm... but it could certainly go a long way to allaying the buisness fears people have about using open source.

    It could also end up funding the lifestyles of people who want to do nothing but develop open source. Essentially I don't see that many differences between the bounty model and contracting.

    Overall I think that the bounty model could do a lot to improve the perception of open source and to promote the culture.

    The only problem I can see is that of bounty steeling - but I'm sure there are ways around that.

    Perhaps the third party could provide certification (in the form of a digital signature) as to who did what work.

  • Did you even read what he said about hiding work before you replied?

    The models being proposed do not pay the first one to complete the work (like a bounty). The sponsor enters into a contract with a developer (before any work is done), and then pays the developer at milestones.

    The source is available to everyone along the way.

  • I agree. However, the Free Software Community always had and always will have a problem with those of its members who are unable to cooperate (except with a small crowd of similar-minded followers) because they would rather insist on their personal opinion than accept that someone else's opinion might be better. Just look at the never-ending Gnome vs. KDE flamewar and all those miserable little projects started because someone thought it would be better to start a new project rather than help improve an existing one.

    This seems to be an attitude problem, not very likely to go away soon, but the bounty schemes might actually help (people should realize soon that cooperation leads to better results, look at efforts such as, GIMPS etc. - why is it obvious there that forming teams is a better idea than going at it alone?).

  • by stowaway ( 53847 ) on Thursday June 10, 1999 @08:31AM (#1857296)
    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" (
  • I think his point was that hiding software negates all the developmental advantages one can gain through sharing information at all stages. "Release early and often" is a tenet of open development models. The project will suffer if it's developed by an individual who can't discuss and share the best techniques because he's afraid to leak secrets.

    I tend to agree with Graydon here, bounty software is encouraging sharing as an end only and not a means to better development.
  • The bounty model is not new. The corporate world has a name for it: consulting. Have something you need done but can't do? Hire someone outside to do the job for you. They do the work, you pay them money, and that's the end of it.

    Instead of contrasting open source with the bounty style, let's look at why the bounty model might be superior to consulting:

    Openness: The contractors have to be very explicit about what they want. They can't vaguely describe the project to lure you in, and then change the specs: it's all up on the webpage. What they ask for is what they'll get.

    Working conditions: No chance of being treated as a slave employee here. They don't even have to know about you until you've finished the coding! You can work how you want, where you want, and when you want, in addition to being able to pick all your own projects.

    Negotiating power: In conventional contracting, your pay is set before you start work -- which, for the coder, is when you are at your negotiating weakest. In the bounty model, you can have the entire product ready before you first approach the customer; which not only means that you have a better idea of the worth of your work, it means that you have the upper hand.

    There are probably other benefits. The point here is that the bounty model is a replacement for contracting, not open source. The niche that contracting fills isn't going to disappear; people are still going to need in-house custom data acquistition software written. While bounty coding may have all the disadvantages described in the essay, conventional contracting has them worse. Why should we be against anything that shifts power towards the hackers?

  • But in general, I would say that the bazaar model would be far more productive (and enjoyable).
    But they aren't mutually exclusive! Don't you see? Every project that starts off as a bounty project is destined to turn into an bazaar project once the bounty is collected!

    The goal of the bounty model is to give some projects a little help getting off the ground, before the bazaar model can be very useful. That's all. It is not a replacement for the bazaar model. Remember, in order for the bazaar model to be effective, usable, testable code must exist first. The bounty model is simply Yet Another Way to get that code to be created.

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

  • Wouldn't there be some difficulty in getting
    the people to maintain and keep improving the
    software/whatever? If you're making something
    because you love it, you'll likely keep improving
    it if it's non-trivial. If you're just cranking
    it out to get some cash, wouldn't it usually be
    a write-once and forget it kind of thing?
  • I wasn't very good at making my point.

    There will most likely be no need to hide the development. If someone wishes to develop a project for which a bounty exists, then he/she goes into an agreement with the company right away, stating that they are now the only person eligible to obtain that bounty. Now, that developer could add people to the group, and agree to split the profits, but otherwise they wouldn't have to worry about losing the bounty to someone else developing the same thing.

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

  • This is how Hoare (the "average slashdot essay writer" in question) characterized his work:

    I've written a small page outlining what I think to be wrong with the new "bounty hunter" open source models, i.e. where the
    developer asks for hackers to code something for a reward. The article is available here.

    I'll omit the obvious comment about your time "spent" in academia ("to [sic] much time").
  • by DonkPunch ( 30957 ) on Thursday June 10, 1999 @07:08AM (#1857308) Homepage Journal
    #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! :)
  • Perhaps what they need to do is offer to pay someone to manage software construction project dedicated to the project, and to write the skeleton code that others could fit their pieces into. They should also host the web site, and offer site management software (CVS, mailing list managers, perhaps other tools, but nothing major.. fancy graphics aren't needed by this kind of site [maybe they could license the discussion software for LinuxToday or SlashDot, those seem to work well!]) This is one of the major hurdles. There would also need to be a bit of low-level advertising/PR to let folk know that the project existed, but not much more than Freebuilder has (still, it *would* require a bit more, as there would probably be less initial interest [otherwise a group would likely have already coalesced]).

    This requires care, and not too much in the way of high expectations. Netscape was, perhaps, a bit unreasonable in what they expected in the way of commitment to a proprietary project and in the way of fast results, although Mozilla seems to be coming to life now.
  • Will introducing the idea of "free-software for money" cause a rush of coders who care more about money than the benefits of free and open source code?

    Other people have pointed out that the desire to collect the bounty may rush some less-than-complete software into production way too early, and that this may increase competition (at the expense of cooperation) for the sake of some money.

    How will this affect software-as-art?

    I have no problem with programmers being paid to work on free software by their employers, and I like that the resulting code is open, but we may be dealing with a shift in the motivation to write software here.

    With the Bazaar model, we have internal motivation as the primary factor. I write free code because I want to try new things, or to solve a particular problem. (There's also the idea of the gift culture which comes into play, and it may be a more external motivation.)

    With the Bounty model, those motivations may be subservient to the desire for cold, hard cash.

    Granted, not everyone may succumb to this. It will be interesting to see if this idea takes off.

    (Perhaps companies should hire successful free programmers as consultants to adapt the programs for specific uses within the companies... doesn't Sendmail, Inc. do this? After all, corporate folks, which would you rather have, a piece of proprietary software and a handful of people who probably could understand it, or a piece of open software and the people who wrote it?)

    QDMerge -- generate documents automatically.
  • I agree with the other comments that said that the 'bounty' model will re-introduce duplication of effort and wasted man-hours into coding as people compete to accomplish the same thing with only one result being accepted. In order for this to work, it must use the cooperative scheme of the OS community... but how?

    I think the solution to this is also an answer to a much older question: how are you gonna judge the relative contribution of each team member to a team effort? how are you gonna do that quantitavely in a manner that will be accepted as fair by all members of the group?

    If you find a solution to that, you could solve a lot of productivity issues in the real world as well ;-)...

    My half-assed stab at a solution would be a point system: first gather a team of people interested in your project. Have the team break the project down into smaller parts and assign 'points' to each part acording to its relative difficulty and importance.

    Then, give percentages of each module's points to team members in proportion with the time they spent on each module. Give also a fixed percentage of a module's points for debugging (say 5%) other people's code ... That way you encourage people to work more, not less, to debug code and --in the process of debugging-- review the entire code tree.

    I dount the end result would be 100% fair, but it will probably be close... and a system like that won't close off the team, leaving the project OS from the start... It's also recursive: if a module is too big, it can be broken down again... I dunno... just brainstorming...

  • That's how things work now, only less organized. Someone starts a project they're interested in. If it's of great importance to a company, they throw money at it. See GNOME (Red Hat), WINE (Corel), etc. Take Alan Cox. I'm sure if he couldn't be writing for the kernel under someone's payroll and had to do something else, he'd probably write something for the kernel anyway, on the side. But he wouldn't be able to write as much. Red Hat (and SuSE, previously?) expedited the process. Having a better kernel is in their interest, so they sponsor him. Having people just suggest topics they're interested in isn't going to work. People can suggest topics that fall through, but every fledgling open-source project serves as proof-of-concept that's needed for this kind of system.
  • 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.

    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.

  • Certainly, it does.

    The process should work like this:

    1. Requestor posts project and bounty
    2. Acceptor contacts requestor and accepts the challenge.
    3. Acceptor develops and releases the software.

    You're ignoring step two. If I accept the requestor's offer, the contract we sign would state that they won't pay someone else for the work if I complete it in the allotted time.
  • An alternative model that might solve some of the problems is this: A company can offer a bounty for a model they need, but the reward will not be given to the programmer(s) but be a donation to a selected-in-advance charity or some such -- anything from Greenpeace to Project Gutenberg.

    It still won't be the inspired or annoyed developer's model, but it will be, very strongly, the community model. No more need for crypto on the CVS tree, since everybody enjoys the result -- and nobody enjoys it personally.

    (And it could lead to Greenpeace hiring open-source hackers...)

  • by Frank Warmerdam ( 18907 ) on Thursday June 10, 1999 @07:21AM (#1857317) Homepage
    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.


    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.

  • by Anonymous Coward
    I figured there would be a few problems with it
    myself, but I came up with different considerations:

    1) Bounties shift focus from doing it right to doing it fast, in order to be the first to submit and get the payoff. In other words, it rewards the quickest solution, not the best, so quality suffers.

    2) Bouties encourage massively redundant efforts.
    (Granted some degree of redundancy is inherent in any open source effort, and redundancy itself is not a bad thing. But at some point having too many people doing exactly the same thing begins to look like it doesn't serve the best interests of the community.)

    3) Judging whether or not submissions meet the requirements for payment of the reward may turn ou t to be more work than actually writing the code, resulting in a net loss of productivity!

    However, I feel that the Open Source community should explore all possible ecomomic models, see what works and what doesn't, then create hybrids that combine the best aspects of each. Sort of a genetic programming model for finding optimum business models...
  • I'm assuming that for projects where collaboration is worthwhile (i.e. large enough projects), greedy individuals or small teams will soon realize that they have the choice between competing with a larger (arguably better because of synergetic effects) development team and joining the team with a good chance to win the bounty, while settling for a smaller chunk of it. This is the same motive that makes people prefer joining a large team for bounty-driven efforts such as and GIMPS, rather than participating alone for the opportunity to win twice the share of the bounty.
  • He suggested:

    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

    and you said:

    I don't believe your forum model would work all that well

    That will be a certainty if it isn't tried.

    In your model, many developers will state what they wish to work on.

    Yes, for example, *I* will.

    Some will go ahead and do it anyhow

    Naturally, but some of them will pull in a sponser midway though the project. Others will be able to justify the effort only if they have a sponser, e.g., your wife might tolerate the project more readily if she knew you were getting paid for it. In other words, some good projects will never happen or never be completed if they're not sponsored.

    Others might simply be blowing hot air.

    Strike "might", write "will". And so? Refine the mechanism by which matches are made between project initiators and project sponsors to deal with this. Design the arrangements so that if nothing happens on the project, only part of the money gets paid.

    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

    And? Don't *you* wade through hundreds of postings on Slashdot to see if there's something interesting/important to you? 95% of the time you only have to read the subject lines.

    Two different systems, bounty hunting and sponsor hunting (a la Christopher Columbus) can both exist in the same world.
  • As with many things, the "right" way to deal with secrecy in a development context is a narrow bridge across a broad chasm, and it's easy to fall off either side. On the one hand, you can be too secretive and there's not enough peer review etc. and you end up producing the wrong thing or crap (which is always the wrong thing). On the other hand, not allowing enough secrecy - which BTW is very closely related to privacy - can be a real problem during the "incubation phase" of a project.

    Here's why I think the "forum" model won't work. Let's say that I want to write the world's greatest cluster/distributed file system - which in fact I do. I can blab about my ideas in public forever and never get anywhere; to attract serious interest, i.e. the kind that will pay my bills, I have to provide a lot more detail than that. Here's the catch: I don't want to provide that kind of detail in a public place. Resentment over who stole/copied what, which is after all merely the flip side of pride in accomplishment, is one of the greatest banes of open-source software development. GNU/Linux, anyone? For me personally, the idea of someone taking credit for my incomparably brilliant ideas is intolerable. ;-) I worry about such misappropriation when dealing with potential employers or investors, bound about with NDAs. There is no way in hell that I'm going to talk about the details to a group of people notorious for their belief that every idea belongs to everybody and their tendency to reward eleventh-hour midgets instead of the innovative giants on whose shoulders those midgets stand.

    [My apologies to those offended by my usage of "midgets" in that metaphor; it predates both me and the spirit of political correctness, and it seemed apt.]
  • In the current system thre are two types of programers (with lots of overlap): hobbiests(who work on projects they like or patch programs they use) and in-house developers(who do what the PHBs ask).

    The advantage of the Free Software Model is not cheap software, nor is it access to freelance programmers. Its GOOD software.

    Under the current, and best, model, companies write programs, and then release them under an open source liscence, which then attracts hobbiests. Hobbiest may, and most do, act as in-house developers during the day, but when they leave they work on what they want.

    This system is advantageous because:

    1. PHBs get to get the programs they need writen and maintained by the in-house folks.

    2. The code is improved/maintained/bug reported by the community.

    So everyone gets what they want: Companies and the community get the programs that work; hobbiests work on programs they want to; and hobbiests get paid when they work as in-house developers during the day(or whatever).

    Why change a system that works? Companies that need program X should hire programmers (even from the community using former work as part of the evaluation process)to write the program and then release the source (under, say, the GPL) and 'reap the whirelwind'.

  • by Anonymous Coward
    Hi. I wrote the page and just wanted to reply to a couple points people have made:

    (1) People complaining that it's not "a good essay". I didn't and wouldn't have called it an essay. I can write essays, and this isn't one. It's just a list of not-too-well organized points. Someone else called it an essay. It's just a web page.

    (2) The sillyness of my suggested alternative model: basically all I'm saying is that the "magic of free software" doesn't come out of nowhere, and bounty organizations aren't going to get it without appealing to a developer's innate sense of quality and coolness. Whether or not there's *any* model which supports this aside from volunteering in your free time is entirely speculation.

    (3) the fact that bounty is almost identical to conventional contracting: this is sorta what I'm getting at. most good programmers already contract, and they do it not by trawling through classified ads.

    (4) the negative tone: I don't mean to poop on free software startups. I've signed up with sourceXchange as a developer too, cause who knows, it might be very cool. I just wanted to express some concern that it might not expand to work terribly well without a little reorientation.

  • >most good programmers already contract

  • There are other problems with that. Suppose not all 8 people put in equal effort (quite likely, even if unintentional). How do you fairly decide who gets paid what?

    In the world of free software where recognition *is* how are you are paid, you might get hurt or offended if some slacker gets more recognition than you, but if you get paid less than some slacker.. that will create some serious problems. (burn bridges)
  • What about the bounty/sponsor ideas takes them outside the realm of (let's say) EBay?

    "Hey, I've got a module writing gig, wanna bid?"

    "Hey, I'm looking for a sponsor for my cool idea, wanna bid?"

    In principle, you can make deals for units of coding effort in an online auction just like you'd make deals for Aunt Hattie's heirloom flowerpot.

    In practice, I can think of a bunch of things that complicate this... some of which SourceXchange et al. are already trying to address.

    What can you think of, and how would you solve it?
  • Technical authoring is not the same as programming, and doesn't obey the same market rules -- for one thing, the copyright system can be seen to work well in that area (relieving, since that is copyright's home ground). Where the bounty system can be useful is not making so much as breaking software -- testing security by offering bounties could be made to work -- but bounty software working is the exception rather then the rule.
  • 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. :-)
  • Your comment doesn't account for greed -- and we are dealing wit Human Beings here.
  • 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.
  • > o If there is a group project, who determines what percentage of the bounty each person gets?

    This would be established by the prime contractor in their agreements with their subcontractors at project startup. If the subcontractors don't feel what they are offered is sufficient they can choose not to participate, or perhaps even try to come up with a proposal of their own.

    > o What if there are disagreements after the project ends about who gets what money?

    Generally the money would be paid by the vendor to the prime contractor who would pay the subcontractors. If there was a disagreement it could be worked out in a court based on the subcontracting agreement. If there was no formal subcontracting agreement (legally speaking) then the subcontractors had better trust their prime.

    > o What if somebody contributes a non trivial amount of work but drops out halfway through because they disagree over some development issue?

    Generally speaking they would be out of the money, but the prime contractor is still on the hook to make the project work.

    These are all common issues for contractors working on multi-person, or multi-corporate projects. In generally project teams will form on the basis of mutual trust based on history, and/or formal (legal) agreements. I do lots of contracts small contracts without any legal agreement in place, on the basis that I trust other people, and that if they screw me it will do more damage to their reputation than it costs me in money.

    There will be disagreements, and at sourceXchange I imagine one of the things a vendor would look at in the different proposals is if they think a project will hang together and complete successfully. Simpler proposals (less parties involved), and project teams with a strong reputation (for doing projects, not just as programming gods) will have an advantage.

    I think that sourceXchange has side stepped some significant potential problems between vendor and project team by introducing the independent reviewer as a tiebreaker in terms of deciding if a project team has met a payment milestone. Furthermore, by indicating that vendors can terminate a contract after a disputed milestone they limit the vendors liability, and hence raise their willingness to try out these contracts.

Nature, to be commanded, must be obeyed. -- Francis Bacon