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: Cosource.com founders Bernie Thompson and Norm Jacobowitz have posted their responses to Graydon Hoare's Essay on the Problem with Bounty
Software . It is available at the Cosource.com
site.
Re:Scratching Itches (Score:1)
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...
Re: The Problem with Bounty "Essay" (Score:2)
"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.
Re:Wrong on all points, and misses the real proble (Score:1)
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.
Bounty is cool. (Score:1)
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.
The Renaisance Patron Model (Score:1)
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.
LL
Re:Wrong on all points, and misses the real proble (Score:1)
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.
"source futures" as sub-contracting tool (Score:1)
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.
Great discussion... (Score:1)
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.
Brian
p.s. - the first draft of the sXc developer agreement is now online. Comments welcome. [sourcexchange.com].
Re:Wrong on all points, and misses the real proble (Score:1)
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.
Re:Another issue? (Score:1)
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.
Well, yeah, but he's still smokin crack . . (Score:3)
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.
Re:A little Diffrent? (Score:1)
market(ing) (Score:1)
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.
It's not open source. (Score:2)
In the end, you get open source software. That seems an improvement over normal closed development.
The quality may be better or worse, but the market will determine the price, and it will determine the winners and losers. If a company pays to have something developed that already exists out there, they lose. Simple, but not a problem. Companies will probably become more aware of what's out there.
And there's no reason to assume only individuals will bid. I would think, over time, market forces will select for good teams of developers that have a broader suite of skills. The lone "dime-a-dozens" will not be able to compete for coding projects.
And for the final alternative suggestion, it was my understanding cosource.com was going to have both developers and consumers initiate project ideas, which seemed to be the main point of the suggestion.
Counter-counterpoint (Score:2)
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).
--
Let the world sort it out... (Score:1)
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.
Bounties vs. the "rock band" (Score:1)
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.)
BUT... It coud also be a good thing. (Score:1)
Alternative? (Score:1)
The problem really is cultural - propertarian models are fundamentally different from non-propertarian and no amount of window-dressing will change this.
Re:Wrong on all points, and misses the real proble (Score:1)
Re:Just to follow up (Score:1)
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).
Re:An interesting essay.... (Score:1)
I get paid less than certain slackers here in
the corporate world. What's unique here?
An interesting essay.... (Score:1)
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?
Counterpoint (Score:5)
But I'll reproduce it here as well:
Now, I don't believe that the bounty model is going to take the world by storm as the open-source model has, but I do think it'll survive as a niche.
I think there are two flawed assumptions made in this essay:
1) That software developed in this model is only developed in this model.
2) That open-source software must start out that way in order to be of high quality.
Point-by-point:
1: It's Not The Community Model
As Eric Raymond stated in The Cathedral and the Bazaar:
That is, software can start being developed (indeed, must be developed) in some other model before being released into the bazaar. It must first be a runnable, testable program before people will come along and turn their eyes to it.The new bounty model is a model that fits just this first step. The program gets written. After the bounty has been collected, the program is now open source, and has all the benefits that any other open source program has.
2: It's Not The Inspired Developer's Model
3: It's Not The Annoyed Developer's Model
That's right - it's a new model. While we have seen that the Inspired and Annoyed Developer models can work, that does not mean that other models don't work. Many problems in the world are solved by people who need something fixed, but don't have the skills or time needed to do it. So they pay someone else to do it. It's a time-tested model that works.
But again, once the program has been created and released, these Inspired and Annoyed Developer models will start to be applied, as people start to use the program and fix the things that bother them, re-write the things they believe could have been done better, and add functionality that will make the program even more useful.
5: It's Technically Difficult
It's funny that you called this your weakest point, but I actually believe it was your strongest. This model has never been tried before, and the logistics are going to take some time to iron out. It could fail simply because people are too afraid to make changes needed to make use of this new model.
Another Approach
I don't believe your forum model would work all that well. In your model, many developers will state what they wish to work on. Some will go ahead and do it anyhow. Others might simply be blowing hot air. Businesses will not want to wade through the hundreds of postings on such a site to see if anything comes close to matching their needs.
In the bounty model, there are fewer posts, because only a few companies that are seriously interested in seeing a project completed will post projects. Some developers will undoubtedly look through this list, and even though they aren't currently interested in something, might find something that sounds interesting and want to give it a shot.
99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again...
Re:An interesting essay.... (Score:1)
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...
Re:An interesting essay.... (Score:1)
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...
Other forms of corporate support? (Score:2)
Perhaps the best way for corporations to support OS development is to migrate their "intellectual property" to an OS model.
Re:why is it that... (Score:1)
Re:An interesting essay.... (Score:2)
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.
Scratching Itches (Score:3)
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 [sourcexchange.com] and CoSource [cosource.com] have made peer review an integral part of the process -- and a bar that must be cleared before getting paid. I don't think that it would make good business sense for them to lower that bar any further than the project sponsor(s) want it to be set.
Inspired Annoyance
If people were already getting interested, there'd be no need for a bounty; in effect, these companies are saying, "We'll pay more if someone can do something which would benefit us in a timeframe we can accept." This doesn't mean that spare-time hackers like myself will flock to it because it's a paid project -- you might well find that the money convinces someone who was already a bit interested in the project's aims to rearrange their priorities in order to get paid to scratch their itch.
It's Still Open Source!
My final, and strongest, point: no matter what, the end result is open source. If you think the code's sloppy, pitch in and fix it; if there's not enough art in the crafted code, show them what Michaelangelo could have done with a keyboard. You've got the choice...and in the meantime, we've got the code.
I'd probably ramble more, but I've got to go to work. You get the idea.
--j
A little Diffrent? (Score:3)
Modification to the model proposed (Score:1)
I can see two possible work around for this.
both of these options should have the effect of allowing the developers to use peer review, without the penalty of loss of compensation.
Working around the "code hiding" problem (Score:1)
- Source code is available to the public at all times during development
- The code is offered under the GPL license
it would encourage developers to cooperate on one solution rather than compete with individual projects.The single best point -- 'sponsor model' (Score:2)
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'?
--
Potential problems (Score:3)
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.
Re:An interesting essay.... (Score:1)
99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again...
a very weak argument (Score:1)
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.
Tom
Re: The Problem with Bounty "Essay" (Score:1)
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.
Re:An interesting essay.... (Score:1)
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 distributed.net, GIMPS etc. - why is it obvious there that forming teams is a better idea than going at it alone?).
a related idea: "source futures" (Score:3)
Suppose Eliza buys 100 shares at $5 each. Then, she works on the Java3D implementation. This drives up the price. A sponser (say, Sun, or Fred, who wants to use the Java3D stuff) might be willing to buy shares for more than the trading price, say, $20 per share. This raises the price. Submitting bug fixes helps the developers, so users who have invested in a project have an incentive to submit bug reports.
When the testing company, X, downloads the package, installs it, and it finally passes, then C pays 1/10,000 of the total that people paid for that certificate (minus a profit), per share. Suppose that each share pays $15. Then Eliza has made money. Fred has lost money, but hey presto! the software he wanted now exists. So: it seems that there's no need to copy-protect, or even too much need to encrypt the CVS archives. Developers choose their level of commitment by deciding how much stock to buy. (You might say this idea is just "open-source stock options.") Developers who buy 100 shares presumably will have more incentive to work on a project than developers who only buy 10 shares. But developers can choose how hard they want to work on something. Clearly, the testing company, X, has to be trusted to certify the software if and only if it's good enough. Also, the spec has to be clear...not so easy...
Josh "stowaway" (jburdick@gradient.cis.upenn.edu)
Re:An interesting essay.... (Score:1)
I tend to agree with Graydon here, bounty software is encouraging sharing as an end only and not a means to better development.
Bounty model is not new. (Score:1)
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?
Re:Counter-counterpoint (Score:2)
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...
Another issue? (Score:1)
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?
Re:An interesting essay.... (Score:1)
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...
Re:why is it that... (Score:1)
I'll omit the obvious comment about your time "spent" in academia ("to [sic] much time").
You know (Score:3)
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!
Re:Counterpoint (Score:1)
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.
I'm Not Sure What To Think (Score:1)
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.
A point system perhaps? (Score:1)
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
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...
Re:The single best point -- 'sponsor model' (Score:2)
Counter-Counterpoint (Score:2)
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.
Re:Who gets the bounty? (Score:1)
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.
Re: (Score:1)
Flawed Points (Score:3)
I think that Graydon raises some issues; however, I think most of them are addressed by sourceXchange.
Code Hiding:
Once a project has been assigned to a project team there is no reason to hide code. I do think that bounties based on the ``present us a working solution, and then we will pay'' with no continuing arrangements isn't going to go anywhere for the various reasons given.
Thus I would claim that bounty software (ala sourceXchange) can be developed in a community manner. However, you may encounter the situation where people don't feel like helping if they aren't getting paid since they figure the guy getting paid should do all the work.
Sullen/Bored:
Graydon suggests that developers doing bounty projects will be sullen and bored because they don't really want to be doing the project they are working on. I see the bounty system as a way of getting funding for projects in people's areas of interest. If you don't like what you will be doing, don't go for the contract. Generally I don't think the bounties will be lucrative, but rather will give a moderate level of income while working on a desirable project.
Technically Difficult:
I agree, but I think that sourceXchange has come up with some excellent techniques to deal with these problems. It remains to be seen how well they will work, but they can. Of course, they won't work for little fixes.
Another Approach:
I do agree that a mechanism for proposing projects that developers want to do could have value. I am not sure how it could be best handled though. Generally this works best for people well enough connected and known within an industry that they can present unsolicited proposals to a bunch of vendors that might be willing to back the project.
At one point Graydon talks about how the companies funding such project could then market the product and make their money back. I think this is a flawed view of why companies will fund such work. I think it will usually be to fill a gap in a larger product (for instance improved web server software for company that fundamentally sells web server hardware, or a library for translating different file formats). While the work should help the vendor --- usually by avoiding the cost of developing the software themselves when it is not a key piece of IP, I don't imagine these things will often be marketted by themselves.
In closing:
I mostly do projects within a narrow industry (geomatics data translation) that could fall under the bounty system. Most of the issues are the same as those Graydon points out, and yet I do fine. I think I (and others with less connections) could do better if there was an easier way of identifying projects that people want done.
I wish sourceXchange well.
Other considerations (Score:1)
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...
Re:Who gets the bounty? (Score:1)
Re:Counterpoint (Score:2)
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.
Hiding ideas (Score:1)
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.
[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.]
A Good System (also: THE CURRENT ONE) (Score:1)
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'.
Just to follow up (Score:1)
(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.
-graydon
Re:Just to follow up (Score:1)
Baloney.
Re:An interesting essay.... (Score:1)
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)
Why not just auction it? (Score:1)
"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?
In a nutshell (Score:1)
Wrong on all points, and misses the real problem (Score:2)
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.
Who gets the bounty? (Score:1)
99.999% (Score:2)
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.
Re:Too many headches (Score:1)
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.