Please create an account to participate in the Slashdot moderation system


Forgot your password?
The Almighty Buck

Bounties for free software 73

Gerg sent us a quick blurb from which says ``In an attempt to jump-start XSL development, Sun Microsystems and Adobe are putting up $90,000 in bounties for independent developers who come up with specific XSL implementations'' Interesting implications. Is this the future of software development? This actually is one of the more common questions that people ask me about. Would a bounty system for software really work? Would it make the suits and the hackers happy? I don't have an answer.
This discussion has been archived. No new comments can be posted.

Bounties for free software

Comments Filter:
  • by Anonymous Coward
    Then you have to:

    * Pay health insurance

    * Withhold taxes

    * Pay other benefits and overtime

    * Manage the programmer

    The salary is a tiny chunk of what it costs a company to maintain a single employee. Far easier just to pay a bounty and avoid the administrative costs.
  • by Anonymous Coward
    : Why not just HIRE someone to write it, jeezz.

    I guess you don't work in the business world.
    Now $90k might seem like a lot to you, but trust me, it far cheaper than hiring people to do it.

    You have bloaty overhead rates, benefits, management costs, and a hard time finding GOOD sw engineers in the valley. And don't forget projects have a real tendency to over run their schedule.

    Only $90k for a completed project like this without the risk of failure is a bargain in the Valley I live in.

    What are the ramifications of this?

    * Companies can be more profitable.

    * Move the software development overseas to places like India where the wages are low and the skill is high. My Indian friends say India has a management infrastructure problem and the government is hostile to foreign business but that can change.

    * The wanna-be engineers in the valley (i.e. talently deficient) could be in for a world of hurt. Who am I kidding, as long as the Valley is still hot and management is still craving bodies to throw into the open fire, even the most lacking engineer can find a job.

    - erik olson
  • This fits right into the "new IT market paradigm," which is results oriented, rather than process oriented. Linux, *BSD, etc. are showing folks that the elusive productivity gain, until recently only a Microsoft.Myth, is possible. Adobe, et al are beginning to realize that paying for results is much more cost-effective than paying for process.

    The comments about "bountyware" bypassing all the hassles that come with employment makes me think that the gubmints must be getting a little nervous about this. They could stand to lose a lot of money and power if this concept succeeds (I think it will).

    I envy the younger geeks who are just getting involved--the software industry is finally getting its act together and I'll be dead or hopelessly senile in thirty years. Damn. At least if I'm only senile I'll be able to go to work for Microsoft. I wonder if they allow employees to wear polyester and carry drool cups?
  • Bounty is something that one can specificaly work for and somehow rely on being paid. But then the announcement should be made in public, in some clear way, so developers should be able to tell, what they actually should do to win one, and what can be expected.

    Grant is something that is paid for some purpose in the expectation that something will be developed, but then it should be paid in advance. It's not a bad way to fund Open Source, and government and companies do it all the time. The down side is that competition for grants is often complex, bureaucracy-dependent and has little to do with the merit of the work done on grants.

    Prize is something that is paid after the work, and prize awarding rules rarely are specific enough to leave any hope for developer that he can rely on a prize -- relying on even high announced prize will be like asking bank for a loan because he is working on a research for what he can win a Nobel Prize.

    In this case the announcement is for a prize, not bounty or grant, so "financial incentive" mentioned in the article doesn't exist.

  • If they were to take that 90K and hire one person, that one person may fail. If, instead, they wave the same 90K in front of the noses of the world's programmers, you may get several programmers to compete for the prize, perhaps increasing the odds of success.
  • by mholve ( 1101 )
    This, from a company that hasn't updated Photoshop for UNIX since... 3.0! WTF? Piss off. I'll use the GIMP, thanks.

  • Don't demonize money. Money is just a physical representation of "effort." I do work and trade it for something.

    Just to get totally off analogy: Don't demonize Windows95. It's just a representation of commands I wish to give to the computer.

    The point isn't that labour for reward is bad (at least *my* point isn't), I just think the implementation (ie the money system) is bad.

    By deomonizing money, you're deomonizing someone who is doing work.

    Not any more than demonizing win95 is demonizing someone for using a computer. There is always the possiblity of using another [operating] system.

    Not that /. is the appropriate place for this discussion, but if "irregardless" can spawn 20 replies when talking about SMP, then why not :-)



  • A bit of clarification. There are two parts to XSL; some people consider it to actually be two different languages.

    The first part specifies transformations from XML to something else (e.g., HTML, PDF, PostScript). This is the part that you seem to be referring to, though it's actually more general than what you describe, since the resulting document doesn't have to be HTML or HTML-like.

    The second part is essentially a formatting language, like CSS. You can then use the XSL transformation language to process an XML document and spit out a set of XSL formatting elements.

  • Perhaps so, but at the worst we'll have a mediochre but working XSL implementation in Mozilla that can then be improved by self-motivated hackers. It would have happened eventually, to be sure, but it certainly doesn't hurt the effort to have money going into it.

  • The main rational for bounty hunters for capturing fugitives was so they could hire people on
    consignment. This is no different than having your boss say to you: if you don't get this done
    on time, I won't pay you for your time. The only reason you would stick around is if you thought
    you could do it or you were stupid.

    Also following this analogy, a bounty hunter doesn't have to keep the fugitive in a jail cell
    and feed it for the next 30 years. Similarly, a bounty coder wouldn't need to support it.

    Bounty hunters are opportunists, I would expect the same for bounty coders.

    Probably not the best way to get code written, but to get bug reports or copies of viruses
    this is probably a win.

    Note there is a big flaw in this analogy. A bounty hunter knows that if he/she has the fugitive,
    nobody else will get the bounty. Anybody and their grandmother can write code and beat you
    to the punch.
  • One of the problems I see with a bounty approach is that the bounty will only be paid to the person/people who 'win'. Everyone else who worked on that project will be completely unpaid. They will have no particular motive to murge their own effort in with the winning code, even if their code is technically superior. There may even be a disincentive if they are bitter they didn't 'win'.

    If a bounty system is to work, it probably needs a registration system of some sort, so everyone knows who is already working on the project and how long they have been working on it. This way, if there are already a few people working on a project, new people will know that they would be at a disadvantage if they started now, and perhaps they would be better off picking a different project.

  • From the bouty-offerer's point of view it seems a smart thing to do: they hopefully get a lot of people to code on it for a quick implementation. But one of the advantages of open source software over proprietary software has been that there is no real pressure on the author, therefore he/she has all the opportunity to set stability/performance/elegance before fancy looks and speed-of-delivery. These bounties might endanger that.
  • I seem to recall a similar deal being offered by some company (SCO?) for anybody who reverse-engineers the protocol used by Windows Terminal Server. Does anybody else remember the details on that?
  • Adobe isn't Sun. Sun came up with java. Adobe thinks it's an important tool
  • I'd sure love to see mozilla with XSL no matter how it gets in there. Last I heard, they just plugged expat (xml parser) in mozilla
  • I think everyone should relax a little, you guys are all way too serious. When this sort of thing becomes commonplace, then start whining and complaining about it, until then, why don't we just see how it goes and if you want to, take part in it, and if you don't, don't.
  • > Why not just HIRE someone to write it, jeezz..

    By offering a bounty, they don't have to screen programmers, hire programmers, or reject programmers. Instead, people who are interested in the project, the money, or both, can freely work on it. Sun and Adobe do not have to pay every programmer (or group) working on this project, just the winners (and runner-up for the Adobe offer).

  • You will also see the exact opposite of open source happen. In order to successfully beat another team to the finish, people will hoard code. Not just for that one project, they will hoard their entire code base so that no other team will have the advantage of their tool set.
    Presumably a condition for winning the bounty is to release the source code as open source, at least for the project in question. You're right that there would be unreleased tools used by each team, and there would be an incentive to hoard them from other teams. But still, paying bounties for open source is a step (however incomplete) in a good direction.
    There's a different, but related issue as far as hoarding: As an AC pointed out, the bounty scheme would move people back from the bazaar into a cathedral. The benefit of OSS is bazaar development, in which you share your code around, and people contribute bug-fixes-- even while development is still in progress. But if you're developing for a bounty, you're not going to let anyone see the code until it's fully developed, lest they run with it and get the bounty with your work.

    What you end up with is cathedral-style development followed by bazaar-style distribution. First releases will be as buggy as any commercialware. But even the bazaared distribution isn't going to work here-- who's going to contribute bug fixes on a bountied software when they could be working toward new bounties? So not only does the initial release suffer, but post-release improvements suffer as well.

    Bounties may have some benefits, but they really miss most of the advantages of OSS.

  • This charade limits the quality of work (no peer review) and the benifits for workers (no jobs). A more interesting model based on the bounty system is instead of the bounty going personally to you, the money is donated to a preset charity. With this model there is peer review (no incentive to hide code). This might incourage more people to work for free software, thinking that they are helping two things at once.
    Four years in jail
    No Trial, No Bail
    *** FREE KEVIN *** []
  • The ransomware idea is an interesting one. On that page, you ask the question:
    Can I announce how close the total is to the ransom, or would nobody pay knowing the source will be released soon?
    Here's a thought. As you get closer to reaching the total, gradually lower your price. If you knew the volume-demand curve exactly, you could plan specific dates for stepping down the price, but that won't happen.

    Maybe you'll want to schedule price reductions based on when you hit certain fractions of the total. You'd probably still want at least a rough guess of the volume-demand curve for your software, and you'd want to run some simulations. But the periodic price reductions would probably come to be regarded as an indication of your good faith that you really will release the source code later on.

    A simplistic approach, assuming you're developing something over a long time, and catering to a market that is eager for the latest version, would be to open-source old versions based on a constant time delay (maybe six or twelve months). This would be a little like a time-compressed version of the patent system.

  • The fear of coming in second many times in a row will keep people out of the market ... there will always be a full-time bounty hunter that will finish the project well before them.
    This is definitely a weakness of the bounty scheme. Maybe a good arrangement would be to split a prize evenly among all the teams that finish the job within a predetermined time window. This might water down the prize enough to discourage greedy shark-like personalities who would choose to be full-time bounty hunters.
    You will also see the exact opposite of open source happen. In order to successfully beat another team to the finish,
    people will hoard code. Not just for that one project, they will hoard their entire code base so that no other team will have the advantage of their tool set.
    Presumably a condition for winning the bounty is to release the source code as open source, at least for the project in question. You're right that there would be unreleased tools used by each team, and there would be an incentive to hoard them from other teams. But still, paying bounties for open source is a step (however incomplete) in a good direction.

    Maybe if people feel strongly about these toolsets, they can put up bounties for their release as well. In any event, I don't think the world will ever conform to anybody's ideas of how things ought to be, not mine nor yours nor RMS's. You can argue persuasively, you can explain your reasoning, and you can set a good example, but you can't really control what people do.

    Can you propose an alternative to bounties, where all parties do at least as well as they do with bounties, and programmers and teams don't have an incentive to hoard tools? Nothing springs to my mind, but any such scheme would be a vast boon to OSS.

  • you guys are all way too serious.
    Yeah, but this is an interesting development. There's a serious paucity of really feasible plans to make money for developing open source software. The reasons for favoring open source software depend largely on principles, and human beings almost inevitably translate principles as morality, and then get emotional about them. Regrettable, but the level of emotion at least keeps people engaged with the question.

    (It would be nice if people could be as dispassionate about OSS principles as they are about, say, the principles of thermodynamics, like this: Yes, this is how things work, and therefore these are the actions we need to take to get what we want, and we need to know all that and act consistently with it, but we don't need to lose sleep over it.)

    There are some really wonderful posts here. People are really thinking about what would happen if this became a widely-used way to finance OSS development. That's cool.

    Ultimately, this being a free country, you can't control what people do (except the very crude control offered by the legal/penal system). The best thing is to argue eloquently for the ideas you think are best. People are using this as a forum to practice doing that.

  • Once you hire people, there's insurance, a building to house them (factory), cost of overhead (such as lighting, etc). It's just much more profitable to outsource it out. A virtual CorpGov LLC with no inventory, buildings, employees and nothing but profit$.
    It could work out the same for independent consultants too. No CorpGov LLC commute, no office politics, no staying 12 hours when you got done with the project in 8hrs. An actual life just might be yours, community, family and friends! Oh my.
  • Well, gnome is just a tremendously complex idea. They seem to have done a good job at implementing things so far. And their progress at fixing bugs seemed to be pretty good last I checked. Of course, i can't run gnome right now because it crashes my X server. I can't wait until I get my G200, hopefully the X server is better, and if not, I'm going to start participating in development.

    On the E side of things, E has been perfectly stable for me for the last four months, and all but perfectly stable for the last year or so. I've almost never seen E crash, and I go back to the late 13.3 days. The only times I remember it crashed, it put upa window saying that it crashed, with an option to restart. If I selected restart, E restarted, and all my apps stayed up. Why do people always pick on E? it's extremely fast, with a small theme, it's pretty small, it looks great, and has tremendous flexibility to do things the way that I want them to be done (where I is the generic I).
  • This is perfect! Now stay at home coders can work on the projects they want to work on, and the companies will pick the best piece.

    The only question is will other companies buy this? I certainly hope so.
  • Heh.. i'll buy THAT for a dollar. :)

  • Besides, what happens if a bunch of people get together and write one, but theirs isn't the first? They have a better implementation sitting there and they don't get paid for it? They would probably subsequently GPL it or something, so just letting all parties work together would be best in the first place. I agree that bounties could be good for small projects, but contracting out would probably work better in the long run and just using free software (and writing free software) would have the best outcome overall.
  • It seems to me that a system where a software contributor would get payed a royalty based on some measure of their contribution to the project (such as lines of code, for example) might be better than a winner-take-all bounty. This would encourage using the best portions of code from many different sources in much the same way that existing free open source projects work. This way programmers would remain independent and source would remain open but the contributors would ultimately get paid when the organizing entity sells the final product.
  • Two problems with the bounty system: risk and benefits. Programmers face too much risk and get no fringe benefits.

    How about a modified bounty system: pay a large pool of remote programmers a "reasonable" base salary (it might be quite small if a programmer can sign up with more than one company) plus a bounty for achieving some programming goal. The problem is benefits. No one company will wish to pay a programmer's benefits because it would prefer to free ride on the rest. In this sense the benefits are a public good. How about a programmer's collective/cooperative to provide benefits to the group? Each member pays in (they would be willing to do so in order to share the risk of not winning a bounty), plus a small payment from each participating business.
  • I have to agree - Enlightenment is the fastest (depending on how many pixmaps you have it load keyword 'versatile') most stable, and again most versatile window manager I've come across - It's also staggeringly beautiful, and completely gnome-aware, they both compliment each other nicely, although a few gnome issues need to be fixed before it's perfect, but I really can't say enough 'bout E. there.
  • The second part of the Sun/Adobe prize is for an XSL formatting object to PDF formatter written in Java.

    Six months ago I started writing what I still believe to be the only XSL formatting object formatter around and I happened to output as PDF and write in Java.

    Due largely to lack of time, I haven't done much in the last few months. I would have accepted $5000 to finish it!

    I'm going to try and finish it now.

    see [] as well as [] for XSL-related software in general.


Machines that have broken down will work perfectly when the repairman arrives.