From kragen@dnaco.net Mon Sep 28 13:52:05 1998 Date: Mon, 28 Sep 1998 13:52:04 -0400 (EDT) From: Kragen To: Frank Hecker cc: Kragen , fsb@crynwr.com, schneier@counterpane.com Subject: Re: Free Software Bazaar In-Reply-To: <360FA8C1.3FB9D9AD@netscape.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: On Mon, 28 Sep 1998, Frank Hecker wrote: > One of the main ideas of the paper is using a strategy of delaying > release of a product until a predetermined amount of money has been > contributed to the creator. One of the main areas that the paper > proposes the use of cryptography is in guaranteeing to customers that > there is in fact a product in the first place, and that the product as > released is the same product they paid for. (This is done basically by > taking a hash of the product's bits and releasing that at the time > contributions are solicited.) This struck me as kind of a strange idea. You have to rely on the reputation of the author or the publisher to guarantee that (a) there really is a product and (b) they will release it when they say they will (after all, if they renege on the deal, you can't decrypt your hash), and also (c) that it's any good. So if you already trust the publisher to deliver on their deal and to deliver something of good quality, what does the hash buy you? > This would seem a reasonable thing to do for works like books and > movies, which are typically released for the first time as fully > finished products. However it just seems strange to delay release of > software in this way, because you lose a period of time during which > other people could be helping the creator improve that software (e.g., > by finding bugs, helping to fix them, and so on). Well, I think the idea was that, if you thought you would derive value from the software, you would be willing to pay to get it as soon as possible -- just as you would if you were buying proprietary software. The only place where Schneier mentions using it for software, he suggests using it rather differently, though -- he suggests collecting up-front money to pay for the development process. This has some potential voting-paradox problems (Why bother to vote? It costs you an hour and doesn't affect the outcome of the election unless it's one vote away from being a tie) -- people are likely to contribute $100 toward a $1,000 project, because they will have a significant effect on its completion, but if the project is a $1,000,000 project, it's unlikely that $100 will make any significant difference. This could be minimized by making the development as granular as possible -- for example, $2,000 for a week of full-time development effort, which is estimated to fix bug-IDs 11277, 12112, 15225, and 4344 (but no guarantees). I wonder if this method could solve the problems the ISC is having? (Is Paul Vixie on the list? He probably should be -- he's trying to find a new business model for the ISC.) Kragen -- Kragen Sitaker The sages do not believe that making no mistakes is a blessing. They believe, rather, that the great virtue of man lies in his ability to correct his mistakes and continually make a new man of himself. -- Wang Yang-Ming