Pricing ACL
in [Lisp]
|
Prev: Newlisp?
Next: cosx - sinx + 3x2
From: Richard J. Fateman on 14 Dec 2005 14:42 Edi Weitz wrote: > On Wed, 14 Dec 2005 10:02:08 -0800, "Richard J. Fateman" > <fateman(a)eecs.berkeley.edu> wrote: > > >> Or you could hire as permanent employees, Lisp maintainers. >> >> Unfortunately the number of people skilled in something so >> specialized as a relatively sophisticated Lisp implementation may >> be limited, and so the option for someone who really wants to run >> an important program on open-source Lisp seems to be the last of >> these. >> >> Paying $100,000+/year to an employee in order to use a "free" lisp >> may not make business sense. > > > While I agree with many of the things you've said I'd say that this > is a na?ve assessment of the situation. I know of at least one > company which has done exactly this - they hired a (former) > maintainer of an open source compiler. But if they pay him US$ > 100,000 per year that does certainly not mean they're paying this > much for maintenance unless he's patching and improving the compiler > all the time. I agree entirely with your assessment. But it may be necessary to have more than one lisp-implementation guru on the staff-- after all, people go on vacation, or quit. And this in turn means that management must hire, manage, etc such people. I was really thinking the $100,000 would be split among several people, and yes, these people would not be doing lisp fixes full time; they would be "on retainer". Is one month/year enough? I guess that depends, (and again I am agreeing with you!) that he/she may be patching and improving the system. This is not so unlikely. Consider the source-forge Maxima project which appears to be driving "patching and improving" of 3 or more "free" lisps. (SBCL, CLISP, GCL). Depends on how ambitious the application is, and whether the platforms it runs on change (e.g. 32 to 64 bit, Windows NT/2000/XP, etc.) > If he's working full time on the compiler one month per year (which > would be very much IMHO) that'd be around US$ 8,000 and that sounds > like a reasonable price, doesn't it? The rest of the time he'll be > "just" one of their normal developers, albeit maybe a pretty clever > one. > This kind of consideration should factor into a business decision. I was curious as to how the late lamented Macsyma Inc. figured its costs. My understanding is that they maintained their own Lisps, KCL on unix, and CLOE on windows, internally. Would it have been cheaper to use (say) ACL? I suspect their decision was made on the grounds of "techie independence" rather than business sense, but maybe someone reading this knows if Macsyma Inc ever tried to use an "outside" lisp. (Actually Symbolics/Macsyma DID.. before CLOE, they used UCB's Franz Lisp on SUN and VAX hardware. They were very reluctant to do this, I think for several reasons. Primarily because VAX and SUN hardware meant no Symbolics hardware sale. Also, I think they were quite uncomfortable with BSD license and free software. Symbolics, unique among all users of Franz Lisp, negotiated a PAID license fee. Everyone else got it free.) RJF
From: Pascal Bourguignon on 14 Dec 2005 14:56 Richard Fateman <fateman(a)cs.berkeley.edu> writes: > Some government agencies required that none of 3BSD was produced > from "convict labor". Funny :-) But this is right on the point. You have two attitudes here: - one of irresponsability, where you involve lawyers and have providers sign soul-selling contracts preventing them to go on holidays and ensuring that if you have any problem, _they_ will be responsible for it; you buy this irresponsability with a lot of money and freedom. This never prevents your projects to fail miserably, as can be seen everyday in the papers, but at least you're not responsible for the failure, it's others. - one of responsability, where you take the open sources and don't listen to whatever guarantee may or may not be given, just do your job of build new products and services taking full responsibility for all code, which you can because you have the source so you can proove it's what you want or correct it. It takes hard work, and if there's a problem some more work to correct it. And here, if you want to take holidays just pass down the sources, or if you want to earn money, just take the responsibility for it, selling not the free sources, but your responsibility to the irresponsbile rich ones. -- __Pascal Bourguignon__ http://www.informatimago.com/ -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w--- O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++ G e+++ h+ r-- z? ------END GEEK CODE BLOCK------
From: Christophe Rhodes on 14 Dec 2005 14:59 "Richard J. Fateman" <fateman(a)eecs.berkeley.edu> writes: > This is not so unlikely. Consider the source-forge Maxima project > which appears to be driving "patching and improving" of 3 or > more "free" lisps. (SBCL, CLISP, GCL). I don't know where this appearance arises, but for the record, and as best as I can tell, the Sourceforge Maxima project has not driven the patching and improving of SBCL for the equivalent of one full-time day this calendar year, let alone any more. (This does not count work spent on the Maxima project itself.) If you could provide any references to what gave you that impression, that would be interesting, because it is good to correct these misapprehensions at source. For information: there is one outstanding bug in SBCL that I know of reported by a Maxima developer, regarding the behaviour of stdin and stdout when they are not attached to a tty, and for which a workaround was produced in four hours; other than that, of the approximately 2000 messages received by the SBCL development mailing list, none are obviously related to Maxima. Bug reports and patches from Maxima developers and users, and indeed everyone else, are of course very welcome. Christophe
From: Förster vom Silberwald on 15 Dec 2005 04:45 Richard J. Fateman wrote: > As I pointed out to alex, in email to him, I am a stockholder/founder > of Franz, but I don't set pricing policies. I do know that "losing a > little on each sale, but making it up on the volume" doesn't work. I am just curious: did you or your company ever had to take action (by lawsuit) against a potential programmer when he was using ACL and making great profit out of it but never reported it to you. I mean how can you control and watch when a professional programmer relying on ACL happend to report only a tiny fraction of his incomme or own licensing issue to his customers? Schneewittchen
From: Don Geddis on 15 Dec 2005 13:44
> Pisin Bootvong wrote: >> Right, that's why you don't have to be thinking of "Product Y that >> provide all of ACL and sell for less" kind of situation if you put the >> restriction in your EULA. Richard Fateman <fateman(a)cs.berkeley.edu> wrote on Wed, 14 Dec 2005: > I don't understand this. What are you saying? > 1.As long as your product costs more than ACL it is ok to include > all of ACL? (and also pay no royalties to Franz?) Because no one > would buy it instead of ACL? Forget about pricing for a second. You seem to suggest that Franz is forced into their pricing model, because otherwise an OEM might license Allegro CL and then start selling the same thing for cheaper. But that's easy to fix with a license agreement. You don't have to technically cripple the code, or force high prices. Just (via license) prohibit a redistribution that enables the end customer to be a lisp programmer with the product. Take a very simple example. Let's say I want to develop a consumer video game on a PC. Say, a real-time strategy game like Age of Empires. Or a 3D first- person shooter like Quake or Doom. Say I'm trying to decide whether to implement this in C or in Lisp. If Lisp, I may use CLOS, may need a runtime compiler, etc. But the end user will never have a way to even know what language my game was written in, much less be able to use to product in place of Allegro CL to develop new Lisp applications. Say in particular that I'm happy to purchase development licenses for my in-house programmers. But I plan to sell millions of these things to consumers. So my total language cost will be swamped by any fees required of the end delivery. C (or open-source Common Lisps) offer the enormous virtue of the runtime delivery being free. Franz has basically priced itself out of this scenario. With its insistence on participating in the revenue stream of final delivery, Allegro CL really isn't a reasonable alternative for such a project. I'm not going to claim that Franz is making a business mistake. But they are pricing themselves out of a very reasonable development scenario. And don't fool yourself by thinking this is all to protect themselves from someone rebranding their Lisp and competing with them. That fear would be easy to deal with via license terms. Using pricing to "solve" it is a huge hammer that also crushes my hypothetical game developer. -- Don _______________________________________________________________________________ Don Geddis http://don.geddis.org/ don(a)geddis.org Dear Mr. President: There are too many states. Please eliminate three. I am not a crackpot. -- Abraham "Grandpa" Simpson |