From: ·········@gmail.com
Subject: Pricing ACL
Date: 
Message-ID: <1134509894.511643.196410@g43g2000cwa.googlegroups.com>
I wrote this as an email reply to R. Fateman, but I now feel like
posting it. (BTW, Richard, you probably meant to post your message in
the first place):


All I can say is that "we will ask you for a %-age of your future
profit once you have your product ready for shipping" is a total deal
breaker.

I don't want to hire lawyers NOW to negotate with Franz when I'm just
developing the product, and I don't want to get f*** (pardon my french)
by Franz if I delay the negotiations until later. Score 1 for other
alternatives.

If I'm being unclear, image this situation: I'm Franz. You have naively
developed a product using ACL, Allegro Cache, and other things that
only I (Franz) can provide.
You have two choices: pay whatever I ask you, or abandon the product
(major rewrite included). As a business, I (Franz) will be inclined to
ask you for just a little less than the cost of a major rewrite.

Now if you are smart, you'll never get into this situation by either
(1) Never using Franz (LW, CMUCL) or (2) negotating the distribution
terms in advance (laywers, etc.). For most people (1) seems like a
better alternative.

From: Jon Boone
Subject: Re: Pricing ACL
Date: 
Message-ID: <m364pspt2h.fsf@amicus.delamancha.org>
·········@gmail.com writes:

> All I can say is that "we will ask you for a %-age of your future
> profit once you have your product ready for shipping" is a total
> deal breaker.

    I can understand why you would be put off by this type of
  situation.  I can see, however, how this might not be a terrible
  situation for either Franz or the entity using Franz's intellectual
  property. 

    At the early stage of development, you may have very different
  ideas as to the profitability of the product you're producing than
  you have once it's nearing shipment.  In fact, that should be the
  normal course of events:

   * At the early stages, you have a rough idea about the product,
     target market segment, potential price points, etc.
     
   * As you near the point of shipment, these ideas will be less
     theoretical and based on more accurate assessments that have been
     completed in the mean time (market surveys, assessment of the
     competition, etc.)

   * Consequently, you will likely either value the product more than
     at the early stages (because you judge your chance of success as
     higher) or you will value it less (because you judge your chance
     of success as lower).

    This type of situation would be terribly beneficial if you could
  avoid putting *any* capital up front into obtaining the Franz
  intellectual property.  They would, in essense, be subsidizing your
  development process, while helping to ensure that products that
  actually ship using their intellectual property are more likley to
  be successful.

    As it stands, since you have to put some capital in up front, the
  value prospect changes based on the idea that the intellectual
  property is worth more than the up front charges.  Each entities
  judgement of this implication will likely vary.

--jon
From: Richard J. Fateman
Subject: Re: Pricing ACL
Date: 
Message-ID: <439F6DBF.4080206@eecs.berkeley.edu>
·········@gmail.com wrote:
> I wrote this as an email reply to R. Fateman, but I now feel like
> posting it. (BTW, Richard, you probably meant to post your message in
> the first place):
No, I didn't :)  But since you responded here...

> 
> 
> All I can say is that "we will ask you for a %-age of your future
> profit once you have your product ready for shipping" is a total deal
> breaker.

That could be the case.  But then here's another potential deal
breaker:  you try to sell your product to a business. The business says

"does this come with support?" You say "no, I was planning on taking
a vacation to Tahiti. If you have problems with the underlying Lisp,
  just post your questions or bug reports on some newsgroup. Or you
could hire some bipolar Lisp hacker. Just check on comp.lang.lisp."

the business says "You wrote this code -- there are no questions about
whether it maybe contains code that is copyrighted by ATT, Microsoft,
Adobe, etc, and you will sign this contract to that effect.?"  You say
"What the hey, this code comes from [whatever, GPL, LGPL, BSD, ...] open
source licensed.  I can't say who wrote it!"

the business says, "Oh, about that Tahiti trip, who's your maintenance
person on 24-hour call."  you say "Hey man, does a blackberry work in
Tahiti?"

vs.

"A professional software company with a staff of experienced
programmers,  18 years in the business, is maintaining the lisp system."
or maybe even
"I have partnered with them and the key contact at Franz to answer
questions is X; if he is not there, someone else will pick it up."

So now maybe you take a vacation in Atlantic City instead of Tahiti.


> 
> I don't want to hire lawyers NOW to negotate with Franz when I'm just
> developing the product, and I don't want to get f*** (pardon my french)
> by Franz if I delay the negotiations until later. Score 1 for other
> alternatives.

Seems to me that if you take a program that Franz sells for $X,  make a
trivial addition to it, and then sell it for $Y  where Y<X, then Franz
should have an interest in that...  To the extent that a recipient of
your program can (by ignoring your contribution) have a complete version 
of Allegro, isn't there a real problem?  Now I haven't been following 
all this stuff (like Reddit), but has someone come up with a rational 
pricing strategy?  (In my email to alex, I think I commented that I 
doubted the market for lisp was very  elastic -- elastic means if you 
drop the price by 1/2, you'll get twice the sales or more, and thus more 
revenue.  My suspicion is that if you drop the price by 1/2 you'll get 
about the same number of sales, and lose revenue.  This is presumably 
what marketing droids take polls about and maybe know about.)
> 
> If I'm being unclear, image this situation: I'm Franz. You have naively
> developed a product using ACL, Allegro Cache, and other things that
> only I (Franz) can provide.
> You have two choices: pay whatever I ask you, or abandon the product
> (major rewrite included). As a business, I (Franz) will be inclined to
> ask you for just a little less than the cost of a major rewrite. 

Franz could certainly not ask you for more than a full license fee per
recipient, so that is an upper bound.  And if your application included
full resources so the recipient could use your "product" instead of
buying ACL+Allegro Cache directly from Franz, there does seem to be that
problem! Your customer might even be in a situation of selling Lisp
in competition with Franz and for that matter, selling your product in
competition with you. How would you like that?
> 
> Now if you are smart, you'll never get into this situation by either
> (1) Never using Franz (LW, CMUCL) or (2) negotating the distribution
> terms in advance (laywers, etc.).

It seems to me that setting up a situation that limits Franz's exposure
and your exposure to someone ripping them or you off, is not a bad
idea.  I do not know that lawyers are needed to negotiate this. If Franz 
wants you to pay some fee for each copy of their lisp that you send to 
someone else, it seems like a business cost, just like (say) rent.
[I assume that if you ship a lisp that is substantially "disabled" e.g. 
without a compiler, without eval, without various tools, then this could 
be relevant.]
What is to prevent your landlord raising your rent to be "just slightly 
less than your cost of moving"?

  For most people (1) seems like a
> better alternative.

That may be because they are not examining the total cost of ownership 
and sales of software. What is supposed to be "free" may in reality 
require substantial investment. (For example, in tech people, and legal 
fees.  Most free software comes without warranty, and so if someone like 
SCO comes and sues you because you are using their code, it's your 
problem, not the "vendor". And you have to hire a lawyer even if you
are innocent of wrongdoing.)

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.


RJF





> 
From: Pisin Bootvong
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134533686.460000.256370@g44g2000cwa.googlegroups.com>
Richard J. Fateman wrote:
> ·········@gmail.com wrote:
> > I wrote this as an email reply to R. Fateman, but I now feel like
> > posting it. (BTW, Richard, you probably meant to post your message in
> > the first place):
> No, I didn't :)  But since you responded here...
>
> >
> >
> > All I can say is that "we will ask you for a %-age of your future
> > profit once you have your product ready for shipping" is a total deal
> > breaker.
>
> That could be the case.  But then here's another potential deal
> breaker:  you try to sell your product to a business. The business says
>
> "does this come with support?" You say "no, I was planning on taking
> a vacation to Tahiti. If you have problems with the underlying Lisp,
>   just post your questions or bug reports on some newsgroup. Or you
> could hire some bipolar Lisp hacker. Just check on comp.lang.lisp."
>

How many time does the problem of an application comes from Underlying
Lisp rather than the application's own logic.

> the business says "You wrote this code -- there are no questions about
> whether it maybe contains code that is copyrighted by ATT, Microsoft,
> Adobe, etc, and you will sign this contract to that effect.?"  You say
> "What the hey, this code comes from [whatever, GPL, LGPL, BSD, ...] open
> source licensed.  I can't say who wrote it!"
>

And I can be sure Franz did not violate any of them because I never see
their source code, right?
And nobody that uses Franz in commercial also use CL-PPCRE, CL-PDF,
SLIME? And if you use Franz with those BSD/GPL licensed library then
you don't have to be worried?

> the business says, "Oh, about that Tahiti trip, who's your maintenance
> person on 24-hour call."  you say "Hey man, does a blackberry work in
> Tahiti?"
>

This is quite nonsense. Your client never know, when a problem comes,
whether it is your application's problem or the underlying Lisp's
problem. So if a customer have a problem with a product (Your product
X, not ACL or any Lisp) and cannot contact the you because you went to
Tahiti, that is not a problem of using open-source Lisp, it is a
problem of choosing the wrong shop. Are you saying that if reddit use
ACL then the developer can go to Tahiti, not taking any call, and Franz
will support any reddit issue for them?

> vs.
>
> "A professional software company with a staff of experienced
> programmers,  18 years in the business, is maintaining the lisp system."
> or maybe even
> "I have partnered with them and the key contact at Franz to answer
> questions is X; if he is not there, someone else will pick it up."
>
> So now maybe you take a vacation in Atlantic City instead of Tahiti.
>
>
> >
> > I don't want to hire lawyers NOW to negotate with Franz when I'm just
> > developing the product, and I don't want to get f*** (pardon my french)
> > by Franz if I delay the negotiations until later. Score 1 for other
> > alternatives.
>
> Seems to me that if you take a program that Franz sells for $X,  make a
> trivial addition to it, and then sell it for $Y  where Y<X, then Franz
> should have an interest in that...  To the extent that a recipient of
> your program can (by ignoring your contribution) have a complete version
> of Allegro, isn't there a real problem?

I thought ACL have something like EXE maker. And that it shakes the
image and unused function from the distributed image. I never know that
when ACL build a distributed EXE, it includes all the IDE inside.

I thought that if I bought MSVC++ and sell a product call
"start-up-vc.bat" which does nothing but start MSVC. And if I sells it
for 1$ and distributed MSVC++ with them, I can still get sued from MS.
And yet MS didn't charge MSVC per distributed app.

To some extent, you are implying that any language that have "eval"
should be licensed per package sold. As a matter of fact, if a
interpreter can be written in a language such language implementation
should be licensed per package sold, too. Right?

If you are afraid of your customer cheat in such a way, why not put it
in EULA? Get a lawyer to indicate what it means to sell product that,
in some way, allow one to use devlopment features of ACL. And indicate
that only such product require per-package distribution fees (well,
disregarding those Allegro special feature that should reasonably be
charged per package if used, like AllegroCache).
You don't have to be afraid that they won't follow the EULA, since if
they are not willing to, I think they willl cheat in all other ways
anyway.

>  Now I haven't been following
> all this stuff (like Reddit), but has someone come up with a rational
> pricing strategy?  (In my email to alex, I think I commented that I
> doubted the market for lisp was very  elastic -- elastic means if you
> drop the price by 1/2, you'll get twice the sales or more, and thus more
> revenue.  My suspicion is that if you drop the price by 1/2 you'll get
> about the same number of sales, and lose revenue.  This is presumably
> what marketing droids take polls about and maybe know about.)
> >


> > If I'm being unclear, image this situation: I'm Franz. You have naively
> > developed a product using ACL, Allegro Cache, and other things that
> > only I (Franz) can provide.
> > You have two choices: pay whatever I ask you, or abandon the product
> > (major rewrite included). As a business, I (Franz) will be inclined to
> > ask you for just a little less than the cost of a major rewrite.
>
> Franz could certainly not ask you for more than a full license fee per
> recipient, so that is an upper bound.  And if your application included
> full resources so the recipient could use your "product" instead of
> buying ACL+Allegro Cache directly from Franz, there does seem to be that
> problem! Your customer might even be in a situation of selling Lisp
> in competition with Franz and for that matter, selling your product in
> competition with you. How would you like that?
> >
> > Now if you are smart, you'll never get into this situation by either
> > (1) Never using Franz (LW, CMUCL) or (2) negotating the distribution
> > terms in advance (laywers, etc.).
>
> It seems to me that setting up a situation that limits Franz's exposure
> and your exposure to someone ripping them or you off, is not a bad
> idea.  I do not know that lawyers are needed to negotiate this. If Franz
> wants you to pay some fee for each copy of their lisp that you send to
> someone else, it seems like a business cost, just like (say) rent.
> [I assume that if you ship a lisp that is substantially "disabled" e.g.
> without a compiler, without eval, without various tools, then this could
> be relevant.]
> What is to prevent your landlord raising your rent to be "just slightly
> less than your cost of moving"?
>
>   For most people (1) seems like a
> > better alternative.
>
> That may be because they are not examining the total cost of ownership
> and sales of software. What is supposed to be "free" may in reality
> require substantial investment. (For example, in tech people, and legal
> fees.  Most free software comes without warranty, and so if someone like
> SCO comes and sues you because you are using their code, it's your
> problem, not the "vendor". And you have to hire a lawyer even if you
> are innocent of wrongdoing.)
>
> 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.
> 
> 
> RJF
> 
> 

Pisin Bootvong
From: John Thingstad
Subject: Re: Pricing ACL
Date: 
Message-ID: <op.s1rdq2t8pqzri1@mjolner.upc.no>
On Wed, 14 Dec 2005 05:14:46 +0100, Pisin Bootvong <··········@gmail.com>  
wrote:

> I thought that if I bought MSVC++ and sell a product call
> "start-up-vc.bat" which does nothing but start MSVC. And if I sells it
> for 1$ and distributed MSVC++ with them, I can still get sued from MS.
> And yet MS didn't charge MSVC per distributed app.
>

This is a bit off topic but MS-VC++ compiler tools are avaliable for
free from microsoft and have been for a time now.
It is the IDE they charge for.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Pisin Bootvong
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134557758.999587.290040@g47g2000cwa.googlegroups.com>
John Thingstad wrote:
> On Wed, 14 Dec 2005 05:14:46 +0100, Pisin Bootvong <··········@gmail.com>
> wrote:
>
> > I thought that if I bought MSVC++ and sell a product call
> > "start-up-vc.bat" which does nothing but start MSVC. And if I sells it
> > for 1$ and distributed MSVC++ with them, I can still get sued from MS.
> > And yet MS didn't charge MSVC per distributed app.
> >
>
> This is a bit off topic but MS-VC++ compiler tools are avaliable for
> free from microsoft and have been for a time now.
> It is the IDE they charge for.
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Yes i knew and I mean that whole IDE, not just the compiler that I
attached for 1$.

Most development environment out there don't sells the runtime.
They sell the development environment. They sells the convenient of
being able to edit/compile/debug. But they rarely sells the runtime.

Selling each runtime only reduced the chance of spreading the runtime,
therefore reduce the chance of application developed in such runtime of
reaching large user base.
However, Selling the runtime is still better than Franz's model of
price per an application distributed: If I sell my ACL-base-app to
someone who also have purchased another ACL-base-app from somewhere
else, it cost them twice for the "license to run ACL".

Franz's view is that if I deliver the Lisp image:
- My app will be capable of using "Compiler code, Eval". So what? Any
turing complete language is capable of writing an eval/interpreter
anyway. There is nothing special about eval, just a built-in
interpreter. Eval is just a convenient feature. Another of the
arguement is that "If we don't charge for each package someone will
build aproduct which do nothing but invoke the REPL and have all
feature of ACL and compete with us for less price". It is nonsense.
Can't you put in any License agreement to pervent that? Have you ever
seen that happens to LispWorks?
- My app will have all the IDE features. Can't you disable this? You
can build a trial version that can't dump executable image and have
memory limit. But you can't disable IDE class to be built to exe? What
application mainly relied on ACL IDE component?

Instead of requiring fee on special case of the product that use IDE
component, Franz suspect everyone will use it and charge on that
component.

I think Franz target the server class environment anyway, so they don't
care about application that is sold in masses.
I'm not saying how this pricing model is good or bad for Franz, it's
their product after all. They can choose any pricing model they want.
All I'm saying is that I don't think this model will benefit Lisp in
any way.
From: John Thingstad
Subject: Re: Pricing ACL
Date: 
Message-ID: <op.s1rt9rqrpqzri1@mjolner.upc.no>
On Wed, 14 Dec 2005 11:55:59 +0100, Pisin Bootvong <··········@gmail.com>  
wrote:

> John Thingstad wrote:
>> On Wed, 14 Dec 2005 05:14:46 +0100, Pisin Bootvong  
>> <··········@gmail.com>
>> wrote:
>>
>> > I thought that if I bought MSVC++ and sell a product call
>> > "start-up-vc.bat" which does nothing but start MSVC. And if I sells it
>> > for 1$ and distributed MSVC++ with them, I can still get sued from MS.
>> > And yet MS didn't charge MSVC per distributed app.
>> >
>>
>> This is a bit off topic but MS-VC++ compiler tools are avaliable for
>> free from microsoft and have been for a time now.
>> It is the IDE they charge for.
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
> Most development environment out there don't sells the runtime.
> They sell the development environment. They sells the convenient of
> being able to edit/compile/debug. But they rarely sells the runtime.

Not just libraries but also compiler and make and linker tools.

> Franz's view is that if I deliver the Lisp image:
> - My app will be capable of using "Compiler code, Eval". So what? Any
> turing complete language is capable of writing an eval/interpreter
> anyway. There is nothing special about eval, just a built-in
> interpreter. Eval is just a convenient feature. Another of the
> arguement is that "If we don't charge for each package someone will
> build aproduct which do nothing but invoke the REPL and have all
> feature of ACL and compete with us for less price". It is nonsense.
> Can't you put in any License agreement to pervent that? Have you ever
> seen that happens to LispWorks?

It's the compiler thery are worried about not the evauator..
In particular if you have a compiler and save facillity you could deliver  
applications
with their app with your code. It is not a ordinary senenario though.

> - My app will have all the IDE features. Can't you disable this? You
> can build a trial version that can't dump executable image and have
> memory limit. But you can't disable IDE class to be built to exe? What
> application mainly relied on ACL IDE component?
>

Yes you can disable IDE and GUI (I think that's what you mean) features.

> Instead of requiring fee on special case of the product that use IDE
> component, Franz suspect everyone will use it and charge on that
> component.
>
> I think Franz target the server class environment anyway, so they don't
> care about application that is sold in masses.
> I'm not saying how this pricing model is good or bad for Franz, it's
> their product after all. They can choose any pricing model they want.
> All I'm saying is that I don't think this model will benefit Lisp in
> any way.
>

I think Franz has set a standard for other Lisps.
In this it has benefitted Lisp.
For me comprehensive support is the primary factor why I chose Franz.
I can't have my developers twiddle their thumbs for a week trying to
figure out what to do. The most important cost to me is paying developers
monthly. It takes a lot to make up for the cost of lost work hours.
Software price is at best secondary.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <EGWnf.7693$i1.3318@news-wrt-01.rdc-nyc.rr.com>
Pisin Bootvong wrote:
> John Thingstad wrote:
> 
>>On Wed, 14 Dec 2005 05:14:46 +0100, Pisin Bootvong <··········@gmail.com>
>>wrote:
>>
>>
>>>I thought that if I bought MSVC++ and sell a product call
>>>"start-up-vc.bat" which does nothing but start MSVC. And if I sells it
>>>for 1$ and distributed MSVC++ with them, I can still get sued from MS.
>>>And yet MS didn't charge MSVC per distributed app.
>>>
>>
>>This is a bit off topic but MS-VC++ compiler tools are avaliable for
>>free from microsoft and have been for a time now.
>>It is the IDE they charge for.
>>
>>--
>>Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> 
> 
> Yes i knew and I mean that whole IDE, not just the compiler that I
> attached for 1$.

Hmm. I have just downloaded VC++ 8 Express for free and registered and 
do not recall taking out my credit card. I admit I did not notice if 
there are indispensible add-ons I get only by buying some "Pro" version. 
OK, I also then downloaded the win32 sdk for free. Hmmm. Not that that 
is an add-on.


> 
> Most development environment out there don't sells the runtime.
> They sell the development environment. They sells the convenient of
> being able to edit/compile/debug. But they rarely sells the runtime.
> 
> Selling each runtime only reduced the chance of spreading the runtime,
> therefore reduce the chance of application developed in such runtime of
> reaching large user base.
> However, Selling the runtime is still better than Franz's model of
> price per an application distributed: If I sell my ACL-base-app to
> someone who also have purchased another ACL-base-app from somewhere
> else, it cost them twice for the "license to run ACL".
> 
> Franz's view is that if I deliver the Lisp image:
> - My app will be capable of using "Compiler code, Eval". So what? Any
> turing complete language is capable of writing an eval/interpreter
> anyway.

ha ha ha, everyone loves to swing that "turing complete" club around. 
Would you like to write a C++ eval? Note that, like eval, it must cover 
the entire C++ language.

  There is nothing special about eval, just a built-in
> interpreter. Eval is just a convenient feature.

Convenient? No, for one Insanely Great application I did a while ago it 
was indispensible. In fact, my next product will rely on eval heavily as 
well. Indispensibly so. Oh, well, maybe I should soften up indispensibly 
-- an ugly and weaker alternative would be to load FASLs dynamically.

  Another of the
> arguement is that "If we don't charge for each package someone will
> build aproduct which do nothing but invoke the REPL and have all
> feature of ACL and compete with us for less price". It is nonsense.
> Can't you put in any License agreement to pervent that? Have you ever
> seen that happens to LispWorks?
> - My app will have all the IDE features. Can't you disable this? You
> can build a trial version that can't dump executable image and have
> memory limit. But you can't disable IDE class to be built to exe? What
> application mainly relied on ACL IDE component?
> 
> Instead of requiring fee on special case of the product that use IDE
> component, Franz suspect everyone will use it and charge on that
> component.
> 
> I think Franz target the server class environment anyway, so they don't
> care about application that is sold in masses.
> I'm not saying how this pricing model is good or bad for Franz, it's
> their product after all. They can choose any pricing model they want.
> All I'm saying is that I don't think this model will benefit Lisp in
> any way.
> 

By "benefit" you must mean "help it grow by giving away stuff they spent 
millions to develop". No, it won't do that. Of course, that would not 
work since -- coming full circle -- they would not be in business very long.

You all have a nasty "existence proof" to overcome: Franz is making 
money with Lisp.

I think you all are missing something. Pricing when "early adopters" are 
your only market is always at a premium. You will not get hordes of 
buyers now matter how low the price, while early adopters will pay 
anything to get your product. Well, a premium anyway.

Based on the blog traffic, we now see that Java has joined C++ on The 
Road to Obsolescence, and no statically-typed pretenders are to be had. 
The final round includes Python, Ruby, and -- holy prefix notation! -- Lisp.

Let's bash Franz again when Apress acquires O'Reilly. Of course, who 
knows what their pricing will be then.


kt
From: jayessay
Subject: Re: Pricing ACL
Date: 
Message-ID: <m31x0fir2o.fsf@rigel.goldenthreadtech.com>
Kenny Tilton <·············@nyc.rr.com> writes:

> Pisin Bootvong wrote:

> > - My app will be capable of using "Compiler code, Eval". So what? Any
> > turing complete language is capable of writing an eval/interpreter
> > anyway.
> 
> ha ha ha, everyone loves to swing that "turing complete" club
> around. Would you like to write a C++ eval? Note that, like eval, it
> must cover the entire C++ language.

Really.  I sometimes wonder if people who say this sort of nonsense
have any idea how foolish it makes them look.


> > I'm not saying how this pricing model is good or bad for Franz, it's
> > their product after all. They can choose any pricing model they want.
> > All I'm saying is that I don't think this model will benefit Lisp in
> > any way.

I tell you one thing that greatly benefits Lisp that Franz has managed
to accomplish: remain a viable business for 18 years.  This is an
important positive influenence when selling applications or proposals
into major companies.


> By "benefit" you must mean "help it grow by giving away stuff they
> spent millions to develop". No, it won't do that. Of course, that
> would not work since -- coming full circle -- they would not be in
> business very long.
> 
> You all have a nasty "existence proof" to overcome: Franz is making
> money with Lisp.

That's the primary problem with ideologues - they never let facts or
reality get in the way of their beliefs.  You watch - these people
will now come up with a new set of "arguments" to "show" that Franz
_can't_ actually exist.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: John Thingstad
Subject: Re: Pricing ACL
Date: 
Message-ID: <op.s1san5k4pqzri1@mjolner.upc.no>
On Wed, 14 Dec 2005 16:15:48 +0100, Kenny Tilton  
<·············@nyc.rr.com> wrote:

I also have a copy of VC-Express it expires april 2005.
It is a beta version.
When it is released it will cost 80 or so $.
Not alot compared to Franz hough.
But then it only works against .NET.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Adam Connor
Subject: Re: Pricing ACL
Date: 
Message-ID: <7asjq1tuo891lg7ih39trigdcqpea4t26q@4ax.com>
On Wed, 14 Dec 2005 15:15:48 GMT, Kenny Tilton
<·············@nyc.rr.com> wrote:
>Based on the blog traffic, we now see that Java has joined C++ on The 
>Road to Obsolescence, and no statically-typed pretenders are to be had. 
>The final round includes Python, Ruby, and -- holy prefix notation! -- Lisp.
>
>Let's bash Franz again when Apress acquires O'Reilly. Of course, who 
>knows what their pricing will be then.

The road to obsolescence is long. In any case, Python and Ruby (and
Perl and...) are free and have the simplicity that comes with a single
defacto standard. Franz may be making money, but if they were the only
competition Java's reign would never end.
--
adamnospamaustin.rr.com
s/nospam/c\./
From: jayessay
Subject: Re: Pricing ACL
Date: 
Message-ID: <m3oe39f2jw.fsf@rigel.goldenthreadtech.com>
Adam Connor <···@nospam.com> writes:


> defacto standard. Franz may be making money, but if they were the only
> competition Java's reign would never end.

I know you will not understand this, but the above is equally true for
Python, Ruby and Perl.

/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: Adam Connor
Subject: Re: Pricing ACL
Date: 
Message-ID: <eplmq1pk341vbsrvh92hii6k6kb344u18i@4ax.com>
On 22 Dec 2005 12:45:55 -0500, jayessay <······@foo.com> wrote:

>Adam Connor <···@nospam.com> writes:
>
>
>> defacto standard. Franz may be making money, but if they were the only
>> competition Java's reign would never end.
>
>I know you will not understand this, but the above is equally true for
>Python, Ruby and Perl.

You're right, I don't understand it. Ruby is attracting a lot of
attention from the Java community right now. 

Basically, I'm hypothesizing that to become popular at this point, a
language needs to have a cross-platform, free implementation with a
good set of libraries that work with it -- easily. Franz seems to have
a good technical reputation, but it can't satisfy that particular
need.

--
adamnospamaustin.rr.com
s/nospam/c\./
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <d%Nqf.15004$Ed.11654@news-wrt-01.rdc-nyc.rr.com>
Adam Connor wrote:
> On 22 Dec 2005 12:45:55 -0500, jayessay <······@foo.com> wrote:
> 
> 
>>Adam Connor <···@nospam.com> writes:
>>
>>
>>
>>>defacto standard. Franz may be making money, but if they were the only
>>>competition Java's reign would never end.
>>
>>I know you will not understand this, but the above is equally true for
>>Python, Ruby and Perl.
> 
> 
> You're right, I don't understand it. Ruby is attracting a lot of
> attention from the Java community right now. 
> 
> Basically, I'm hypothesizing that to become popular at this point, a
> language needs to have a cross-platform, free implementation with a
> good set of libraries that work with it -- easily. Franz seems to have
> a good technical reputation, but it can't satisfy that particular
> need.

When are yuse guys gonna cheer up? The trend for the past few years 
shows a huge upramp in Lisp popularity. Java is dying and Ruby stole 
Python's succession to the throne. So now there are two languages left 
standing, Ruby and Lisp. Why do I like Lisp's chances?

kt
From: drewc
Subject: Re: Pricing ACL
Date: 
Message-ID: <87mzipheth.fsf@rift.com>
Kenny Tilton <·············@nyc.rr.com> writes:

>
> When are yuse guys gonna cheer up? The trend for the past few years
> shows a huge upramp in Lisp popularity. Java is dying and Ruby stole
> Python's succession to the throne. So now there are two languages left
> standing, Ruby and Lisp. Why do I like Lisp's chances?

Thanks Kenny, you're always the voice of reason!

(fsvo of 'always', fsvo 'reason')

;)
  


> kt

-- 
drewc at tech dot coop
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <YZKrf.24769$i1.11314@news-wrt-01.rdc-nyc.rr.com>
drewc wrote:
> Kenny Tilton <·············@nyc.rr.com> writes:
> 
> 
>>When are yuse guys gonna cheer up? The trend for the past few years
>>shows a huge upramp in Lisp popularity. Java is dying and Ruby stole
>>Python's succession to the throne. So now there are two languages left
>>standing, Ruby and Lisp. Why do I like Lisp's chances?
> 
> 
> Thanks Kenny, you're always the voice of reason!

Hey, even the Wall Street Journal has noticed the death of Java. Front 
page of some section, saw it over XMas at my brother's. Talking all 
about the Tower of Babel of new languages-- PHP, Perl, Python, TCL, 
Ruby. No mention of Lisp, but that does not matter... the funny thing is 
that, when the mainstream wheels really start to come off, conservative 
managers are going to love the maturity, stability, polish, and 
standardization of CL.

Now if only we had a clear competitor for Ruby on Rails.

kt
From: Richard Fateman
Subject: Re: Pricing ACL / 2 royalties?
Date: 
Message-ID: <qlYnf.31412$dO2.21476@newssvr29.news.prodigy.net>
(in response to Pisin, saying two applications would cost two royalties..)

YOu could price your Allegro Lisp application as, say

$500 for the program executable or
$400 for the fasl-only  (must be run on your own Allegro version 7.0)

sort of like the "upgrade" model common in PC software.

$500 for Adobe XYZ version N
$400 for upgrade from version N-1

or like plug-ins for photoshop, toolkits for Matlab,
libraries etc for Excel, ...

RJF
From: Pisin Bootvong
Subject: Re: Pricing ACL / 2 royalties?
Date: 
Message-ID: <1135288046.114919.31750@g43g2000cwa.googlegroups.com>
Richard Fateman wrote:
> (in response to Pisin, saying two applications would cost two royalties..)
>
> YOu could price your Allegro Lisp application as, say
>
> $500 for the program executable or
> $400 for the fasl-only  (must be run on your own Allegro version 7.0)
>
> sort of like the "upgrade" model common in PC software.
>
> $500 for Adobe XYZ version N
> $400 for upgrade from version N-1
>
> or like plug-ins for photoshop, toolkits for Matlab,
> libraries etc for Excel, ...
>
> RJF

No, no, you misunderstand me.
I meant that two product from two company would cost two royalties.

If my company sells product X, built with ACL then a customer Z who buy
X would have to pay:
 X price == (price solely of product X) + (ACL runtime fee X have to
pay to ACL).
Then this same customer Z buys another product Y, which is also built
with ACL.
Customer Y would have to pay for product Y of price
Y price == (price solely of product Y) + (ACL runtime fee Y have to pay
to ACL).

If Franz fee was for each copied of runtime distributed to the
customer.
X pays to Franz for each X copied distributed to client Z.
Y pays to Franz for each Y copied distributed to client Z.

But totally client Z is paying two times for permission to run ACL
runtime on a single machine.

One of Franz's agreement was that by distributing ACL runtime, you are
distributing compilation, IDE, etc. which is like having Operating
System. Therefore, you should pay for a machine to have those Operating
System.

But the problem is I only buy Windows/Linux once. And then I can buy
any program that run on Windows/Linux without any fee that is passed to
MS/Redhat/Mandrake per application on my systems.

> $500 for the program executable or
> $400 for the fasl-only  (must be run on your own Allegro version 7.0)

should be compared to

> $500 for Windows XX + Adobe
> $400 for Adobe any version

How many program, not just adobe, do you have on your machine,
multiplied that by 100 is the additional cost if all of applications
are built with ACL.

Suggesting to sell the FASL only version is good *iff*
- The customer is also doing development. It will be good for
Lisp/Ruby/Java community if, before running any program built by
Borland C/MSVC, you are required to buy and install corresponding IDE.
If I'm just a user, I don't want to pay for IDE I don't use, That's why
I was hoping for ACL run only thingy.
- It is easy to deploy and used. I shouldn't need my customer to know
how to load all the fasl. All they want is to be able to double click
an EXE and run the program. Can fasl do that?
- Every vendor that use ACL provides FASL as default. You don't see
adobe Selling two version, one with a copy of Windows and another
without. You might say I can negotiate with every company to make out
the way. But do you have to negotiate with every vendor for every
software you buy for a version without Windows or upgrade version?

As I said before, Franz can use any pricing scheme they want with their
product after all.
But I don't think their pricing encourage people to use Lisp as in
"Develop everything in Lisp, from a simple Notepad to a Web server". I
wouldn't bother "Negotiate for special license to runtime only version
of ACL for lower price" just to use a beirc I download for free from
the internet.

P.S. The argument someone said about "Why do you criticise pricing
scheme of a succesful company which has been around for 15+ years?" is
nonsense. COBOL and FORTRAN is still used today. Why do you criticise
the successful language which has been used for 20+ years? C++ is even
more used by Lisp and has been around for more than 15 years. Windows
is a successful product, Why do you criticise the features of Operating
System which has been installed in more than 90% of all PCs? Living for
a long time or gaining most user base doesn't means everything about it
is good, does it?
From: Richard Fateman
Subject: Re: Pricing ACL
Date: 
Message-ID: <zLPnf.32969$7h7.22213@newssvr21.news.prodigy.com>
Pisin Bootvong wrote:

>
> And I can be sure Franz did not violate any of them because I never see
> their source code, right?

And if you did see the source code, you would know?  Of course you would
not know then either! But presumably Franz stands behind their product and
claims (and will defend the claim that) it owns Allegro Common Lisp.

> And nobody that uses Franz in commercial also use CL-PPCRE, CL-PDF,
> SLIME? 

If you are selling a product that relies on BSD code, you are in fact
assuming a certain risk. If you are selling a product that relies on
GPL code, you are assuming a certain risk, as well as an obligation,
in many circumstances, of making your own code free and open source.
As a business model this has some deficiencies.

And if you use Franz with those BSD/GPL licensed library then
> you don't have to be worried?

> 
> 
>>the business says, "Oh, about that Tahiti trip, who's your maintenance
>>person on 24-hour call."  you say "Hey man, does a blackberry work in
>>Tahiti?"
>>
> 
> 
> This is quite nonsense. Your client never know, when a problem comes,
> whether it is your application's problem or the underlying Lisp's
> problem.  So if a customer have a problem with a product (Your product
> X, not ACL or any Lisp) and cannot contact the you because you went to
> Tahiti, that is not a problem of using open-source Lisp, it is a
> problem of choosing the wrong shop.  
Well, when I ask for help from a vendor of Windows-based software, I
am often told that I should mess around with the operating system, get
a download of something, etc.  The vendors rely on Microsoft maintaining
a certain presence.  We may argue that MS doesn't do everything we want
it to do, but it usually doesn't require downloading fresh source code
for the whole operating system, editing a makefile, and recompiling everything.
That's the kind of advice I get if cygwin is broken.


> Are you saying that if reddit use
> ACL then the developer can go to Tahiti, not taking any call, and Franz
> will support any reddit issue for them?

I believe that Franz works very closely with some customers, and in some
cases may know more about the application than some of the application
programmers. I suppose it depends on the kind of revenue stream that
the application represents.  I doubt that a one-time $29.95 shrink-wrap
license fee for an infinite number of redistributed binaries would
get much help, but for $100 per copy (X many copies) it makes sense for
Franz to be helpful.
> 
> 

> 
> 
> I thought ACL have something like EXE maker. And that it shakes the
> image and unused function from the distributed image. I never know that
> when ACL build a distributed EXE, it includes all the IDE inside.

If your image uses all of Lisp, that doesn't help. For example, you
might use the IDE, or eval. Or you might use the compiler (e.g. for
dynamic CLOS).
> 
> I thought that if I bought MSVC++ and sell a product call
> "start-up-vc.bat" which does nothing but start MSVC. And if I sells it
> for 1$ and distributed MSVC++ with them, I can still get sued from MS.
> And yet MS didn't charge MSVC per distributed app.
> 
> To some extent, you are implying that any language that have "eval"
> should be licensed per package sold. As a matter of fact, if a
> interpreter can be written in a language such language implementation
> should be licensed per package sold, too. Right?

If you omitted eval from a copy of Allegro, but then
  you wrote an eval that had hooks to every function in Allegro, then
not much could be left out of that Allegro.  Just the main line of maybe
a page or two of one program, eval.
> 
> If you are afraid of your customer cheat in such a way, why not put it
> in EULA? Get a lawyer to indicate what it means to sell product that,
> in some way, allow one to use devlopment features of ACL. And indicate
> that only such product require per-package distribution fees (well,
> disregarding those Allegro special feature that should reasonably be
> charged per package if used, like AllegroCache).

If there is such an EULA, (I don't know),
I think it would have to be a very elaborate license agreement
to cover every contingency; so elaborate that a potential purchaser
would have difficulty figuring out if it
was right, and maybe would have to re-write particular parts.  Maybe
even hire a lawyer :( .

If the current technique is for Franz to try to "partner" with the
application writer, then that cooperation may be at least as useful as the proposal
above.  But presumably people at Franz read your note and this one
and can comment.

> You don't have to be afraid that they won't follow the EULA, since if
> they are not willing to, I think they willl cheat in all other ways
> anyway.

There are ways of auditing the sale of products. While MS might not
catch you making an extra copy of Word on your laptop, you can be sure
that if a large organization, even a university, buys software,
(or sells software) it cannot use piracy for long. (Unless it is in
a country that does not respect patents, copyrights, etc.)

So far as I can tell, the pricing model you are suggesting looks
pretty close to what is already in place.

It seems that we are hypothesizing the existence of
a creative lisp programmer who has the following characteristics:
  1. he/she avoids lawyers.
  2. and yet is willing to assume unknown legal risks to use "free" software;
  3. and probably has no financial backing (since investors
    (a) have lawyers
    (b) do not want to assume unknown legal risks. )
  4. so has no money to buy a commercial Lisp.

So Franz is not losing money on this person.  :)

More seriously,  finding a good way to "not give away the whole thing"
seems to be a key.  Maybe distribute a fasl file. Run it on a trial version.

RJF




> 
From: Pisin Bootvong
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134547412.962717.16600@g47g2000cwa.googlegroups.com>
Richard Fateman wrote:
> Pisin Bootvong wrote:
>
> >
> > And I can be sure Franz did not violate any of them because I never see
> > their source code, right?
>
> And if you did see the source code, you would know?  Of course you would
> not know then either! But presumably Franz stands behind their product and
> claims (and will defend the claim that) it owns Allegro Common Lisp.
>

Why would that make me more confident to sign the agreement that my
product, that contains Franz, instead of SBCL, doesn't violate anyone's
copyright? I wouldn't sign any agreement that some product I didn't
write myself doesn't violate any copyright, be it from SBCL, ACL or
Microsoft, would you? And how likely do you think that Linux will
collapse in the next 5-10 year of copyright violation?

> > And nobody that uses Franz in commercial also use CL-PPCRE, CL-PDF,
> > SLIME?
>
> If you are selling a product that relies on BSD code, you are in fact
> assuming a certain risk. If you are selling a product that relies on
> GPL code, you are assuming a certain risk, as well as an obligation,
> in many circumstances, of making your own code free and open source.
> As a business model this has some deficiencies.
>
> And if you use Franz with those BSD/GPL licensed library then
> > you don't have to be worried?
>
> >
> >
> >>the business says, "Oh, about that Tahiti trip, who's your maintenance
> >>person on 24-hour call."  you say "Hey man, does a blackberry work in
> >>Tahiti?"
> >>
> >
> >
> > This is quite nonsense. Your client never know, when a problem comes,
> > whether it is your application's problem or the underlying Lisp's
> > problem.  So if a customer have a problem with a product (Your product
> > X, not ACL or any Lisp) and cannot contact the you because you went to
> > Tahiti, that is not a problem of using open-source Lisp, it is a
> > problem of choosing the wrong shop.
> Well, when I ask for help from a vendor of Windows-based software, I
> am often told that I should mess around with the operating system, get
> a download of something, etc.  The vendors rely on Microsoft maintaining
> a certain presence.  We may argue that MS doesn't do everything we want
> it to do, but it usually doesn't require downloading fresh source code
> for the whole operating system, editing a makefile, and recompiling everything.
> That's the kind of advice I get if cygwin is broken.
>

Right, but you still get such advice and support from the product X
first. You don't go directly to MS support and ask why Some X software
doesn't work, do you? Your Tahiti situation was that the product X
vendor is not willing to provide any support and direction. Even if
that irresponsible vendor use ACL, I still wouldn't expect any better
support.

>
> > Are you saying that if reddit use
> > ACL then the developer can go to Tahiti, not taking any call, and Franz
> > will support any reddit issue for them?
>
> I believe that Franz works very closely with some customers, and in some
> cases may know more about the application than some of the application
> programmers. I suppose it depends on the kind of revenue stream that
> the application represents.  I doubt that a one-time $29.95 shrink-wrap
> license fee for an infinite number of redistributed binaries would
> get much help, but for $100 per copy (X many copies) it makes sense for
> Franz to be helpful.
> >
> >
>
> >
> >
> > I thought ACL have something like EXE maker. And that it shakes the
> > image and unused function from the distributed image. I never know that
> > when ACL build a distributed EXE, it includes all the IDE inside.
>
> If your image uses all of Lisp, that doesn't help. For example, you
> might use the IDE, or eval. Or you might use the compiler (e.g. for
> dynamic CLOS).
> >
> > I thought that if I bought MSVC++ and sell a product call
> > "start-up-vc.bat" which does nothing but start MSVC. And if I sells it
> > for 1$ and distributed MSVC++ with them, I can still get sued from MS.
> > And yet MS didn't charge MSVC per distributed app.
> >
> > To some extent, you are implying that any language that have "eval"
> > should be licensed per package sold. As a matter of fact, if a
> > interpreter can be written in a language such language implementation
> > should be licensed per package sold, too. Right?
>
> If you omitted eval from a copy of Allegro, but then
>   you wrote an eval that had hooks to every function in Allegro, then
> not much could be left out of that Allegro.  Just the main line of maybe
> a page or two of one program, eval.
> >
> > If you are afraid of your customer cheat in such a way, why not put it
> > in EULA? Get a lawyer to indicate what it means to sell product that,
> > in some way, allow one to use devlopment features of ACL. And indicate
> > that only such product require per-package distribution fees (well,
> > disregarding those Allegro special feature that should reasonably be
> > charged per package if used, like AllegroCache).
>
> If there is such an EULA, (I don't know),
> I think it would have to be a very elaborate license agreement
> to cover every contingency; so elaborate that a potential purchaser
> would have difficulty figuring out if it
> was right, and maybe would have to re-write particular parts.  Maybe
> even hire a lawyer :( .
>
> If the current technique is for Franz to try to "partner" with the
> application writer, then that cooperation may be at least as useful as the proposal
> above.  But presumably people at Franz read your note and this one
> and can comment.
>
> > You don't have to be afraid that they won't follow the EULA, since if
> > they are not willing to, I think they willl cheat in all other ways
> > anyway.
>
> There are ways of auditing the sale of products. While MS might not
> catch you making an extra copy of Word on your laptop, you can be sure
> that if a large organization, even a university, buys software,
> (or sells software) it cannot use piracy for long. (Unless it is in
> a country that does not respect patents, copyrights, etc.)
>

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.

> So far as I can tell, the pricing model you are suggesting looks
> pretty close to what is already in place.
>
> It seems that we are hypothesizing the existence of
> a creative lisp programmer who has the following characteristics:
>   1. he/she avoids lawyers.
>   2. and yet is willing to assume unknown legal risks to use "free" software;
>   3. and probably has no financial backing (since investors
>     (a) have lawyers
>     (b) do not want to assume unknown legal risks. )
>   4. so has no money to buy a commercial Lisp.
>
> So Franz is not losing money on this person.  :)
>
> More seriously,  finding a good way to "not give away the whole thing"
> seems to be a key.  Maybe distribute a fasl file. Run it on a trial version.
>
> RJF
>

May be something like VMWare player, say AllegroPlayer.
Just the runtime, where anyone can install for free and use for any
purpose.
Just the pure runtime, no IDE, no interface at all, without ability to
compile file, and must run from fasl. No AllegroCache or any of that
Allegro addon that you think deserve to be charge per copies.
From: Richard Fateman
Subject: Re: Pricing ACL
Date: 
Message-ID: <F6Ynf.31411$dO2.12969@newssvr29.news.prodigy.net>
Pisin Bootvong wrote:

...
> 
> 
> Why would that make me more confident to sign the agreement that my
> product, that contains Franz, instead of SBCL, doesn't violate anyone's
> copyright?

There are 2 parts to your product. The part you wrote yourself.  If you
deliberately copied it from something you didn't own, you could be in
trouble.  Then there is the part that Franz wrote. They protect you
from issues about that part.  That is part of what you pay them for.
I don't know about SBCL. But any code covered by BSD is not warranted.

When Berkeley was giving away 3BSD (UNIX for VAX, 68000), and the
original Franz Lisp (different code base from Allegro), we were
asked to sign all kinds of things by companies like IBM.  Like
UC Berkeley should assume all liability in case some of the 3BSD
code was copyrighted by someone else.  We didn't.  For years
IBM would not take 3BSD code. For some reason DEC was more willing
to take our code. Maybe because their lawyers were not as careful
or maybe they assumed that they would not be the target. IBM would
be the target.
Some government agencies required that none of 3BSD was produced
from "convict labor".

  I wouldn't sign any agreement that some product I didn't
> write myself doesn't violate any copyright, be it from SBCL, ACL or
> Microsoft, would you? 

You might have trouble selling it.

> And how likely do you think that Linux will
> collapse in the next 5-10 year of copyright violation?

Unfortunately, lawyers cost money whether the legal issues are
real or not.  So far as I can tell, IBM has plenty of lawyers
and as long as they fight Caldera/SCO, the rest of us can just
watch.  If you are not on the same side of the table as someone
with deep pockets, you might get sued.
> 
.....
>>
>>Well, when I ask for help from a vendor of Windows-based software, I
>>am often told that I should mess around with the operating system, get
>>a download of something, etc.  The vendors rely on Microsoft maintaining
>>a certain presence.  We may argue that MS doesn't do everything we want
>>it to do, but it usually doesn't require downloading fresh source code
>>for the whole operating system, editing a makefile, and recompiling everything.
>>That's the kind of advice I get if cygwin is broken.
>>
> 
> 
> Right, but you still get such advice and support from the product X
> first. 

Correct.

You don't go directly to MS support and ask why Some X software
> doesn't work, do you? Your Tahiti situation was that the product X
> vendor is not willing to provide any support and direction. Even if
> that irresponsible vendor use ACL, I still wouldn't expect any better
> support.
Incorrect.  Say the vendor determines that the bug is in the Lisp. Who fixes
it?  The vendor?  The open-source community?  The vendor may not be
(should not have to be ...) an expert in Lisp implementation.  Could he
fix a bug in (say) the garbage collector for GCL?  In the case of a
commercial Lisp, there is at least a prospect of getting professional
help.

Nevertheless, I think that if you find a bug in Franz software you are
likely to get a fix or a workaround.  From the open source community
you also might get a fix or a workaround, but maybe not.  It depends
on how "shallow" the bug is, how easy to reproduce, who is looking for
things to do, how many people take pride in their volunteerism, how many
people total there are in the community and how many are really expert
as opposed to just hacking.  There are lots of people in the linux
community. Many fewer in GCL.
> 
.....
>
>>There are ways of auditing the sale of products. While MS might not
>>catch you making an extra copy of Word on your laptop, you can be sure
>>that if a large organization, even a university, buys software,
>>(or sells software) it cannot use piracy for long. (Unless it is in
>>a country that does not respect patents, copyrights, etc.)
>>
> 
> 
> 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.

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?   [problem: what if you don't enforce
your EULA, there are all these ACLs distributed, hurting you and
Franz.]

2. If your product costs less than ACL it is OK to include all of
ACL because.. um,  someone would be giving you money and um, that
is good?

3. You are proposing that as long as the product does not contain
every single bit of ACL, it is ok to redistribute without royalties to Franz?
[Say, removing Roman Numerals from the formatted output...] or that
there should be some negotiation with Franz about royalties.
{I gather this is the current pricing policy}.

Auditing, which you seem to favor, means that the EULA from Franz and also from you
will contain a royalty provision which also allows Franz to
audit (a) your books; (b) your customers' books  (c) if they also produce
software, their customers' books. etc.

>.....
>>
> 
> 
> May be something like VMWare player, say AllegroPlayer.


> Just the runtime, where anyone can install for free and use for any
> purpose.
> Just the pure runtime, no IDE, no interface at all, without ability to
> compile file, and must run from fasl. No AllegroCache or any of that
> Allegro addon that you think deserve to be charge per copies.

One problem with Lisp is that the runtime for Lisp tends to be almost
all of the Lisp. Symbolics had a delivery system on IBM-PCs called
CLOE, (common lisp object environment) that it used for "products".
The only one I ever saw was Macsyma, but maybe there were others.
CLOE/Macsyma had a compiler since Macsyma uses compilation. Macsyma
also has an "execute lisp command" capability.  So the delivery system
could leave out the Symbolics IDE, but had to leave in, ANSI Common Lisp.

I guess it is a business and technical decision for Franz as to whether they should
design and develop a product like "AllegroPlayer" and then give it away.
Such a product would not be free to develop, support, document.
  Would this increase sales of development
systems enough to justify the cost?
(Franz already gives out (source) for a variety of programs, and
also gives out a free trial Allegro version.)

RJF

> 
From: Christophe Rhodes
Subject: Re: Pricing ACL
Date: 
Message-ID: <sqvexra9oq.fsf@cam.ac.uk>
Richard Fateman <·······@cs.berkeley.edu> writes:

> Incorrect.  Say the vendor determines that the bug is in the Lisp. Who fixes
> it?  The vendor?  The open-source community?  The vendor may not be
> (should not have to be ...) an expert in Lisp implementation.  Could he
> fix a bug in (say) the garbage collector for GCL?  In the case of a
> commercial Lisp, there is at least a prospect of getting professional
> help.

This is a false dichotomy: the Lisp does not have to be commercial for
there to be a prospect of getting professional help, just as the
Operating System kernel does not have to be commercial for there to be
a prospect of getting professional help.  The professional help may
involve a consideration, of course.

Christophe
From: Richard J. Fateman
Subject: Re: Pricing ACL
Date: 
Message-ID: <dnpmn0$1qi0$1@agate.berkeley.edu>
Christophe Rhodes wrote:
> Richard Fateman <·······@cs.berkeley.edu> writes:
> 
> 
>>Incorrect.  Say the vendor determines that the bug is in the Lisp. Who fixes
>>it?  The vendor?  The open-source community?  The vendor may not be
>>(should not have to be ...) an expert in Lisp implementation.  Could he
>>fix a bug in (say) the garbage collector for GCL?  In the case of a
>>commercial Lisp, there is at least a prospect of getting professional
>>help.
> 
> 
> This is a false dichotomy: the Lisp does not have to be commercial for
> there to be a prospect of getting professional help, just as the
> Operating System kernel does not have to be commercial for there to be
> a prospect of getting professional help.  The professional help may
> involve a consideration, of course.
> 
> Christophe

True. You could try to hire someone to fix a bug in an open-source Lisp 
implementation, instead of asking for a volunteer.

Or you could have a maintenance contract with a company that was 
committed to fixing such bugs.

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.

The situation changes when the code is used by huge numbers of people 
(e.g. Linux, RedHat), there are lots of experts, and there are
companies in the maintenance business.

I am not against using free software; I have produced some myself.
My point is that "total cost of ownership" is a more complicated issue 
than is often portrayed.   Certainly by university researchers.

RJF
From: Edi Weitz
Subject: Re: Pricing ACL
Date: 
Message-ID: <ud5jzh7ij.fsf@agharta.de>
On Wed, 14 Dec 2005 10:02:08 -0800, "Richard J. Fateman" <·······@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.  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.

Cheers,
Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Richard J. Fateman
Subject: Re: Pricing ACL
Date: 
Message-ID: <dnpsj2$1sba$1@agate.berkeley.edu>
Edi Weitz wrote:
> On Wed, 14 Dec 2005 10:02:08 -0800, "Richard J. Fateman" 
> <·······@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: Christophe Rhodes
Subject: Re: Pricing ACL
Date: 
Message-ID: <sqmzj3phz7.fsf@cam.ac.uk>
"Richard J. Fateman" <·······@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: Richard J. Fateman
Subject: Maxima code driving lisp implementation? was Re: Pricing ACL
Date: 
Message-ID: <dnq4i1$1v7j$1@agate.berkeley.edu>
Christophe Rhodes wrote:

> "Richard J. Fateman" <·······@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.
There are 74 archived messages in the maxima sourceforge list that
mention SBCL, and 127 that mention CMU-CL. My guess is that some of
them say "this worked just great in SBCL"  but some of them raise
issues about stuff that either has to be conditionalized around in
the maxima code, or that causes problems.  Treatment of signed
(float) zeros caught my eye.

There are 153 mentions of CLISP
There are 500 mentions of GCL

Ideally, an application program written in ANSI Common Lisp would
not be affected much by which Lisp is being used. In reality it
matters since there are components that are not part of the standard,
and so Maxima developers tend to have to mess with this. There were
originally conditionalizations in the code for PDP10, Multics, 
Symbolics, etc.

My personal tendency with respect to Maxima implementation is
that I use the pre-packaged GCL most of the time, and so I try
to avoid looking at messages solely concerned with other lisps.  When I
need to build a new lisp program and use maxima, I compile it
into Allegro CL.   So my impression of "other lisps" is
not the result of careful study. Things work or not, or get fixed,
as people hack on either the Maxima source or the lisp.
It is fairly easy to seach on the maxima mail:
http://maxima.sourceforge.net/maximalist.html

I did not mean to disparage any of those lisps, just to point
out that sometimes bug searches lead to bugs in the Lisp.
 From my perspective, a major problem (bug?) with Maxima/SBCL is that
  it doesn't yet work on Windows,
  (yeh,yeh, what am I doing running on windows...)
and thus SBCL is in need of "patching and improving". :)

> Bug reports and patches from Maxima developers and users, and indeed
> everyone else, are of course very welcome.

You get high points from me for the right attitude!

RJF
From: Christophe Rhodes
Subject: Re: Maxima code driving lisp implementation? was Re: Pricing ACL
Date: 
Message-ID: <sqirtqq1dr.fsf@cam.ac.uk>
"Richard J. Fateman" <·······@eecs.berkeley.edu> writes:

> From my perspective, a major problem (bug?) with Maxima/SBCL is that
>  it doesn't yet work on Windows,
>  (yeh,yeh, what am I doing running on windows...)
> and thus SBCL is in need of "patching and improving". :)

Heh.  Well, a minor challenge for someone with the need to run Maxima
with SBCL on windows is to see what happens with the binary provided
by Alastair Bridgewater at
<http://www.dridus.com/~nyef/sbcl-win32-0.9.6-binaries.zip> (though to
be honest I'd be very surprised if the answer were anything but "it
breaks instantly" :-)

Christophe
From: Espen Vestre
Subject: Re: Pricing ACL
Date: 
Message-ID: <m1acf3xyv6.fsf@vestre.net>
Edi Weitz <········@agharta.de> writes:

> unless he's patching and improving the compiler all the time.  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.

Sounds like good management: Get one of the really good ones by giving
him time to work with his pet projects, and benefit both from the
pet projects and the guy who runs them.
-- 
  (espen)
From: Pascal Bourguignon
Subject: Re: Pricing ACL
Date: 
Message-ID: <87hd9b1mi0.fsf@thalassa.informatimago.com>
Richard Fateman <·······@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: Don Geddis
Subject: Re: Pricing ACL
Date: 
Message-ID: <878xum2oao.fsf@geddis.org>
> 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 <·······@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/               ···@geddis.org
Dear Mr. President:  There are too many states.  Please eliminate three.  I am
not a crackpot.  -- Abraham "Grandpa" Simpson
From: jayessay
Subject: Re: Pricing ACL
Date: 
Message-ID: <m3slsugkfg.fsf@rigel.goldenthreadtech.com>
Don Geddis <···@geddis.org> writes:

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

How is this different from just about any other case of OEM
considerations?  Or for that matter, what about the packaging costs
per unit?  If you are selling millions I would expect you must be on
display counters at Best Buy, WalMart, etc.  That requires real
packaging and the attendent costs.  Come to think of it, you have to
account for the per unit take of Best Buy, WalMart, etc. as well.


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

It's hard to understand how any of this follows in any sort of real
business scenario - especially the kind you have put forth where you
are selling millions of copies.  What do these sort of games go for
these days?  $50.00?  $30.00?  So, if a royalty of say 20-50 _cents_
per copy were involved, how would that prevent the whole thing from
happening?  It's possible, but that would tend to indicate that
something else is seriously wrong with the business.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: Don Geddis
Subject: Re: Pricing ACL
Date: 
Message-ID: <87d5jy2ck2.fsf@geddis.org>
jayessay <······@foo.com> wrote on 15 Dec 2005 15:4:
> How is this different from just about any other case of OEM
> considerations?

Well, of course it isn't unreasonable in principle.

But compared to other alternatives, it does seem way out of the ballpark.

Imagine a planning meeting, before beginning on the project.  Haven't even
hired programmers yet.  Executive staff is trying to decide what language
platform to commit to.  Somebody goes up to the whiteboard, lists the pros
& cons of each choice.  C, C++, Java, Python, CMUCL, SBCL, CLisp, Lispworks,
Franz Allegro CL.  There are pros and cons like, how hard is it to find
programmers, how expensive are they, how productive would we expect them to
be, how much support does the supplier provide, etc.

And then way at the end is a column for programming language costs.  Every
line shows a few thousand dollars or less (some are free), except Allegro CL,
where the total cost to the project would be more on the order of millions of
dollars.

Is that single offering from that single supplier really so much better than
all the alternatives?  I suppose it might be, but that would be a tough
argument to try to win during the discussion.

> It's hard to understand how any of this follows in any sort of real
> business scenario - especially the kind you have put forth where you
> are selling millions of copies.  What do these sort of games go for
> these days?  $50.00?  $30.00?  So, if a royalty of say 20-50 _cents_
> per copy were involved, how would that prevent the whole thing from
> happening?

So you're imagining royalties at around 1%?  And where did you get numbers
like that?

In any case, even you would admit that the cost for going with Franz would be
on the order of millions, whereas the cost for alternatives is thousands.

Perhaps there's benefit to compensate for the costs, but you're going to need
to find a whole lot of it to make the decision worthwhile.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Seen on Pavlov's door:  "Knock.  Don't ring bell."
From: Peter Herth
Subject: Re: Pricing ACL
Date: 
Message-ID: <dnsur9$ack$00$1@news.t-online.com>
Don Geddis wrote:

> 
> And then way at the end is a column for programming language costs.  Every
> line shows a few thousand dollars or less (some are free), except Allegro CL,
> where the total cost to the project would be more on the order of millions of
> dollars.
> 

Millions of dollars? How in all worlds do you come to that number?
Allegro certainly isn't a low-cost software, but Franz offers several 
license models, so the chance is that you can get a deal that fits your 
projects size and requirements.
Of course, with everything you buy, YOU have to decide how to spend your 
money. If using Allegro does not give you an advantage compared to lets 
say, use Python, then every single buck spend on Allegro is wasted. On 
the other side, there are projects, where using Allegro does give an 
advantage, up to the point that paying for Allegro saves you a lot of 
money.

Peter

-- 
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
From: Ravi
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134725671.110339.28680@g14g2000cwa.googlegroups.com>
I  think Peter Herth nails it with

"If using Allegro does not give you an advantage compared to lets
say, use Python, then every single buck spent on Allegro is wasted."

This is the key point. If Allegro does not give you an advantage worth
paying them (on their terms) for, don't buy.

I would never ever buy an Allegro license because I don't believe in
their philosophy of  'in perpetuity' runtime licenses, and I don't like
using closed source languages, but I am absolutely fine with them
imposing any pricing scheme they can think of on their product. It is *
their product*  to price! And my money and time are *mine* to spend.

I think the real problem here is that of a lack of a cross platform
(runs on win,linux,bsd,osx) lisp which has threads, networking etc ,has
libraries comparable to those of Python or Ruby, installs easily on
every platform etc. Then again no one is stopping anyone from writing
just such a beast.

I think if you ask yourself the following questions
a) Does writing my product in Lisp vs Python or Ruby (both totally
free) give me a major advantage?
b)If so is that advantage worth paying the Allegro license fees or
should I work with(say)CMUCL and live with the limitations of (say)
running  only on Linux/Unix?
c) do you (the person with the money) *mind* paying what may seem
"unreasonable" license fees?

I think you will find very  few projects that pass these filters and
land on the side of "pay the Allegro fees", but if you do find one, you
should just pay up and focus on your project.

In short, Allegro has the right to price their product any way they
want. Every developer has the right to reject these terms and work with
another product or language. Every person has the right to determne how
to spend their money. What could be fairer?

If Allegro claims that their licensing policy is somehow "more right"
than others (say that of Ruby or MIcrosoft VC++ or whatever), or if
some developers claim that aAllegro pricing schemes are "unfair", both
should be rejected as invalid. If Allegro makes sense in your project
use it. Else ignore it and let the market take care of ACL's dominance
or decline.


All imo.

Regards,
Ravi
From: ············@reillyhayes.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134740892.647547.269070@g44g2000cwa.googlegroups.com>
>Millions of dollars? How in all worlds do you come to that number?

Franz charges a percentage of revenue for commercial software
developers.  If your revenues are $100 million per year, they are
charging you between $4 million and $10 million per year.  For
comparison, 10 engineers on $50,000 a seat CAD stations comes to half a
million a year.  That $50,000 looks pretty cheap by comparison, doesn't
it?

Franz makes money because their pricing scheme is a sucker bet.  In
accepting Franz's pricing scheme, their customers are betting against
their own future success.  You know, it isn't a bad business model
they've got there.  They've got the best kind of rubes in the world:
people who assume that because they are smart about one thing
(technology) that they're smart about another (business).  As I've said
before, this only applies to the reseller license.  And it doesn't
really apply to somebody selling a low-volume/low-cost product that
makes their money another way.

Actually, I take back what I said before.  I would be perfectly happy
to develop a loss-leader product with Allegro.   Something I sold for
$50 bucks a seat but gave me a relationship with clients that I could
use to upsell other products at $50,000 seat.
From: Kevin Layer
Subject: Re: Pricing ACL
Date: 
Message-ID: <mkirto36ou.fsf@*n*o*s*p*a*m*franz.com>
············@reillyhayes.com writes:

> >Millions of dollars? How in all worlds do you come to that number?
> 
> Franz charges a percentage of revenue for commercial software
> developers.  If your revenues are $100 million per year, they are
> charging you between $4 million and $10 million per year.  

A company with a product that brings in $100 million per year has
already negotiated a royalty rate significantly less than $4 million
per year.

And, it doesn't take a $100 million dollar application to get a better
rate.  The reason we don't publish a single royalty rate is that every
application is different and we *want* the rate to vary.  The rates,
in recent years, are in single digits, and vary with what the customer
wants.   We have some customers that just repackage our development
environment and sell a complete Lisp with their application
(documentation and all).  This is at the high end.  There are others
where the situation is very different, at the other end.

> For
> comparison, 10 engineers on $50,000 a seat CAD stations comes to half a
> million a year.  That $50,000 looks pretty cheap by comparison, doesn't
> it?

In fact, Franz has a few customers in the CAD area, and I don't know
the details, but I know our royalties were not a significant part of
the cost of the application (the word `significant' in the way you are
talk... yes, I know, some thing 5% is significant).

> Franz makes money because their pricing scheme is a sucker bet.  

You make it sound like there is one `royalty pricing scheme'.  There
is not.

> In
> accepting Franz's pricing scheme, their customers are betting against
> their own future success.  

I don't believe your implied assertion, that we want anything but
successful, happy customers.

Kevin Layer
Franz Inc.
From: ···················@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134811081.176393.198210@g44g2000cwa.googlegroups.com>
The royalty based pricing approach of Franz Inc. is not a problem; it
is a consequence. It's a consequence of a 20 years old idea still
driving the sales of Allegro Common Lisp that the customer must be
caught and locked in.

Allegro Common Lisp is such a tool that encourages  the developer
  - to write code which is hard to use with other implementations
later,
  - to use proprietory libraries instead of vendor-neutral ones;
and the manager to establish binding relations with Franz in such a
way, that the very amount of effort spent makes switching to another
implementation, or using more than one, undesirable.

The approach to pricing is a logical consequence of this policy: make
the ties as strong as possible.

I believe this was something that worked 20 years ago and continues to
work now. But the audience has changed: those who believe that spending
more money on programming tools yields a better product are wrong now;
it does not count anymore. Franz is just a brick in VC piramide; and as
such it gets its share. But not because ACL is particularly good, it is
not the best implementation: it eats more memory than LW, works slower
than CMUCL on numeric computations, in particular with complex numbers,
has mediocre multi-threading. Where it shines in is in creating false
impression of shift of responsibility -- they imply that they take care
of my code. They are good programmers, but they won't.

When I sent subscription request to the allegro users mailing list, I
got a confirmation reply from a human. In 2005, it means that Franz is
either so smart that they have an AI software that talks like a man, or
that they are 20 years behind in customer relations. I suspect the
latter.

I agree that the pricing is appropriate. And that the marketing
strategy of Franz is successful. It is just not successful with me; I
want an implementation that makes it easy to switch to another one --
and if it does not, I don't pay. I want a users list managed by a
robot; because its a kind of job robots do well and they don't get sick
or go to vacations. And, yes, as a developer, I want pricing policy
that does not make my manager think that his effort spent on tools
acquisition and revenue reporting improves the product quality -- this
is a wrong assumption. 

David Tolpin
From: Rainer Joswig
Subject: Re: Pricing ACL
Date: 
Message-ID: <joswig-F70E28.17395217122005@news-europe.giganews.com>
In article <························@g44g2000cwa.googlegroups.com>,
 ···················@gmail.com wrote:

> The royalty based pricing approach of Franz Inc. is not a problem; it
> is a consequence. It's a consequence of a 20 years old idea still
> driving the sales of Allegro Common Lisp that the customer must be
> caught and locked in.

And I thought that the base idea was providing excellent
service for demanding customers.

> Allegro Common Lisp is such a tool that encourages  the developer
>   - to write code which is hard to use with other implementations
> later,

I don't think this is true in general. Atleast not more
so than with the other implementations. For some applications
it is not THAT hard to move large amounts of code from
ACL to, say, LW and back. For some of their libraries
they have even allowed other to use it (AllegroServe is
an example -> Portable AllegroServe). But I'm also
not surprised that a company enhances their product to get
a competetive advantage.

>   - to use proprietory libraries instead of vendor-neutral ones;
> and the manager to establish binding relations with Franz in such a
> way, that the very amount of effort spent makes switching to another
> implementation, or using more than one, undesirable.

See above.

> The approach to pricing is a logical consequence of this policy: make
> the ties as strong as possible.

On the other hand it helps the customer to implement
complex software.

> I believe this was something that worked 20 years ago and continues to
> work now. But the audience has changed: those who believe that spending
> more money on programming tools yields a better product are wrong now;
> it does not count anymore. Franz is just a brick in VC piramide; and as
> such it gets its share. But not because ACL is particularly good, it is
> not the best implementation: it eats more memory than LW, works slower
> than CMUCL on numeric computations, in particular with complex numbers,
> has mediocre multi-threading. Where it shines in is in creating false
> impression of shift of responsibility -- they imply that they take care
> of my code. They are good programmers, but they won't.

It seems though that for some (demanding) applications Allegro CL works
pretty well. In many areas CMUCL is far, far behind ACL.
ACL works with a very complete feature set on many platforms.

> When I sent subscription request to the allegro users mailing list, I
> got a confirmation reply from a human. In 2005, it means that Franz is
> either so smart that they have an AI software that talks like a man, or
> that they are 20 years behind in customer relations. I suspect the
> latter.

I find a human response refreshingly modern.

> I agree that the pricing is appropriate. And that the marketing
> strategy of Franz is successful. It is just not successful with me; I
> want an implementation that makes it easy to switch to another one --
> and if it does not, I don't pay. I want a users list managed by a
> robot; because its a kind of job robots do well and they don't get sick
> or go to vacations. And, yes, as a developer, I want pricing policy
> that does not make my manager think that his effort spent on tools
> acquisition and revenue reporting improves the product quality -- this
> is a wrong assumption. 
> 
> David Tolpin

Have you ever seen the prices and licenses for BEA's WebLogic?
It is quite popular in the Java/J2EE world.
From: ···················@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134840444.434910.246150@g14g2000cwa.googlegroups.com>
> > The royalty based pricing approach of Franz Inc. is not a problem; it
> > is a consequence. It's a consequence of a 20 years old idea still
> > driving the sales of Allegro Common Lisp that the customer must be
> > caught and locked in.
>
> And I thought that the base idea was providing excellent
> service for demanding customers.

No, the base idea is to provide false impression of excellent service
for demanding customers. A customer that is tied is not being served
well. He is just in a convenient state to serve him: immobilized except
for the swallowing reflex.

> I don't think this is true in general. Atleast not more
> so than with the other implementations. For some applications
> it is not THAT hard to move large amounts of code from
> ACL to, say, LW and back.

Of course it is true in general for applications. Applications which
are written
well are easy to port between. It is only a problem that the Allegro CL
environment
and libraries discourage writing portably. If you develop using
something else and
just check with ACL, everything is good. If you develop in ACL, you'll
have
problems.

> > The approach to pricing is a logical consequence of this policy: make
> > the ties as strong as possible.
>
> On the other hand it helps the customer to implement
> complex software.

How does limiting the freedom of design help implement complex
software? Complex
rules result in dumb behavior.

> It seems though that for some (demanding) applications Allegro CL works
> pretty well. In many areas CMUCL is far, far behind ACL.
> ACL works with a very complete feature set on many platforms.

ACL works with a very complete feature set on many platforms, and the
complete
feature set behaves differently with other lisp implementations. You
are locked in.

> I find a human response refreshingly modern.

In two days since the request, they might as well have sent it to me by
mail.

> Have you ever seen the prices and licenses for BEA's WebLogic?
> It is quite popular in the Java/J2EE world.

It does not excuse.

David
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <lxYof.2560$Ed.1220@news-wrt-01.rdc-nyc.rr.com>
···················@gmail.com wrote:
>>>The royalty based pricing approach of Franz Inc. is not a problem; it
>>>is a consequence. It's a consequence of a 20 years old idea still
>>>driving the sales of Allegro Common Lisp that the customer must be
>>>caught and locked in.
>>
>>And I thought that the base idea was providing excellent
>>service for demanding customers.

OK, now on this one I have all the expertise in the world: nah, they are 
pretty damn good.

I had three complaints in dozens of incidents over several years, and 
there were several times that support went above and beyond the call of 
duty. All the other incidents produced patches within 24 hours. (Why so 
many? Lots were because I was doing cruel and unusual things to 
AllegroStore that unearthed flaws therein.)

I think they hew too closely to an understandable line: they hold out 
for a non-working code sample distilled from the application. But I 
never (once?) really jumped up and down and asked them to Just Think 
about my description of the observed failure and work backwards. Maybe 
they would bend on that.

What I did learn to do, where a reproducible was hard to carve out, was 
just ask them for background on some library that might relate to the 
observed problem. Then they were great about tossing out useful 
background material to help me find avenues to explore a problem.

I am wondering if "demanding customer" explains our different mileage. 
We always proved to ourselves at least that any anomaly we reported did 
not arise from our own bug. And we always RTFMed more closely, dreading 
a response that simply pointed us at the doc to resolve our problem. 
What I wanted to do was establish that we were "undemanding" so that, if 
it ever came down to it, I could jump and down and demand proper support 
if they were dragging their feet on something. But as I said, they 
always responded the same or next day with a patch to any bug of theirs, 
so I never had to jump up and down.

kt
From: Edi Weitz
Subject: Re: Pricing ACL
Date: 
Message-ID: <uwti3ttbd.fsf@agharta.de>
On Sat, 17 Dec 2005 18:11:29 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:

> And we always RTFMed more closely

Now I'm disappointed.  You always tell us that you don't RTFM.

Tststs,
Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <c3_of.2564$Ed.948@news-wrt-01.rdc-nyc.rr.com>
Edi Weitz wrote:
> On Sat, 17 Dec 2005 18:11:29 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:
> 
> 
>>And we always RTFMed more closely
> 
> 
> Now I'm disappointed.  You always tell us that you don't RTFM.

<g> Actually, as I wrote that I was laughing to myself at how nicely it 
/confirmed/ my famous manual illiteracy.

> 
> Tststs,

Did you mean "Tsk tsk"? :)

kt
From: Edi Weitz
Subject: Re: Pricing ACL
Date: 
Message-ID: <uk6e3tryg.fsf@agharta.de>
On Sat, 17 Dec 2005 19:55:52 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:

>> Tststs,
>
> Did you mean "Tsk tsk"? :)

That's probably how you'd say it on your side of the pond.  But you
also say "soccer" when it's actually "football," right?

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Ulrich Hobelmann
Subject: Re: Pricing ACL
Date: 
Message-ID: <40kokmF1b2on8U1@individual.net>
Edi Weitz wrote:
> On Sat, 17 Dec 2005 19:55:52 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:
> 
>>> Tststs,
>> Did you mean "Tsk tsk"? :)
> 
> That's probably how you'd say it on your side of the pond.  But you
> also say "soccer" when it's actually "football," right?

Actually "football" seems to be the most popular sport in lots of 
countries, only that it denotes different sports :)

Aah, the joy of :shadow.

-- 
If you have to ask what jazz is, you'll never know.
	Louis Armstrong
From: Duane Rettig
Subject: Re: Pricing ACL
Date: 
Message-ID: <o0psntkiwk.fsf@franz.com>
···················@gmail.com writes:

>> I find a human response refreshingly modern.
>
> In two days since the request, they might as well have sent it to me by
> mail.

Help me to understand something, David.  The above mail makes it seem
like you were requesting advice from Franz Inc and got a poor response.

However, the context of this reply seems to be here:

| When I sent subscription request to the allegro users mailing list, I
| got a confirmation reply from a human. In 2005, it means that Franz is
| either so smart that they have an AI software that talks like a man, or
| that they are 20 years behind in customer relations. I suspect the
| latter.

and in a different part of this thread you make it clear that the
mailing list you are describing is the Allegro-CL mailing list, a
forum on which users can discuss issues with Allegro CL.  Sometimes
we take support nudges from that list, but usually it is users
talking to other users.  And its volume is low.  Why is that?  I
assume it's because our customers are satisfied by the support
they receive on our support mailing list (which is, oddly enough,
named ·······@franz.com).  Because they get quick and detailed
support when they send mail to the support list, there tends to
be little need for the use of the allegro-cl list for the purpose
of complaining about such lack, or to ask about techniques and
secrets about Allegro CL.  I suppose that if we weren't as responsive
on the support list, there would be more traffic on the allegro-cl
list.  Would that be a better scene for you?

Even those users who have downloaded out Trial version (free and
unsupported) can always send in problem reports to support, and
we will assign an spr (software problem report) number to the issue.
We don't promise to answer unsupported customers, so those who send
such reports in may not realize that an spr number has been assigned,
but we do keep track of these reports, and we take them seriously,
including possible generation of bug reports, etc, for a next version.
Sometimes we even create a patch, if we determine that what the user
is seeing must be fixed right away.

So I can look at our spr database and see who has ever submitted a
problem report in Allegro CL's history.  And as I look, your name is
not there.  Now, it is possible that you submitted problem reports
under a different name, or perhaps you had someone else submit a
problem report, but in fact I do not see your name anywhere in the
database.

So you are claiming to prefer an automated response for support, and
yet you seem never to have used our support.  Instead, you have used
a mailing list, the sole purpose of which is to spawn _discussion_,
notably between users and potential users, all of whom can be assumed
to be human.

Please explain this strange paradox.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: ············@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134974467.712542.207450@g49g2000cwa.googlegroups.com>
> So you are claiming to prefer an automated response for support, and
> yet you seem never to have used our support.  Instead, you have used
> a mailing list, the sole purpose of which is to spawn _discussion_,
> notably between users and potential users, all of whom can be assumed
> to be human.
>
> Please explain this strange paradox.
>


Hi Duane,

I am not claiming to prefer an automated response for support.I was not
going to submit a bug report to Franz.  What I am claiming is

1) a software company I am interested to deal with should create and
keep alive a users' community around the software it offers; in
particular if the software is an implementation of Common Lisp. Many
problems are of public interest.

2) when I had sent a subscription request to the mailing list, I  had
received an answer in two days, and written by a human. It means the
following:
  - Most discussions on vendor mailing lists are fostered by immediate
problems or challenges; by the time I am subscribed to the list in this
low-tech way, the problem is either solved or dissolved (or I resorted
to writing to private support address, and Franz has happily turned my
curiousity into a private matter)
  - The company I am considering dealing with is unable to keep up with
the current technology,  wasting human resources and paying wages for a
kind of job done by a robot better than by a man. I would think that
good engineers left the company, and those who are still in the team
cannot set up a mailing list in a appropriate way, let alone support me
in my problems.
  - If the company charges high rates for its goods and services, I
would think that it is because it spends too much on inefficient ways
to maintain and develop software: if their list subscription is manual,
then their bug tracking, testing and distribution building is too, and
thus is error-prone.

3) My impression is that this is not an omission, but a part of the
company's marketing policy; the policy seems to be of 1984 vintage, and
does not work with me.

David Tolpin
From: Duane Rettig
Subject: Re: Pricing ACL
Date: 
Message-ID: <o0mzixvse7.fsf@franz.com>
·············@gmail.com" <············@gmail.com> writes:

>> So you are claiming to prefer an automated response for support, and
>> yet you seem never to have used our support.  Instead, you have used
>> a mailing list, the sole purpose of which is to spawn _discussion_,
>> notably between users and potential users, all of whom can be assumed
>> to be human.
>>
>> Please explain this strange paradox.
>>
>
>
> Hi Duane,
>
> I am not claiming to prefer an automated response for support.I was not
> going to submit a bug report to Franz.

Some of your writing is apparently hypothetical, as is illustrated by
your second bulletted item under 2), below.  Thanks for clarifying.

>  What I am claiming is
>
> 1) a software company I am interested to deal with should create and
> keep alive a users' community around the software it offers; in
> particular if the software is an implementation of Common Lisp. Many
> problems are of public interest.

Why Common Lisp in particular?  Why not C?

Any community that a vendor establishes is not a user's community, by
definition and by design; it is a vendor's community.  If you've cut your
teeth on one of the languages whose instigator is a strong (hopefully
benevolent) dictator, then you won't have experienced a true user
community.  Old lispers, on the other hand, have indeed experienced what
a true user commnity is - unfortunately it tends to be a negative thing -
users getting together so that their voice can be heard by an otherwise
unresponsive vendor.  Nowadays, that kind of community is not very
necessary, because a vendor who is unresponsive to customer demands will
not last.

So vendor-created user's community is an oxymoron.

> 2) when I had sent a subscription request to the mailing list, I  had
> received an answer in two days, and written by a human.

There are two problems with the above statement:

 - It is not _the_ mailing list - Franz Inc maintains several.  You
have assumed a function for a mailing list that is not necessarily true.

 - You sent a subscription request.   Did you send any actual messages?
Subscription requests and messages are not eqivalent.  Subscription
(and unsubscription) requests occur extremely rarely, and is easily
administered by a human with little time consumption - perhaps a half-hour
per year.  I think that the Allegro-CL administrator spends a lot more
time tracking down and killing subscriptions that have died due to email
addresses becoming invalid - these messages are automatically generated
but need some human intervention to ensure that people don't get dropped
just because they are currently having trouble with their domains, etc.

> It means the
> following:

and because of the above mistakes, the "following" do not follow,
even if they happened to be true:

>   - Most discussions on vendor mailing lists are fostered by immediate
> problems or challenges; by the time I am subscribed to the list in this
> low-tech way, the problem is either solved or dissolved (or I resorted
> to writing to private support address, and Franz has happily turned my
> curiousity into a private matter)

Yes. and this is bad because ...?

We have a long but strong feedback loop at Franz Inc.  We tend to be
responsive to users, and try to get back to paying customers in a
reasonable time.  Besides that, we try to feed back issues and problems,
as well as rfes (requests for enhancemet) into the implementation and
the documentation.  As a result, we have a huge set of documentation,
which becomes the public offering of the private interactions.  Believe
me, you really don't _want_ to see all of the private interaction anyway,
you would be overwhelmed.  

>   - The company I am considering dealing with is unable to keep up with
> the current technology,  wasting human resources and paying wages for a
> kind of job done by a robot better than by a man. I would think that
> good engineers left the company, and those who are still in the team
> cannot set up a mailing list in a appropriate way, let alone support me
> in my problems.

Ah, yes, you know our company so well - we're just so much like any other
company.  Well, for starters, I'll tell you that almost every developer
we had 18 years ago at Franz Inc is still here, and most developers here
today were present at least 15 years ago.  I even have a story about it,
but I'll refrain from repeating it since you can probably google for it.

As for keeping up with technology, that is a subjective thing, and you
are entitled to your opinions.  But in fact your guesses tell me that
you base your subjectivity on very little fact, knowledge that can easily
be gleaned by browsing our site or downloading and working with our
Trial version.  And if this "technology" that we are so backwards in is
epitomized by the Allegro-CL mailing list, then you are simply barking
up the wrong tree.

>   - If the company charges high rates for its goods and services, I
> would think that it is because it spends too much on inefficient ways
> to maintain and develop software: if their list subscription is manual,
> then their bug tracking, testing and distribution building is too, and
> thus is error-prone.

More inaccuracies, in assumption and conclusion.

How long have you kept your company alive and profitable?

> 3) My impression is that this is not an omission, but a part of the
> company's marketing policy; the policy seems to be of 1984 vintage, and
> does not work with me.

I'm not sure what the "this" is that is supposedly ommitted or not, but
your whole argument does not work with me.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: ···················@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1135021180.419102.160580@f14g2000cwb.googlegroups.com>
> Some of your writing is apparently hypothetical, as is illustrated by
> your second bulletted item under 2), below.  Thanks for clarifying.
>

Hi Duane,

this  a false statement. In my original message, available at
http://groups.google.com/group/comp.lang.lisp/msg/7b71bc5e31ee4ee9, I
had clearly and unambigiously stated the following:

> When I sent subscription request to the allegro users mailing list, I
> got a confirmation reply from a human. In 2005, it means that Franz is
> either so smart that they have an AI software that talks like a man, or
> that they are 20 years behind in customer relations. I suspect the
> latter.

Which means basically the same, and even expressed in almost the same
words, as my point 2) below. Let me quote the point 2) below again:

> > 2) when I had sent a subscription request to the mailing list, I  had
> > received an answer in two days, and written by a human.


> > 1) a software company I am interested to deal with should create and
> > keep alive a users' community around the software it offers; in
> > particular if the software is an implementation of Common Lisp. Many
> > problems are of public interest.
>
> Why Common Lisp in particular?  Why not C?

Because any current implementation of Common Lisp is underspecified in
more areas than C (with libraries); and there are more things to
interpret differently, both by the implementor and by the user.

> users getting together so that their voice can be heard by an otherwise
> unresponsive vendor.  Nowadays, that kind of community is not very
> necessary, because a vendor who is unresponsive to customer demands will
> not last.
>
> So vendor-created user's community is an oxymoron.

Let me point you at vendor-created user communities (in the form of a
mailing list) by two Common Lisp vendors:

http://clozure.com/pipermail/openmcl-devel/
http://news.gmane.org/gmane.lisp.lispworks.general/

both are active and useful. Let me also point you at a vendor-created
user community (in the form of a mailing) by a non-programming-language
(but a similar by nature) software vendor.

http://www.renderx.net/lists/xep-support/200512byindex.html

>
> > 2) when I had sent a subscription request to the mailing list, I  had
> > received an answer in two days, and written by a human.
>
> There are two problems with the above statement:

Duane, you are using word `problem'. Could you please explain whose
problems are they? Are they my problems, your problems, or problems of
Franz?

>
>  - It is not _the_ mailing list - Franz Inc maintains several.  You
> have assumed a function for a mailing list that is not necessarily true.

Are there any other public mailing lists maintained by Franz? Where on
the Franz's site are links/subscription instructions to the lists? The
only link I found on Franz's site is to _the_mailing_list_.

>
>  - You sent a subscription request.   Did you send any actual messages?

No, because by the time I could get a response (being subscribed) I
solved my problem and lost the interest. Then I discovered that due to
faulty subscription scheme the list is almost uninhabited.

> Subscription requests and messages are not eqivalent.  Subscription
> (and unsubscription) requests occur extremely rarely, and is easily
> administered by a human with little time consumption - perhaps a half-hour
> per year.

This scheme has resulted in the delay of subscription by two days.
Assuming that a similar delay happened with every other subscriber, or
even a delay of  a few hours, there is no wonder that manual
subscription will only take half an hour per year. As I explained, this
means that the mailing list is useless for initial problem resolution,
and most people decide whether to join a community based on their first
experience.


> I think that the Allegro-CL administrator spends a lot more
> time tracking down and killing subscriptions that have died due to email
> addresses becoming invalid - these messages are automatically generated
> but need some human intervention to ensure that people don't get dropped
> just because they are currently having trouble with their domains, etc.


So the problem is still thate  Allego-CL administrator is unqualified,
and cannot set up a mailing list properly. The problem you are
describing is resolved years ago in a few different software packages.

> Believe
> me, you really don't _want_ to see all of the private interaction anyway,
> you would be overwhelmed.

I don't want to see all of the private interaction. I only want to see
public interaction, that is, questions and problems users decide to
discuss publicly. And Franz explicitly makes it impossible or
inconvenient.

> Ah, yes, you know our company so well - we're just so much like any other
> company.  Well, for starters, I'll tell you that almost every developer
> we had 18 years ago at Franz Inc is still here, and most developers here
> today were present at least 15 years ago.  I even have a story about it,
> but I'll refrain from repeating it since you can probably google for it.

That's because I wrote in the last point of my message that since most
Franz developers are the same for 15 years, this is not due to their
engineering failure, but due to the marketing policy of Franz, which is
successful, but not with me.

>
> As for keeping up with technology, that is a subjective thing, and you
> are entitled to your opinions.  But in fact your guesses tell me that
> you base your subjectivity on very little fact, knowledge that can easily
> be gleaned by browsing our site or downloading and working with our
> Trial version.

I had applied for the full time-limited version of Allegro CL, received
it and tried it for a month and a half. It is of good quality; however,
this is not the point of this discussion. I am talking about a simple
thing,  that and why I don't like the way Franz Inc. sells their
software to me, and I don't buy. And my point has been that the
revenue-based pricing is not a problem of mine by itself, but a
consequence of a more general problem that Franz Inc. creates for its
customers; and that I don't want to get.

> How long have you kept your company alive and profitable?

6 alive, 4.5 profitable.

>
> > 3) My impression is that this is not an omission, but a part of the
> > company's marketing policy; the policy seems to be of 1984 vintage, and
> > does not work with me.
>
> I'm not sure what the "this" is that is supposedly ommitted or not, but
> your whole argument does not work with me.

The omission is the absence of good software making the users' mailing
list usable; I beg you to excuse my bad English. It is not an argument,
it is an opinion; and as an opinion, it is not intended to work with
anybody else; however, it deserves consideration.

David
From: Duane Rettig
Subject: Re: Pricing ACL
Date: 
Message-ID: <o01x08whr3.fsf@franz.com>
···················@gmail.com writes:

>> Some of your writing is apparently hypothetical, as is illustrated by
>> your second bulletted item under 2), below.  Thanks for clarifying.
>>
>
> Hi Duane,
>
> this  a false statement.

Perhaps, as you note later in your response, there is a problem in
your understanding of my English.  See below, where I point out that
you missed the "second bulletted item" in my statement.

> In my original message, available at
> http://groups.google.com/group/comp.lang.lisp/msg/7b71bc5e31ee4ee9, I
> had clearly and unambigiously stated the following:
>
>> When I sent subscription request to the allegro users mailing list, I
>> got a confirmation reply from a human. In 2005, it means that Franz is
>> either so smart that they have an AI software that talks like a man, or
>> that they are 20 years behind in customer relations. I suspect the
>> latter.
>
> Which means basically the same, and even expressed in almost the same
> words, as my point 2) below. Let me quote the point 2) below again:
>
>> > 2) when I had sent a subscription request to the mailing list, I  had
>> > received an answer in two days, and written by a human.

Yes, but that has nothing to do with _my_ point, which was to compare
your unclear writing about subscriptions with the _second_ _bulletted_ item
of 2), where you posed a hypothetical (conveniently elided from your
response):

|   - The company I am considering dealing with is unable to keep up with
| the current technology,  wasting human resources and paying wages for a
| kind of job done by a robot better than by a man. I would think that
| good engineers left the company, and those who are still in the team
| cannot set up a mailing list in a appropriate way, let alone support me
| in my problems.

This hypothetical is patently false.

>> > 1) a software company I am interested to deal with should create and
>> > keep alive a users' community around the software it offers; in
>> > particular if the software is an implementation of Common Lisp. Many
>> > problems are of public interest.
>>
>> Why Common Lisp in particular?  Why not C?
>
> Because any current implementation of Common Lisp is underspecified in
> more areas than C (with libraries); and there are more things to
> interpret differently, both by the implementor and by the user.

Ah, so this is a Common Lisp thing!  Well, then, since your complaint
is about how unstandardized CL is, it should be a CL-wide community.
Check out any of the CL-wide efforts (many of which Franz participates
in actively) to create de-facto standards for CL programs above and
beyond the Ansi spec.

>> users getting together so that their voice can be heard by an otherwise
>> unresponsive vendor.  Nowadays, that kind of community is not very
>> necessary, because a vendor who is unresponsive to customer demands will
>> not last.
>>
>> So vendor-created user's community is an oxymoron.
>
> Let me point you at vendor-created user communities (in the form of a
> mailing list) by two Common Lisp vendors:
>
> http://clozure.com/pipermail/openmcl-devel/
> http://news.gmane.org/gmane.lisp.lispworks.general/
>
> both are active and useful. Let me also point you at a vendor-created
> user community (in the form of a mailing) by a non-programming-language
> (but a similar by nature) software vendor.
>
> http://www.renderx.net/lists/xep-support/200512byindex.html

As I conceded to Arthur, oxymoron was too harsh a term, and I rescind
it.  However, the usefulness of a user list is sometimes inversely
proportional to the usefulness of the vendor responses.  If our own
user mailing list is not used very often by its users, it suggests
something about the quality of our support.  As for a sense of
"community", I think many of our users are also users of other lisps,
and they tend to get a sense of community, not from a particular
vendor, but due to this language that we all love so much.  It really
is a Common Lisp thing!

>> > 2) when I had sent a subscription request to the mailing list, I  had
>> > received an answer in two days, and written by a human.
>>
>> There are two problems with the above statement:
>
> Duane, you are using word `problem'. Could you please explain whose
> problems are they? Are they my problems, your problems, or problems of
> Franz?

I think you are not understanding my English.  You made a statement.
I told you that there are two problems with that statement, and listed
what they were.  Now, the "problems" may be yours, if you accept that
you made a statement that is wrong or incomplete in certain senses, or
they might be the c.l.l. community's problems, if they believe that
what you say is accurate or complete.  The problems with your statement
are not mine, except that I'm taking the trouble to correct you, nor
are they Franz's, many employees of which haven't even seen your
statement yet.

>>  - It is not _the_ mailing list - Franz Inc maintains several.  You
>> have assumed a function for a mailing list that is not necessarily true.
>
> Are there any other public mailing lists maintained by Franz?

Ah, first you say "mailing list", and then you say "public mailing
list".  That is precisely the problem with your statement; you are
manipulating your words to make it convenient to make your point
without having to be precise.  So I will resolve the conflict by
ignoring this latest addition of the word "public", and tell you
that you can find at least three mailing lists here:

http://www.franz.com/support/


> Where on
> the Franz's site are links/subscription instructions to the lists?

The majority of our mailing lists don't need a subscription.

> The only link I found on Franz's site is to _the_mailing_list_.

There you go with "the mailing list" again (sans "public").  It's
as if the only mailing list you acknowledge is a public one.
If so, just say so, so we can get on with the knowledge that
you don't acknowledge mailing lists that aren't public.

>>  - You sent a subscription request.   Did you send any actual messages?
>
> No, because by the time I could get a response (being subscribed) I
> solved my problem and lost the interest. Then I discovered that due to
> faulty subscription scheme the list is almost uninhabited.

Not true.  I am not the administrator of the list, but there are many
users and non-users on the list.  That it is seldom used doesn't speak
to its habitation, but to its use. 

>                             As I explained, this
> means that the mailing list is useless for initial problem resolution,
> and most people decide whether to join a community based on their first
> experience.

Here we go with the hypothetical again.  "Initial problem resolution"
implies that there is a problem to resolve.  But if you were an Allegro CL
user, and posed such a problem to a user list, and had to wait for several
days to get someone to respond, you would be no better off than if you just
sent mail to ·······@franz.com, where you don't even have to subscribe.

>> Believe
>> me, you really don't _want_ to see all of the private interaction anyway,
>> you would be overwhelmed.
>
> I don't want to see all of the private interaction. I only want to see
> public interaction, that is, questions and problems users decide to
> discuss publicly. And Franz explicitly makes it impossible or
> inconvenient.

No, we don't.  We only make it _more_ convenient to send mail directly
to ·······@franz.com.  And our users tend to know this, and becuase of
that they don't tend to use the public list as often.

>> Ah, yes, you know our company so well - we're just so much like any other
>> company.  Well, for starters, I'll tell you that almost every developer
>> we had 18 years ago at Franz Inc is still here, and most developers here
>> today were present at least 15 years ago.  I even have a story about it,
>> but I'll refrain from repeating it since you can probably google for it.
>
> That's because I wrote in the last point of my message that since most
> Franz developers are the same for 15 years, this is not due to their
> engineering failure, but due to the marketing policy of Franz, which is
> successful, but not with me.
>
>>
>> As for keeping up with technology, that is a subjective thing, and you
>> are entitled to your opinions.  But in fact your guesses tell me that
>> you base your subjectivity on very little fact, knowledge that can easily
>> be gleaned by browsing our site or downloading and working with our
>> Trial version.
>
> I had applied for the full time-limited version of Allegro CL, received
> it and tried it for a month and a half. It is of good quality; however,
> this is not the point of this discussion. I am talking about a simple
> thing,  that and why I don't like the way Franz Inc. sells their
> software to me, and I don't buy. And my point has been that the
> revenue-based pricing is not a problem of mine by itself, but a
> consequence of a more general problem that Franz Inc. creates for its
> customers; and that I don't want to get.

That's your prerogative.

>> > 3) My impression is that this is not an omission, but a part of the
>> > company's marketing policy; the policy seems to be of 1984 vintage, and
>> > does not work with me.
>>
>> I'm not sure what the "this" is that is supposedly ommitted or not, but
>> your whole argument does not work with me.
>
> The omission is the absence of good software making the users' mailing
> list usable; I beg you to excuse my bad English. It is not an argument,
> it is an opinion; and as an opinion, it is not intended to work with
> anybody else; however, it deserves consideration.

I can excuse your English, but when it causes you to deride the company
I work for, I will not sit idlely by.  I do not mind the marketing
jabs; we get those all the time; but the talk of incompetence of developers
is galling.  If you feel ill at ease with your English, then you should
tone it down a little, until you can understand the nuances of what you
are saying and how it is being taken.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Arthur Lemmens
Subject: Re: Pricing ACL
Date: 
Message-ID: <op.s11o5uzgwpmq96@news.xs4all.nl>
Duane Rettig <·····@franz.com> wrote:

> So vendor-created user's community is an oxymoron.

I don't think it is.  You may want to look at the Lispworks mailing
list for a nice counter-example.
From: Duane Rettig
Subject: Re: Pricing ACL
Date: 
Message-ID: <o0bqzcwlmc.fsf@franz.com>
"Arthur Lemmens" <········@xs4all.nl> writes:

> Duane Rettig <·····@franz.com> wrote:
>
>> So vendor-created user's community is an oxymoron.
>
> I don't think it is.  You may want to look at the Lispworks mailing
> list for a nice counter-example.

OK, I concede that oxymoron is too strong a word.  But I see in those
lists questions which should be answerable by the vendor.  Why isn't
that being done?  David has been harping on the Allegro-CL mailing
list's subscription mechanism, but once users are subscribed, they
can mail whatever info they want back and forth on the list.  Why
don't they do that?  I suspect that is is rather a softer dichotomy;
if the vendor is able to answer your questions more often than other
users can, then which will you turn to?  I suspect that the Allegro-CL
list is much less used because it is not as good for information as
talking to us is.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Edi Weitz
Subject: Re: Pricing ACL
Date: 
Message-ID: <uslso5vbs.fsf@agharta.de>
On Mon, 19 Dec 2005 18:25:15 -0800, Duane Rettig <·····@franz.com> wrote:

> OK, I concede that oxymoron is too strong a word.  But I see in
> those lists questions which should be answerable by the vendor.  Why
> isn't that being done?  David has been harping on the Allegro-CL
> mailing list's subscription mechanism, but once users are
> subscribed, they can mail whatever info they want back and forth on
> the list.  Why don't they do that?  I suspect that is is rather a
> softer dichotomy; if the vendor is able to answer your questions
> more often than other users can, then which will you turn to?  I
> suspect that the Allegro-CL list is much less used because it is not
> as good for information as talking to us is.

Granted, such a mailing list is also a clever way to pass some load
off of the implementor towards the user community, and Franz certainly
has more staff to deal with support requests than LispWorks.
Nevertheless, there are advantages the "always ask your vendor"
approach doesn't have: A mailing list is often simply faster than a
vendor.  I've had one support request where it took Franz a week to
answer.  That certainly was an exception, but even if you can
guarantee that you'll always answer within one business day that won't
help me much if I'm working on a Saturday night - and I do that a lot.
On the LispWorks mailing list you'll most likely find some fellow
hacker who also can't sleep or simply is in another time zone.  But it
gets even better than that: A mailing list can be archived and made
publicly accessible - see gmane.org for example.  There you'll find
literally thousands of emails which comprise (part of) the combined
wisdom of the LW user community and many of your questions are
probably answered before you've even started your email program.
Maybe your spr database carries even more interesting information but
I guess you won't open it up to the public any time soon... :)

Cheers,
Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Duane Rettig
Subject: Re: Pricing ACL
Date: 
Message-ID: <o0u0d4uqra.fsf@franz.com>
Edi Weitz <········@agharta.de> writes:

> On Mon, 19 Dec 2005 18:25:15 -0800, Duane Rettig <·····@franz.com> wrote:
>
>> OK, I concede that oxymoron is too strong a word.  But I see in
>> those lists questions which should be answerable by the vendor.  Why
>> isn't that being done?  David has been harping on the Allegro-CL
>> mailing list's subscription mechanism, but once users are
>> subscribed, they can mail whatever info they want back and forth on
>> the list.  Why don't they do that?  I suspect that is is rather a
>> softer dichotomy; if the vendor is able to answer your questions
>> more often than other users can, then which will you turn to?  I
>> suspect that the Allegro-CL list is much less used because it is not
>> as good for information as talking to us is.
>
> Granted, such a mailing list is also a clever way to pass some load
> off of the implementor towards the user community, and Franz certainly
> has more staff to deal with support requests than LispWorks.

Specifically, the support staff is probably of similar size, but also,
all developers perform support as part of their tasks.

> Nevertheless, there are advantages the "always ask your vendor"
> approach doesn't have: A mailing list is often simply faster than a
> vendor.  I've had one support request where it took Franz a week to
> answer.

Sorry about that.

>  That certainly was an exception, but even if you can
> guarantee that you'll always answer within one business day that won't
> help me much if I'm working on a Saturday night - and I do that a lot.
> On the LispWorks mailing list you'll most likely find some fellow
> hacker who also can't sleep or simply is in another time zone.

Yes, but of course that only would help you if that hacker knows
the answer to your question.  Of course, we Franz developers are
also hackers, and some of our customers can attest to the fact that
we are also insomniacs often in a time zone near you.  Business day?
What's that? :-)

>  But it
> gets even better than that: A mailing list can be archived and made
> publicly accessible - see gmane.org for example.  There you'll find
> literally thousands of emails which comprise (part of) the combined
> wisdom of the LW user community and many of your questions are
> probably answered before you've even started your email program.
> Maybe your spr database carries even more interesting information but
> I guess you won't open it up to the public any time soon... :)

Yes; now we're finally talking - this is precisely the reason for
a public forum.  And the Allegro-CL list is open and archived (it
even has a link in the location I gave to David).  But it is up to our
users to use it or not, and they tend to choose not to, presumably
(and I do assume here) because the response is faster on average
when given from the support mailing list, _and_ because the responses
tend to be helpful.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Duane Rettig
Subject: Re: Pricing ACL
Date: 
Message-ID: <o0fyond94x.fsf@franz.com>
Duane Rettig <·····@franz.com> writes:

[Sorry for the lateness of these responses; we're having trouble with
our news provider, which we're trying to fix.  I'd use google groups,
but I really like gnus, so I want to see if we can fix the underlying
service there first... ]

>>  But it
>> gets even better than that: A mailing list can be archived and made
>> publicly accessible - see gmane.org for example.  There you'll find
>> literally thousands of emails which comprise (part of) the combined
>> wisdom of the LW user community and many of your questions are
>> probably answered before you've even started your email program.
>> Maybe your spr database carries even more interesting information but
>> I guess you won't open it up to the public any time soon... :)
>
> Yes; now we're finally talking - this is precisely the reason for
> a public forum.  And the Allegro-CL list is open and archived (it
> even has a link in the location I gave to David).  But it is up to our
> users to use it or not, and they tend to choose not to, presumably
> (and I do assume here) because the response is faster on average
> when given from the support mailing list, _and_ because the responses
> tend to be helpful.

I'm also told by our Allegro-CL administrator that there is a
gmane interace: http://news.gmane.org/gmane.lisp.allegro - it is
not mentioned in our support page; I'll try to get that changed.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Richard Fateman
Subject: Re: Pricing ACL  / vendor mailing lists vs community lists
Date: 
Message-ID: <phLpf.1460$oW.1343@newssvr11.news.prodigy.com>
Edi Weitz wrote:

>
> 
> 
> Granted, such a mailing list is also a clever way to pass some load
> off of the implementor towards the user community, and Franz certainly
> has more staff to deal with support requests than LispWorks.
> Nevertheless, there are advantages the "always ask your vendor"
> approach doesn't have: A mailing list is often simply faster than a
> vendor.  

I have some experience with microsoft on a similar situation.  I was
(still am..) using MS speech development kit, and found some bugs
that I wished to report, and also provide workarounds.  I thought
I would do them a favor.  No thanks -- they make it virtually
impossible to report bugs (oh, you can pay them "to fix YOUR bugs"
but I didn't have any).  They want you to join a newgroup hosted
by MS. That way the MS developers don't have to answer questions;
they have some category of (I suspect volunteer) experts who
sometimes answer questions correctly.  For my "problem" there were
numerous people responding out of ignorance, with advice to reboot
my machine, reload my OS, or the speech software etc.  Finally
someone (at MS) asked for a voluminous and pointless
trace, which I supplied. I suspect he tried the simple example
and agreed it was a MS bug.

Two points:  it was a waste of my time, and somewhat insulting.

Basically MS is asking you to wade into a newsgroup, checking
the water, looking at FAQs etc. as a prerequiste to asking
people for help when 90% of the participants know less than
you do  [ and I assure you I was far far from an expert on
this], and wait a few days for one of the few people who
know more than you to maybe answer.

Sensing that, in this speech community, I was almost an expert..
I could answer 30% of the questions, having looked at the documentation for
maybe 3 days was kind of bizarre.   Am I supposed to somehow be indebted
to MS or to MS speech users that I should actually answer their questions?
when did I volunteer for this?

I stopped reading that newsgroup.
So maybe the model works sometimes, but I prefer a model where
I can report what I think of as bugs, and get prompt responses from
someone who knows more than I do.  If the responses are not prompt,
that becomes a problem too, of course.

RJF
From: Edi Weitz
Subject: Re: Pricing ACL  / vendor mailing lists vs community lists
Date: 
Message-ID: <ubqzc6r05.fsf@agharta.de>
On Tue, 20 Dec 2005 03:56:05 GMT, Richard Fateman <·······@cs.berkeley.edu> wrote:

> I have some experience with microsoft on a similar situation.  I was
> (still am..) using MS speech development kit, and found some bugs
> that I wished to report, and also provide workarounds.  I thought I
> would do them a favor.  No thanks -- they make it virtually
> impossible to report bugs (oh, you can pay them "to fix YOUR bugs"
> but I didn't have any).  They want you to join a newgroup hosted by
> MS. That way the MS developers don't have to answer questions; they
> have some category of (I suspect volunteer) experts who sometimes
> answer questions correctly.  For my "problem" there were numerous
> people responding out of ignorance, with advice to reboot my
> machine, reload my OS, or the speech software etc.  Finally someone
> (at MS) asked for a voluminous and pointless trace, which I
> supplied. I suspect he tried the simple example and agreed it was a
> MS bug.
>
> Two points:  it was a waste of my time, and somewhat insulting.
>
> Basically MS is asking you to wade into a newsgroup, checking the
> water, looking at FAQs etc. as a prerequiste to asking people for
> help when 90% of the participants know less than you do [ and I
> assure you I was far far from an expert on this], and wait a few
> days for one of the few people who know more than you to maybe
> answer.
>
> Sensing that, in this speech community, I was almost an expert..  I
> could answer 30% of the questions, having looked at the
> documentation for maybe 3 days was kind of bizarre.  Am I supposed
> to somehow be indebted to MS or to MS speech users that I should
> actually answer their questions?  when did I volunteer for this?
>
> I stopped reading that newsgroup.  So maybe the model works
> sometimes, but I prefer a model where I can report what I think of
> as bugs, and get prompt responses from someone who knows more than I
> do.  If the responses are not prompt, that becomes a problem too, of
> course.

This doesn't sound good and the only encounter I had with MS support
also wasn't good but your analogy is flawed.  We initially started
comparing the LispWorks mailing list to the AllegroCL mailing list.
At LispWorks, unlike MS, nobody /forces/ you to use the list.  You
/can/ use it and it obviously works well for many of their users.  If
you don't like such a list you can email LispWorks directly for
support and you'll get timely and helpful answers just as with Franz.

That way, the LW mailing list is an addition (and a nice one) not an
alternative to having vendor support.

Cheers,
Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Rainer Joswig
Subject: Re: Pricing ACL
Date: 
Message-ID: <BFCD6390.23458%joswig@lisp.de>
Am 19.12.2005 20:16 Uhr schrieb "Arthur Lemmens" unter <········@xs4all.nl>
in ·················@news.xs4all.nl:

> Duane Rettig <·····@franz.com> wrote:
> 
>> So vendor-created user's community is an oxymoron.
> 
> I don't think it is.  You may want to look at the Lispworks mailing
> list for a nice counter-example.

Btw., only recently (given the age of the list) the LispWorks mailing list
woke up. It is still far away from where for example the MCL mailing was
some years ago. There were lots of people sharing expertise and code on the
mailing list and via Digitool's FTP server.

There are some signs that the LispWorks community will reach that
that level - an example are Edi Weitz' extensions for LispWorks.
From: Richard Fateman
Subject: Re: Pricing ACL
Date: 
Message-ID: <zfBpf.31169$BZ5.12617@newssvr13.news.prodigy.com>
Hi, David.
  Since your message to C.L.L appears to have been written
by a human, you clearly haven't kept up with technology. How
can you justify wasting human resources for a job clearly
done better by a robot?
   For my part, I'm just waiting for my toaster to finish.
Maybe I should get a higher-tech toaster that could multitask
and write letters to C.L.L. Maybe I should design such a toaster
and give one to Duane. And to you. :)

Regards.
RJF



with ············@gmail.com wrote:

.....
>   - The company I am considering dealing with is unable to keep up with
> the current technology,  wasting human resources and paying wages for a
> kind of job done by a robot better than by a man. I would think that
> good engineers left the company, and those who are still in the team
> cannot set up a mailing list in a appropriate way, let alone support me
> in my problems.
>   - If the company charges high rates for its goods and services, I
> would think that it is because it spends too much on inefficient ways
> to maintain and develop software: if their list subscription is manual,
> then their bug tracking, testing and distribution building is too, and
> thus is error-prone.
> 
> 3) My impression is that this is not an omission, but a part of the
> company's marketing policy; the policy seems to be of 1984 vintage, and
> does not work with me.
> 
> David Tolpin
> 
From: ···················@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1135012065.465847.25790@g47g2000cwa.googlegroups.com>
Richard Fateman wrote:
> Hi, David.
>   Since your message to C.L.L appears to have been written
> by a human, you clearly haven't kept up with technology. How
> can you justify wasting human resources for a job clearly
> done better by a robot?

Hi Richard,

the attitude you are trying to express is what made AI fail in 80s. Not
every job is done by a computer is better than by a human; only a
simple one. But the thing is that when the computer does a simple
routine job, it frees the human's brain for decision-making.

>    For my part, I'm just waiting for my toaster to finish.
> Maybe I should get a higher-tech toaster that could multitask
> and write letters to C.L.L. Maybe I should design such a toaster
> and give one to Duane. And to you. :)

I doubt that you can; in particular, one that will suit both Duane and
me. The cause of that is that such toaster will have free will; and
this is beyond current capacities even of a founder of Franz Inc.

What you should consider though, is that forcing you to use a toaster
without a timer so that you have to pay to a person with a stop-watch
taking care of your morning toast, and, what is more important, to
depend on his attention to get the toast baked to the right level, is
like the current level of technology at Franz with regard to their
community forum.

As a result, you would avoid getting toasts on mornings, and Franz does
not have an active user community on the list.

David
From: Larry Clapp
Subject: Re: Pricing ACL
Date: 
Message-ID: <slrndqe4so.ck6.larry@theclapp.ddts.net>
On 2005-12-19, ···················@gmail.com <···················@gmail.com> wrote:
> Richard Fateman wrote:
>> Hi, David.
>>   Since your message to C.L.L appears to have been written by a
>> human, you clearly haven't kept up with technology. How can you
>> justify wasting human resources for a job clearly done better by a
>> robot?
>
> Hi Richard,
>
> the attitude you are trying to express is what made AI fail in 80s.

Oh, I don't know.  I didn't think he was trying to express any
particular attitude; I thought he was trying to make fun of you.  For
my part, he succeeded; I just about snorted my lunch all over my
laptop.

In particular, your stance appears illogical, unreasonable, unfounded,
and impervious to reason.  Very machine-like, no?

-- Larry
From: ···················@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1135023420.677141.64810@g47g2000cwa.googlegroups.com>
> > the attitude you are trying to express is what made AI fail in 80s.
>
> Oh, I don't know.  I didn't think he was trying to express any
> particular attitude; I thought he was trying to make fun of you.  For
> my part, he succeeded; I just about snorted my lunch all over my
> laptop.
>
> In particular, your stance appears illogical, unreasonable, unfounded,
> and impervious to reason.  Very machine-like, no?


No. I am joking, too. We just have a finer sense of humour here, on the
other side of the ocean. And we don't eat where we work.

David
From: Larry Clapp
Subject: Re: Pricing ACL
Date: 
Message-ID: <slrndqed1m.ck6.larry@theclapp.ddts.net>
On 2005-12-19, ···················@gmail.com <···················@gmail.com> wrote:
>> > the attitude you are trying to express is what made AI fail in 80s.
>>
>> Oh, I don't know.  I didn't think he was trying to express any
>> particular attitude; I thought he was trying to make fun of you.
>> For my part, he succeeded; I just about snorted my lunch all over
>> my laptop.
>>
>> In particular, your stance appears illogical, unreasonable,
>> unfounded, and impervious to reason.  Very machine-like, no?
>
> No. I am joking, too. We just have a finer sense of humour here, on
> the other side of the ocean.

Ah, excellent!

> And we don't eat where we work.

Excellent!  Wonderful!  I don't either.

-- L
From: Ivan Boldyrev
Subject: Re: Pricing ACL
Date: 
Message-ID: <8lpk73-n1j.ln1@ibhome.cgitftp.uiggm.nsc.ru>
On 9328 day of my life david tolpin mobile wrote:
>>    For my part, I'm just waiting for my toaster to finish.
>> Maybe I should get a higher-tech toaster that could multitask
>> and write letters to C.L.L. Maybe I should design such a toaster
>> and give one to Duane. And to you. :)
>
> I doubt that you can; in particular, one that will suit both Duane and
> me. The cause of that is that such toaster will have free will; and
> this is beyond current capacities even of a founder of Franz Inc.

Software is already written by Arthur Lemmens:
Message-ID: <················@news.xs4all.nl>

(defun cll-regular (cll)
 (let ((replies '("Nonsense!" "Poppycock!"  "Bullshit!")))
   (loop (let ((message (read-message cll)))
           (declare (ignore message))
           (write (elt replies (random (length replies)))
                  cll)))))


-- 
Ivan Boldyrev

                                       XML -- new language of ML family.
From: Julian Stecklina
Subject: Re: Pricing ACL
Date: 
Message-ID: <86lkyikqwy.fsf@dellbeast.localnet>
···················@gmail.com writes:

> ACL works with a very complete feature set on many platforms, and the
> complete
> feature set behaves differently with other lisp implementations. You
> are locked in.

Uh? Just because Foo Lisp's feature Z works on Linux and is broken on MacOS,
Franz Inc. wants to lock you into using ACL?

Regards,
-- 
Julian Stecklina

When someone says "I want a programming language in which I
need only say what I wish done," give him a lollipop. - Alan Perlis
From: Coby Beck
Subject: Re: Pricing ACL
Date: 
Message-ID: <gbZof.8430$ic1.1572@edtnps90>
<···················@gmail.com> wrote in message 
·····························@g44g2000cwa.googlegroups.com...
...
> When I sent subscription request to the allegro users mailing list, I
> got a confirmation reply from a human. In 2005, it means that Franz is
> either so smart that they have an AI software that talks like a man, or
> that they are 20 years behind in customer relations. I suspect the
> latter.

Not all "advances" in customer service are actually better for the customer.

> I want a users list managed by a robot; because its a kind of job robots 
> do well and they don't get sick

I am very surprised that anyone would feel that way!  Live and learn I 
guess...I would still be surprised if you are not in a vast minority.

-- 
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: ···················@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134894593.221872.197670@z14g2000cwz.googlegroups.com>
> > I want a users list managed by a robot; because its a kind of job robots
> > do well and they don't get sick
>
> I am very surprised that anyone would feel that way!  Live and learn I
> guess...I would still be surprised if you are not in a vast minority.

Do you think that the majority of users is willing to pay high license
fees for  a human mailing list managing robot that responds after two
days of the request? Just because it's how the management of Franz
undestands customer care?
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <AQ9pf.1193$GW1.1180@news-wrt-01.rdc-nyc.rr.com>
···················@gmail.com wrote:
>>>I want a users list managed by a robot; because its a kind of job robots
>>>do well and they don't get sick
>>
>>I am very surprised that anyone would feel that way!  Live and learn I
>>guess...I would still be surprised if you are not in a vast minority.
> 
> 
> Do you think that the majority of users is willing to pay high license
> fees for  a human mailing list managing robot that responds after two
> days of the request? Just because it's how the management of Franz
> undestands customer care?
> 

Franz has a mailing list?

kt
From: ············@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134918392.757672.235990@z14g2000cwz.googlegroups.com>
> Franz has a mailing list?
>

Strictly speaking, they don't. But they have the following page on
their site, inviting users to participate in an open online forum for
ACL users:

http://www.franz.com/support/acl.forum.lhtml
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <I3hpf.4964$Ed.1729@news-wrt-01.rdc-nyc.rr.com>
············@gmail.com wrote:
>>Franz has a mailing list?
>>
> 
> 
> Strictly speaking, they don't. But they have the following page on
> their site, inviting users to participate in an open online forum for
> ACL users:
> 
> http://www.franz.com/support/acl.forum.lhtml
> 

Looks like one or two threads a month based on a casual scan of the log. 
  Might explain why the cobbler's children are going without shoes in re 
list maintenance.

kt
From: Coby Beck
Subject: Re: Pricing ACL
Date: 
Message-ID: <6Zjpf.12108$wg4.10221@edtnps84>
<···················@gmail.com> wrote in message 
·····························@z14g2000cwz.googlegroups.com...
>> > I want a users list managed by a robot; because its a kind of job 
>> > robots
>> > do well and they don't get sick
>>
>> I am very surprised that anyone would feel that way!  Live and learn I
>> guess...I would still be surprised if you are not in a vast minority.
>
> Do you think that the majority of users is willing to pay high license
> fees for  a human mailing list managing robot that responds after two
> days of the request? Just because it's how the management of Franz
> undestands customer care?

Well, now that depends entirely on how you define "non seqitur", doesn't it?

-- 
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: jayessay
Subject: Re: Pricing ACL
Date: 
Message-ID: <m3irtmgvvk.fsf@rigel.goldenthreadtech.com>
···················@gmail.com writes:

> Allegro Common Lisp is such a tool that encourages  the developer
>   - to write code which is hard to use with other implementations
> later,

Only if you're incompetent - are you saying that's what you are???


>   - to use proprietory libraries instead of vendor-neutral ones;

Only if it makes sense - are you saying you can't understand this?
For example, what "vendor-neutral" lib out there can do anything close
to what AllegroCache can do with the same transparency and ease of
effort?  There are other examples.


> and the manager to establish binding relations with Franz in such a
> way, that the very amount of effort spent makes switching to another
> implementation, or using more than one, undesirable.

Again, only if you are incompetent.


... remaining weird diatribe snipped ...

So, what meds are you normally on, which you apparently forgot to
take?


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: ············@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134936569.099529.211270@g44g2000cwa.googlegroups.com>
> > Allegro Common Lisp is such a tool that encourages  the developer
> >   - to write code which is hard to use with other implementations
> > later,
>
> Only if you're incompetent - are you saying that's what you are???
>

I am incompetent in the same way as any other one is. Basically, I have
three options
  - a tool that encourages me to use Common Lisp, in its current shape
  - a tool that tries to serve as a validator of adherence to the
specification, making impossible the use of certain constructs because
their behavior is undefined;
  - a tool that provides and encourages to use a language which is an
extension/dialect of Lisp resembling Common Lisp.

ACL belongs to the latter group. One way to learn a language is to read
the program code in this language and try to understand it. Open-source
bits of ACL are not written in Common Lisp.

> Only if it makes sense - are you saying you can't understand this?
> For example, what "vendor-neutral" lib out there can do anything close
> to what AllegroCache can do with the same transparency and ease of
> effort?  There are other examples.

Franz is not a vendor of AllegroCache. It is a vendor of an
implementation of Common Lisp which includes a powerful library using
ACL extensions all the way through; you cannot buy a version of
AllegroCache for CMUCL.

> > and the manager to establish binding relations with Franz in such a
> > way, that the very amount of effort spent makes switching to another
> > implementation, or using more than one, undesirable.
>
> Again, only if you are incompetent.

I suspect that you didn't read my words. I have been trying to say that
a company executive engaged into a deal with Franz will insist on
continuing relations with Franz because there is
so much effort already spent on establishing them.

> So, what meds are you normally on, which you apparently forgot to
> take?

I don't think it is an appropriate remark.

David
From: jayessay
Subject: Re: Pricing ACL
Date: 
Message-ID: <m364pmgmsb.fsf@rigel.goldenthreadtech.com>
·············@gmail.com" <············@gmail.com> writes:

> > > Allegro Common Lisp is such a tool that encourages  the developer
> > >   - to write code which is hard to use with other implementations
> > > later,
> >
> > Only if you're incompetent - are you saying that's what you are???
> >
> 
> I am incompetent in the same way as any other one is. Basically, I have
> three options
>   - a tool that encourages me to use Common Lisp, in its current shape

There likely aren't any of these.


>   - a tool that tries to serve as a validator of adherence to the
> specification, making impossible the use of certain constructs
> because their behavior is undefined;

This option is basically the same as the first.


>   - a tool that provides and encourages to use a language which is
> an extension/dialect of Lisp resembling Common Lisp.

There likely aren't any of these either - what does it mean for a
_tool_ to "encourage"???


> ACL belongs to the latter group.

Only in your really weird world.


> the program code in this language and try to understand it. Open-source
> bits of ACL are not written in Common Lisp.

Open source bits of _many_ Lisp libraries aren't written "in Common
Lisp" as meaning "that and _only_ that which is in the ANSI
specification".  And???


> Franz is not a vendor of AllegroCache. It is a vendor of an

Well, you're just wrong on this one.  You don't have to buy
AllegroCache to use Allegro CL.  Just like you don't have to buy
ORBlink, et.al.  You can purchase them from Franz though.  Which
means, what? oh yeah - that Franz is a _vendor_ of said items.  Just
like IBM is vendor of, oh, say, WebSphere or MS is a vendor of MSWord.
That MS makes the OS on which MSWord runs in no way makes it any less
a vendor of MSWord as it is a vendor of Windows.

You really have a _very_ strange view of of this stuff.


> I suspect that you didn't read my words. I have been trying to say
> that a company executive engaged into a deal with Franz will insist
> on continuing relations with Franz because there is so much effort
> already spent on establishing them.

First, that's not at all what you previously have said.  But even so,
this point you make here is totally orthogonal to any technology _or_
pricing issues at all.  So, it seems completely irrelevant.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: ············@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134939524.231734.18620@g43g2000cwa.googlegroups.com>
> >   - a tool that encourages me to use Common Lisp, in its current shape
>
> There likely aren't any of these.

LispWorks, CMUCL, OpenMCL

> >   - a tool that tries to serve as a validator of adherence to the
> > specification, making impossible the use of certain constructs
> > because their behavior is undefined;
>
> This option is basically the same as the first.

It's SBCL, basically.

> >   - a tool that provides and encourages to use a language which is
> > an extension/dialect of Lisp resembling Common Lisp.
>
> There likely aren't any of these either - what does it mean for a
> _tool_ to "encourage"???

It's ACL. For a tool to encourage means to make certain behavior
particularly convenient. For example, Lisp in general encourages to
develop in small bits and frequently use REPL to try and explore.

> Open source bits of _many_ Lisp libraries aren't written "in Common
> Lisp" as meaning "that and _only_ that which is in the ANSI
> specification".

Many things in ACL-related sources are written using special forms
which are not in the ANSI specifications. They can be programmed as
macros for portability; but the samples do not encourage to write in
easy-to-understand Common Lisp.

> > Franz is not a vendor of AllegroCache. It is a vendor of an
>
> Well, you're just wrong on this one.  You don't have to buy
> AllegroCache to use Allegro CL.  Just like you don't have to buy
> ORBlink, et.al.

I didn't say that one would have to buy AllegroCache to use ACL;
instead, I said
that one has to buy ACL to use AllegroCache; and that's why Franz, in
my opinion,
encourages to write programs which are hard to port between
implementations.

> > I suspect that you didn't read my words. I have been trying to say
> > that a company executive engaged into a deal with Franz will insist
> > on continuing relations with Franz because there is so much effort
> > already spent on establishing them.
>
> First, that's not at all what you previously have said.  But even so,
> this point you make here is totally orthogonal to any technology _or_
> pricing issues at all.  So, it seems completely irrelevant.

>From the very beginning I had explained that neither pricing nor
technology I was going to talk about. What was the subject of my
remarks is the marketing policy of Franz Inc., of which both the
pricing and technology are but consequences. And the note above
explains how another technique by Franz works.

David Tolpin
From: jayessay
Subject: Re: Pricing ACL
Date: 
Message-ID: <m31x09gh14.fsf@rigel.goldenthreadtech.com>
·············@gmail.com" <············@gmail.com> writes:

> > >   - a tool that encourages me to use Common Lisp, in its current shape
> >
> > There likely aren't any of these.
> 
> LispWorks, CMUCL, OpenMCL

They are all different outside of the ANSI core.  Just like ACL.  So,
no, these are not examples of what you want.


> > There likely aren't any of these either - what does it mean for a
> > _tool_ to "encourage"???
> 
> It's ACL. For a tool to encourage means to make certain behavior

Weird. But if it floats your boat go ahead and keep on believing it.
It doesn't really matter at all.


> > Open source bits of _many_ Lisp libraries aren't written "in Common
> > Lisp" as meaning "that and _only_ that which is in the ANSI
> > specification".
> 
> Many things in ACL-related sources are written using special forms
> which are not in the ANSI specifications.

As I say, that's true of a lot of non ACL stuff as well.  Just look at
all the implementation dependent feature checking code in various
available non Franz produced source.


> They can be programmed as macros for portability; but the samples do
> not encourage to write in easy-to-understand Common Lisp.

I'm guessing you are really whinning about if* here.  Thing is, it's
implementation is openly available and appears to even be public
domain.  I never use it myself, and it has never been an issue one way
or another.


> > > Franz is not a vendor of AllegroCache. It is a vendor of an
> >
> > Well, you're just wrong on this one.  You don't have to buy
> > AllegroCache to use Allegro CL.  Just like you don't have to buy
> > ORBlink, et.al.
> 
> I didn't say that one would have to buy AllegroCache to use ACL;

You said they were not a vendor of AllegroCache.  They are.  Just as
MS is a vendor of MSWord.  You are just plain wrong on this.  And it
is strange that you are trying to pretend otherwise.


> pricing and technology are but consequences. And the note above
> explains how another technique by Franz works.

I'm not convinced that _anything_ you have said "explains" _anything_.

Bottom line: if you don't want to use Franz as a vendor, well duh,
don't!  OTOH, don't try to claim that your choice indicates some sort
"one true vision of correct vendor behavior" or whatever.  Or that
your weird ideological rants show that some vendor is "harming Lisp"
or whatever.  It's just plain outright nonsense and you need to get a
grip on some reality.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: ···················@gmail.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1135012725.429900.16130@g14g2000cwa.googlegroups.com>
> Bottom line: if you don't want to use Franz as a vendor, well duh,
> don't!  OTOH, don't try to claim that your choice indicates some sort
> "one true vision of correct vendor behavior" or whatever.  Or that
> your weird ideological rants show that some vendor is "harming Lisp"
> or whatever.  It's just plain outright nonsense and you need to get a
> grip on some reality.

Hi Jayessay,

in my messages to comp.lang.lisp, I didn't say that "some vendor is
harming Lisp"; you are mistaken. Nor do I claim that my choice
indicates that my choice indicates some sort "one true vision of
correct vendor behavior".

In my original message, to which you replied and which you quoted in
your reply, I had explicitely stated that:

> I agree that the pricing is appropriate. And that the marketing
> strategy of Franz is successful. It is just not successful with me; I
> want an implementation that makes it easy to switch to another one --
> and if it does not, I don't pay. I want a users list managed by a
> robot; because its a kind of job robots do well and they don't get sick
> or go to vacations. And, yes, as a developer, I want pricing policy
> that does not make my manager think that his effort spent on tools
> acquisition and revenue reporting improves the product quality -- this
> is a wrong assumption. 

David Tolpin
From: Coby Beck
Subject: Re: Pricing ACL
Date: 
Message-ID: <dzCof.2062$ic1.1931@edtnps90>
<············@reillyhayes.com> wrote in message 
·····························@g44g2000cwa.googlegroups.com...
> >Millions of dollars? How in all worlds do you come to that number?
>
> Franz charges a percentage of revenue for commercial software
> developers.  If your revenues are $100 million per year, they are
> charging you between $4 million and $10 million per year.  For
> comparison, 10 engineers on $50,000 a seat CAD stations comes to half a
> million a year.  That $50,000 looks pretty cheap by comparison, doesn't
> it?

I find all these hypothetical business scenarios such a dubious way of 
arguing this kind of topic.  It is worse than armchair quarter backing, it 
is armchair quarterbacking a game you aren't even watching!  (Yet, here I am 
:-/

The above scenario is very naive.  If you are running a $100M company, all 
your business decisions run the risk of losing $100M per year.  A $4M 
dollars investment to ensure that risk is minimized is worth it.  The kind 
of thinking above is called "penny wise but pound foolish".

> Franz makes money because their pricing scheme is a sucker bet.  In
> accepting Franz's pricing scheme, their customers are betting against
> their own future success.  You know, it isn't a bad business model
> they've got there.  They've got the best kind of rubes in the world:
> people who assume that because they are smart about one thing
> (technology) that they're smart about another (business).

This is a ridiculous and ignorant thing to say.  I hope you are a 
multi-millionaire business success story and this is what gives you such 
confidence and contempt for other peoples business decisions.  But even so, 
different things work for different circumstances.

It is ironic for me to defend Franz's position (well, only by implication 
"an enemy of my enemy is my friend" kind of thing) because I was involved at 
one time in the decision to buy or not buy ACL and we didn't for many of the 
reasons people are throwing around.  I just think people *really* confuse 
"it isn't right for me" with "it isn't right".

-- 
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: Richard J. Fateman
Subject: Re: Pricing ACL / getting bored, too, so here's something different
Date: 
Message-ID: <dnv289$cvc$1@agate.berkeley.edu>
Say that you really really like Allegro CL.
You have revenues of $100 million a year that
depend on Allegro CL.
You don't like to see money leave your hands,
and therefore don't like paying royalties.

So buy Franz Inc.  You can then control the
pricing to other companies  (in fact you can
decrease royalties, drop them to zero, make
the code open source,  or on the dark side,
you could raise royalties or even stop
distribution outside your company.).
From: Don Geddis
Subject: Re: Pricing ACL / getting bored, too, so here's something different
Date: 
Message-ID: <874q58sv40.fsf@geddis.org>
"Richard J. Fateman" <·······@eecs.berkeley.edu> wrote on Fri, 16 Dec 2005:
> Say that you really really like Allegro CL.  You have revenues of $100
> million a year that depend on Allegro CL.  So buy Franz Inc.

Revenues aren't the same as profits.  You may be a breakeven business with
thin margins at $100M/year in revenues.  That doesn't mean you have $100M in
cash to spend on buying other businesses.  And it could mean that royalties of
a few million dollars spell the difference between success and failure.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Q. How do you attract a vegetarian?
A. Make a noise like a wounded vegetable.
From: ············@reillyhayes.com
Subject: Re: Pricing ACL / getting bored, too, so here's something different
Date: 
Message-ID: <1134794820.371844.72550@o13g2000cwo.googlegroups.com>
 Don Geddis wrote:
> Revenues aren't the same as profits.  You may be a breakeven business with
thin margins at $100M/year in revenues.

Exactly!  Thank you.  The companies that DO have a healthy profit at
$100 million in revenue do so by watching their margins closely.

Richard J. Fateman wrote:
> Say that you really really like Allegro CL.  You have revenues of $100
> million a year that depend on Allegro CL.

My point is that it's unlikely that anybody ever will have revenues of
$100 million that depend on Allegro.  There are hundreds of other
technologies to build products with.  The decisions regarding which
technology to use are, in the end, all economic decision.  LISP's
technical advantages can yield economic advantages, but the overall
decision balances that against the long term economic impact.

One thing I should be clear about.  I didn't pick $100 million because
I thought it was at all representative of the revenue of Franz
customers.  I picked it because it is consistent with the aspirations
of VC investors.  Franz's pricing policy may in fact work out to be a
great deal for moderately successful companies.  And they may be very
willing to change their policy in the face of a big successful
customer.

Imagine you are a small start-up running on friend and family funding
while you get your product started.  You have no leverage with anybody
at this point, so the deal you get is likely to be close to Franz's
rack prices.  But you're convinced that you can get there faster with
ACL, so you sign the document.

Move the clock forward 9 months and you've got a working prototype
you're showing to VC's.  They're all impressed, but none of them will
like the contract you've signed.  Remember, they're really betting
you'll be a smashing success, so the scenario they're looking at is
closer to $100 million than $5 million.  Moderate success isn't a lot
better than failure to that crowd.  They're judging you by the chance
you'll hit a home run and by what you'll be worth if you do hit a home
run.

Now you've got 3 choices: 1) Tell the VC's that ACL is critical and
that you're sure you'll be able to negotiate a better deal, 2) Try to
renogotiate in advance of funding, or 3) rewrite the product using
other tools.

None of this applies to modestly-sized or organically-funded companies.
 But the VC's are in charge of the purse-strings for a huge number of
start-ups.

I really AM bored with this thread now.  I don't have anything against
Franz.  I don't know if their pricing is optimal for them or not.  I
don't really care.  My only point is that their pricing is probably not
very good for helping LISP break out of the box it's been in for 20
years.
From: Kenny Tilton
Subject: Re: Pricing ACL / getting bored, too, so here's something different
Date: 
Message-ID: <sVPof.21$GW1.20@news-wrt-01.rdc-nyc.rr.com>
············@reillyhayes.com wrote:

> I really AM bored with this thread now.  I don't have anything against
> Franz.  I don't know if their pricing is optimal for them or not.  I
> don't really care.  My only point is that their pricing is probably not
> very good for helping LISP break out of the box it's been in for 20
> years.
> 

So now Franz is responsible for Lisp's small market share. I love it. 
Who says this thread is boring?

kt
From: Michael
Subject: Re: Pricing ACL / getting bored, too, so here's something different
Date: 
Message-ID: <slrndq8f64.d3r.malus42@yahoo.com>
On 2005-12-17, Kenny Tilton <·············@nyc.rr.com> wrote:
>  ············@reillyhayes.com wrote:
> 
> > I really AM bored with this thread now.  I don't have anything against
> > Franz.  I don't know if their pricing is optimal for them or not.  I
> > don't really care.  My only point is that their pricing is probably not
> > very good for helping LISP break out of the box it's been in for 20
> > years.
> > 
> 
>  So now Franz is responsible for Lisp's small market share. I love it. 
>  Who says this thread is boring?

You need to learn how to read Kenny. He didn't say Franz was responsible,
just that they aren't helping.
From: Kenny Tilton
Subject: Re: Pricing ACL / getting bored, too, so here's something different
Date: 
Message-ID: <I6Yof.1019$GW1.89@news-wrt-01.rdc-nyc.rr.com>
Michael wrote:
> On 2005-12-17, Kenny Tilton <·············@nyc.rr.com> wrote:
> 
>> ············@reillyhayes.com wrote:
>>
>>
>>>I really AM bored with this thread now.  I don't have anything against
>>>Franz.  I don't know if their pricing is optimal for them or not.  I
>>>don't really care.  My only point is that their pricing is probably not
>>>very good for helping LISP break out of the box it's been in for 20
>>>years.
>>>
>>
>> So now Franz is responsible for Lisp's small market share. I love it. 
>> Who says this thread is boring?
> 
> 
> You need to learn how to read Kenny. He didn't say Franz was responsible,
> just that they aren't helping.
> 

As Edmund Burke said, "The only thing necesssary for the triumph of Java 
is for good Lisp companies to overprice their proprietary 
implmentations." I think I have that right.

kt
From: jayessay
Subject: Re: Pricing ACL / getting bored, too, so here's something different
Date: 
Message-ID: <m3ek4agvny.fsf@rigel.goldenthreadtech.com>
············@reillyhayes.com writes:

> don't really care.  My only point is that their pricing is probably not
> very good for helping LISP break out of the box it's been in for 20
> years.

LOL!!


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: Peter Seibel
Subject: Re: Pricing ACL / getting bored, too, so here's something different
Date: 
Message-ID: <m28xukz9vc.fsf@gigamonkeys.com>
"Richard J. Fateman" <·······@eecs.berkeley.edu> writes:

> Say that you really really like Allegro CL.  You have revenues of
> $100 million a year that depend on Allegro CL.  You don't like to
> see money leave your hands, and therefore don't like paying
> royalties.
>
> So buy Franz Inc.  You can then control the pricing to other
> companies (in fact you can decrease royalties, drop them to zero,
> make the code open source, or on the dark side, you could raise
> royalties or even stop distribution outside your company.).

Better watch it; if there are any tabloid bloggers on planet.lisp.org,
we're likely to see a headline: "Franz Board Members Looking for an
Exit Strategy". ;-)

-Peter

-- 
Peter Seibel           * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp  * http://www.gigamonkeys.com/book/
From: Greg Menke
Subject: Re: Pricing ACL
Date: 
Message-ID: <m3zmn18bg5.fsf@athena.pienet>
Peter Herth <·······@t-online.de> writes:

> Don Geddis wrote:
> 
> > And then way at the end is a column for programming language costs.
> > Every
> > line shows a few thousand dollars or less (some are free), except Allegro CL,
> > where the total cost to the project would be more on the order of millions of
> > dollars.
> >
> 
> Millions of dollars? How in all worlds do you come to that number?
> Allegro certainly isn't a low-cost software, but Franz offers several
> license models, so the chance is that you can get a deal that fits your
> projects size and requirements.
> Of course, with everything you buy, YOU have to decide how to spend your
> money. If using Allegro does not give you an advantage compared to lets
> say, use Python, then every single buck spend on Allegro is wasted. On
> the other side, there are projects, where using Allegro does give an
> advantage, up to the point that paying for Allegro saves you a lot of
> money.
> 
> Peter

Not to mention the CAD and EDA software seat licensing & support costs
dwarf the Allegro cost.  Unless its a software-only product, in which
case we're not talking about engineering...  ;)

Gregm
From: jayessay
Subject: Re: Pricing ACL
Date: 
Message-ID: <m3mzj0hgje.fsf@rigel.goldenthreadtech.com>
Don Geddis <···@geddis.org> writes:

> jayessay <······@foo.com> wrote on 15 Dec 2005 15:4:
> > How is this different from just about any other case of OEM
> > considerations?
> 
> Well, of course it isn't unreasonable in principle.

Exactly.


> But compared to other alternatives, it does seem way out of the ballpark.

Only in those cases where it would in fact make no sense.  All such
cases need to be decided individually.  Of course, if your "reasoning"
is rooted in ideology all bets are off...


> And then way at the end is a column for programming language costs.  Every
> line shows a few thousand dollars or less (some are free), except Allegro CL,
> where the total cost to the project would be more on the order of millions of
> dollars.

No, you have no idea about this until you actually negotiate with the
OEM.  And actually see what your potential sales really are.  That's
how this sort of stuff actually works in the real world.  I know a lot
of people don't think software is part of the real world and that
nothing to do with it conforms to the realities thereof.  But
believing it's so doesn't make it so.


> Is that single offering from that single supplier really so much better than
> all the alternatives?  I suppose it might be, but that would be a tough
> argument to try to win during the discussion.

Again, it depends and it may be an easy thing to see - one way or
another.  One key thing that producers of real products (you know the
things that really count - cars, furniture, clothing, food, aircraft,
etc., etc.) understand is that situations like this are not a zero sum
game, and that negotiating with an OEM that will provide you with
something that gets you directly up to speed in providing _your_ true
value add, is good business sense.


> > It's hard to understand how any of this follows in any sort of real
> > business scenario - especially the kind you have put forth where you
> > are selling millions of copies.  What do these sort of games go for
> > these days?  $50.00?  $30.00?  So, if a royalty of say 20-50 _cents_
> > per copy were involved, how would that prevent the whole thing from
> > happening?
> 
> So you're imagining royalties at around 1%?

First, you are very confused here - you seem to be thinking that all
that $50.00 or $30.00 is going to the producer of the good.  No way.
Most of it, typically 2/3 or more, will go into the pockets of the
distributers.  That's just the way things work with commodity stuff.
In this case, that means you would be lucky to get $10-$12 of the
price, the remaining $38-$40 would be going to others in the "food
chain".  So, of the 100s of millions of dollars your game might
actually generate overall, you will be lucky to see a couple tens of
millions, and a supplier expecting 2-3% might see 500-750K or so.
Those aren't "alarming" numbers by any reasonable understanding.  In
this sort of scenario (commodity wares), and this one in particular,
most of your expenses will be going to marketing and advertising.
Those will take a _much_ bigger chunk of your revenues.


> around 1%?  And where did you get numbers like that?

As you see your assumption here is just wrong.  Secondly, I base some
of this on actual past negotiations.


> In any case, even you would admit that the cost for going with Franz
> would be on the order of millions

Millions?  Maybe, but highly unlikely.  Several hundreds of thousands?
Yeah, could be.  And if it were millions, you should be _very_ happy
as you would be making 100s of millions.  Don't get confused by zero
sum thinking here.


> whereas the cost for alternatives is thousands.

Of course, they may not be viable alternatives or smart alternatives.
Or maybe they are - in which case go for them.  Another thing that
could be a very big deal here is time to market.  You don't want to be
trying to explain to your investors that you just spent the first few
months trying to figure out how to get your choice of platform to do
X, Y, Z, ..., in the various scenarios you need it to.  That will go
over like a lead balloon.  Again, fixating on this zero sum thing can
really lead you astray.


> Perhaps there's benefit to compensate for the costs, but you're
> going to need to find a whole lot of it to make the decision
> worthwhile.

One business's "whole lot" is another's "obvious cost of doing
business".


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <WZjof.12198$Ys4.3289@twister.nyc.rr.com>
Don Geddis wrote:
> 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.

Are you saying that on the basis of actual unsuccessful negotiations 
with Franz? If not, how do you know what they would want for a low-end 
retail product?

Disclaimer: I have started but never finished such negotiations with 
Franz, so whaddoiknow.

Hey, why argue? Use Lispworks! :)

krnny
From: John Thingstad
Subject: Re: Pricing ACL
Date: 
Message-ID: <op.s1uf18sxpqzri1@mjolner.upc.no>
On Thu, 15 Dec 2005 21:03:02 +0100, Kenny Tilton  
<·············@nyc.rr.com> wrote:


>
> Hey, why argue? Use Lispworks! :)
>
> krnny

I could have sworn you use Allegro Common Lisp..

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <aXlof.7956$i1.2882@news-wrt-01.rdc-nyc.rr.com>
John Thingstad wrote:
> On Thu, 15 Dec 2005 21:03:02 +0100, Kenny Tilton  
> <·············@nyc.rr.com> wrote:
> 
> 
>>
>> Hey, why argue? Use Lispworks! :)
>>
>> krnny
> 
> 
> I could have sworn you use Allegro Common Lisp..
> 

I was talking to anyone not happy with their pricing.

I use AllegroCL, but nothing proprietary of theirs. If I decide I like 
AllegroCache, then I have a problem. /Then/ I will learn more. OTOH, I 
am looking at Elephant now, another persistent CLOS. And so it goes...

kt
From: Ulrich Hobelmann
Subject: Re: Pricing ACL
Date: 
Message-ID: <40due6F19p06gU1@individual.net>
Don Geddis wrote:
> 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.

So what's the problem?  Royalties are a per-unit cost, just like 
delivery costs.

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

But why not?  Having a strong, supported Lisp available might boost 
programmer productivity significantly.  So you save lots of money on 
development, which either increases your final product margins, or makes 
the existence of such margins possible in the first place.  What you pay 
is a few percent of the end price, cutting your margins a bit smaller. 
But what's a few percent added to the cost, if your development costs 
are maybe HALF with Lisp?

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

Well, definitely a fixed cost would be more attractive than royalties, 
if you intend to ship many units of your software.  But OTOH maybe Franz 
would be open to negotiations in that case (who knows?), and OTOH even 
royalties might still be worth it, if it allows you to use Lisp.  The 
customer chooses, and there are other Lisps and options out there, with 
different costs attached to them (buying Lispworks, or adapting an 
open-source Lisp to deliver all the features you want).

-- 
If you have to ask what jazz is, you'll never know.
	Louis Armstrong
From: Cameron MacKinnon
Subject: Re: Pricing ACL
Date: 
Message-ID: <BMCdnSa9oN_07T_eRVn-vA@rogers.com>
Disclaimer: I'm not a past or current Franz customer. My analysis of 
their specific business strategy may be wrong. In fact, I've revised my 
post and replaced most vendor/product names with placeholder variables.


Don Geddis wrote:

> Take a very simple example.  Let's say I want to develop a consumer video game
> on a PC.

'...on a PC': Good qualifier. It's my understanding that if your game 
ran on a console, you'd have to pay per-unit royalties to the console 
manufacturer. That's a business model that many game developers have 
bought into. OTOH, if you're willing to put up with the hassle of 
supporting a few different operating system/language combinations and a 
multiplicity of CPUs/GPUs/sound cards/RAM sizes etcetera, Microsoft will 
provide you with free dev tools and runtimes, because their business 
model is to extract revenue from your customer when he purchases his 
computer.

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

It seems funny that you'd be cheese-paring with the runtime but 
spendthrift with the developer licenses. Below, you equate $product's 
runtime with free runtimes, so I suspect you'd equate $vendor's 
development environment with free IDEs, too. And if $vendor employed a 
similar pricing strategy for IDEs as my analysis of runtimes below, it 
might well be $10k/developer/year -- just to keep the riff-raff from 
taking up time they could be devoting to those of their customers who 
see the value added and are gladly willing to pay. I bet if $vendor 
offered developer seats at those prices with free runtimes, there'd be 
someone arguing passionately that they're being priced out of the market 
and that $vendor really has to drop their per-seat prices to compete 
with Eclipse.

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

You're equating the $product runtime with free alternatives. Obviously, 
if that's the case for your scenario, it may make sense to use the free 
ones. Obviously, $vendor's customers feel they're getting more from 
$product than they would from the free alternatives. If $vendor's 
customers make money, $vendor makes money, and if they don't, $vendor 
doesn't. Given that business model, it behooves $vendor to choose its 
customers wisely.

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

No. They're pricing *you* out of a development scenario. I saw part of 
an ad on TV the other day. IIRC it was selling hot tubs, and it ended 
with "starting from $3,000.00" (not even $2,999!) which is really a 
polite way of saying to prospects "If you're not willing to spend at 
least $3,000, don't bother calling -- you would only be wasting our 
time." By including that one line, they exclude a lot of prospects, 
which means their sales force can concentrate on high value leads, which 
means they can hire a better sales force in the first place, etcetera 
etcetera.

Similarly, I imagine $vendor's pricing model eliminates them having to 
deal with a lot of marginal, half-baked ideas and customers who want to 
screw their suppliers out of virtually all profit margin, which means 
$vendor can concentrate on providing excellent service to to customers 
who believe in mutually beneficial supplier relationships and who think 
they have a product idea with enough money on the table for everyone to 
get a share.

I really find this whole recurring topic bizarre. It involves people 
admitting in a public forum that they don't understand the (by no means 
unique or esoteric) pricing model of a successful company. Further, they 
go on to point out that alternatives exist (in the marketplace, not just 
in theory). And then they argue that this choice isn't good enough, that 
  the successful company should change its revenue model to be more like 
entities which don't even measure their success in terms of revenue.
From: Don Geddis
Subject: Re: Pricing ACL
Date: 
Message-ID: <87bqzgsw61.fsf@geddis.org>
Cameron MacKinnon <··········@clearspot.net> wrote on Fri, 16 Dec 2005:
> It seems funny that you'd be cheese-paring with the runtime but 
> spendthrift with the developer licenses.

Not at all.  The developer decision is choosing between free or a few hundred
or a few thousand dollars of expenditure.  The runtime decision is choosing
between free or a few hundred or a few million dollars of cost.  Clearly, one
decision isn't that important in a commercial project, and the other is.

> Obviously, $vendor's customers feel they're getting more from $product than
> they would from the free alternatives. If $vendor's customers make money,
> $vendor makes money, and if they don't, $vendor doesn't. Given that
> business model, it behooves $vendor to choose its customers wisely.

Of course.  I was merely noting that a not-uncommon scenario is really not in
Franz's reasonable customer set.  That's a decision they have made, which may
be surprising to some developers.

As you suggest, it's important to match up customers with suppliers who are
compatible.

>> 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.
>
> No. They're pricing *you* out of a development scenario.

Uh, no.  I'm not an example of the kind I was talking about.

The scenario is: a commercial team developing software where you have <10
developers, but >million end users.  For example, many venture captial-backed
startups.  It seems unlikely that Franz's Allegro CL will be a good choice
for such developers, not for technical reasons, but for pricing reasons.

> By including that one line, they exclude a lot of prospects, which means
> their sales force can concentrate on high value leads, which means they can
> hire a better sales force in the first place, etcetera etcetera.
> Similarly, I imagine $vendor's pricing model eliminates them having to deal
> with a lot of marginal, half-baked ideas and customers who want to screw
> their suppliers out of virtually all profit margin, which means $vendor can
> concentrate on providing excellent service to to customers who believe in
> mutually beneficial supplier relationships and who think they have a
> product idea with enough money on the table for everyone to get a share.

You're very confused.  I wasn't talking about "marginal, half-baked ideas",
or customers wanting "to screw their suppliers".

The startup scenario I outlined might really value Allegro CL's technical
qualities, really appreciate the high quality support that Franz offers, etc.
And be willing to pay for it: Almost any reasonable price that is a function
of developer seats and/or support time/effort would be acceptable.  Say
$5K/developer for 10 developers, i.e. $50,000 of real cash.  It's not really
accurate to call that "screwing their suppliers".

But it's also a long step from there, to significant runtime royalty revenues.
Just a totally different topic.

> It involves people admitting in a public forum that they don't understand
> the (by no means unique or esoteric) pricing model of a successful
> company.

Far from it.  I understand Franz's model perfectly.  I'm merely sad that it
doesn't include a business scenario that I'm interested in, so I would be
unable to take advantage of their excellent product and technical support.

> Further, they go on to point out that alternatives exist (in the
> marketplace, not just in theory). And then they argue that this choice
> isn't good enough, that the successful company should change its revenue
> model to be more like entities which don't even measure their success in
> terms of revenue.

I wasn't only comparing with open-source lisps.  There are other commercial
lisps, and there are other languages (C, C++, C#, Fortran, Java).  There's
nothing "wrong" with their choice, but Franz is surely an outlier among
programming language providers in not offering a royalty-free runtime.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
The only difference between me and a madman is that I am not mad.
	-- Salvador Dali
From: Cameron MacKinnon
Subject: Re: Pricing ACL
Date: 
Message-ID: <ETFpf.1270$1Y4.96893@news20.bellglobal.com>
Don Geddis wrote:
> Cameron MacKinnon <··········@clearspot.net> wrote on Fri, 16 Dec 2005:
> 
>>It seems funny that you'd be cheese-paring with the runtime but 
>>spendthrift with the developer licenses.
> 
> 
> Not at all.  The developer decision is choosing between free or a few hundred
> or a few thousand dollars of expenditure.  The runtime decision is choosing
> between free or a few hundred or a few million dollars of cost.  Clearly, one
> decision isn't that important in a commercial project, and the other is.

The key point you're making here is that you want an absolute, 
orders-of-magnitude reduction in the amount you pay to $vendor, not just 
a reallocation of the costs between upfront and per-unit. Clearly, a 
vendor that's paid up front (thereby incurring no risk of product 
failure) should earn less than one sharing in the risks of the 
enterprise. But orders of magnitude less?

> The scenario is: a commercial team developing software where you have <10
> developers, but >million end users.  For example, many venture captial-backed
> startups.  It seems unlikely that Franz's Allegro CL will be a good choice
> for such developers, not for technical reasons, but for pricing reasons.
...
> The startup scenario I outlined might really value Allegro CL's technical
> qualities, really appreciate the high quality support that Franz offers, etc.
> And be willing to pay for it: Almost any reasonable price that is a function
> of developer seats and/or support time/effort would be acceptable.  Say
> $5K/developer for 10 developers, i.e. $50,000 of real cash.

I can think of two ways of determining a "reasonable" price in the 
absence of per-unit royalties. One could look at the total per-seat cost 
of employing one's programmers (salary, benefits, equipment and real 
estate, share of overhead for management deadweight and IT support 
positions...), estimate the productivity gains to be had with $vendor, 
and split the savings. The added bonus for your enterprise is that 
changes to the size of your programming team aren't linear: Just as 
expanding a five member team to eight won't increase output by 60%, 
reducing an eight member team to five makes each member somewhat more 
productive.

Using an analysis like this, your offer of $5k/programmer seems low. If 
you're only getting a small bump in programmer productivity, maybe it 
doesn't make enough business sense to bother with. Of course, what we're 
doing here is pricing $vendor as a commodity supplier of productivity 
improvement tools, with no claim on our product's success. As well, to 
put that $5k number in perspective, you're almost certainly spending 
several times that on recruiting fees.

The second way of pricing is to work through $vendor's business model. 
If we allow $vendor a revenue of $300k/employee/year we can see that 
your offer of $50k/year funds one sixth of an employee-year for $vendor, 
and we can multiply $vendor's head count by six(!) to see how many 
customers like yours (a shop with ten developers) the vendor needs to 
have to remain viable. Don't expect a lot of "excellent product and 
technical support" as the vendor's front line technical reps will each 
be supporting hundreds of developers.


> I wasn't only comparing with open-source lisps.  There are other commercial
> lisps, and there are other languages (C, C++, C#, Fortran, Java).  There's
> nothing "wrong" with their choice, but Franz is surely an outlier among
> programming language providers in not offering a royalty-free runtime.

Sure, you can get a toolchain from Intel, but then you discover that 
your customers with AMD processors take an unreasonable speed hit[1]. 
You can get the toolchain du jour from the biggest vendor in the 
industry, but it isn't ported to Mac or UNIX for some strange reason. 
Java is its own reward. All of these toolchains are currently being 
marketed to advance interests in addition to their users' success in the 
marketplace. Put simply, these toolchain vendors' interests don't 
exactly align with their customers'.

In fact, the history of the compiler toolchain market is a history of 
independent vendors being purchased by larger entities (OS or chip 
makers) to further their interests. This doesn't change my analysis 
above: If you can get a subsidized toolchain from a different vendor, 
and the cost/benefit doesn't work in the original $vendor's favour, and 
you're willing to accept your new vendor's agenda, then by all means choose.

The EDA tools for chip design market offers an interesting contrast. 
Chip design is very similar to software design in that the upfront costs 
are large but the per-unit margins are high. As I understand it, 
however, CAD tool vendors have not been purchased by chip foundries to 
use in a vertical integration bid. Per-seat prices approach and surpass 
the salaries of the occupants of those seats.

Franz's pricing model virtually guarantees that their interests are 
aligned with their customers', far more so than per-developer or 
per-incident models. And they offer their technology on the same terms 
that VCs offer money on. Further, I'm guessing that Franz is flexible 
enough that if you can structure them a reasonable business proposition, 
they'll deal. As should be any VCs you're working with.

At any rate, I suspect Franz is an outlier among programming language 
providers in more ways that their pricing model. If there really were 
comparable tools with preferable pricing models, you and your ilk in 
this thread would just be using them. To me, this recurring thread is a 
strong indicator that many people see ACL as a competitive advantage 
with few if any peers, but one they'd naturally rather pay less for.


[1] -  AMD Alleges Intel Compilers Create Slower AMD Code,
http://yro.slashdot.org/article.pl?sid=05/07/12/1320202&tid=142&tid=118&tid=123
From: Förster vom Silberwald
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134639916.888884.266420@o13g2000cwo.googlegroups.com>
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: Richard J. Fateman
Subject: Re: Pricing ACL
Date: 
Message-ID: <dnsrek$2ps8$1@agate.berkeley.edu>
F�rster vom Silberwald wrote:
> 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.

Let me change your question to:

"Did Franz Inc ever take action (e.g. threaten a lawsuit) against a
company which was shipping ACL with its product, but failed to properly
report and pay royalties?"

Yes.

I don't know if my re-phrasing missed some nuance of your question.
If so, it was not deliberate.
> 
> 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: Steven M. Haflich
Subject: Re: Pricing ACL
Date: 
Message-ID: <OJNof.42766$D13.6492@newssvr11.news.prodigy.com>
Richard J. Fateman wrote:

> "A professional software company with a staff of experienced
> programmers,  18 years in the business, is maintaining the lisp system."

Minor quibble:

Most readers will know that Richard was involved in the founding of the
company, and that Richard was previously (and still is) involved in the
development of Macsyma/Maxima.  But it appears my friend Richard is
arithmetically challenged:  Franz was founded in 1984; it is now more
than 21 years in the business.

See http://www.franz.com/about/company.history.lhtml
From: Kenny Tilton
Subject: Re: Pricing ACL
Date: 
Message-ID: <2IInf.10949$Ys4.7371@twister.nyc.rr.com>
·········@gmail.com wrote:
> I wrote this as an email reply to R. Fateman, but I now feel like
> posting it. (BTW, Richard, you probably meant to post your message in
> the first place):
> 
> 
> All I can say is that "we will ask you for a %-age of your future
> profit once you have your product ready for shipping" is a total deal
> breaker.

That's fine. Apparently enough others feel differently that Franz is 
making a profit. With Lisp. Hello? Note that I am not saying there is 
anything wrong with your choice, just that Franz probably understands 
they will lose a lot of customers with their policy but do better enough 
with those who go for their terms to make up for it. The math probably 
has something to do with few people wanting to use Lisp, but thems that 
do /really/ needing it /and/ Franz's added value.

In brief, the market is perfect and Franz seems to be playing it well.

> 
> I don't want to hire lawyers NOW to negotate with Franz when I'm just
> developing the product, and I don't want to get f*** (pardon my french)
> by Franz if I delay the negotiations until later. Score 1 for other
> alternatives.
> 
> If I'm being unclear, image this situation: I'm Franz. You have naively
> developed a product using ACL, Allegro Cache, and other things that
> only I (Franz) can provide.
> You have two choices: pay whatever I ask you, or abandon the product
> (major rewrite included). 

Yep. Although I do not think Franz has all that much power to dictate. 
There is a downside to acting badly, however legal. But, no, I would not 
want to be negotiating at the last minute.

> 
> Now if you are smart, you'll never get into this situation by either
> (1) Never using Franz (LW, CMUCL) or (2) negotating the distribution
> terms in advance (laywers, etc.). For most people (1) seems like a
> better alternative.
> 

(3) If (1) is an option, you do not need their proprietary stuff. So 
develop with AllegroCL and deliver with something else.

If you absolutely need something they offer no one else does, that might 
make it a little easier to swallow them taking a cut.

Just my two.

kt
From: John Thingstad
Subject: Re: Pricing ACL
Date: 
Message-ID: <op.s1rdgfuopqzri1@mjolner.upc.no>
On Tue, 13 Dec 2005 22:38:14 +0100, <·········@gmail.com> wrote:

> I wrote this as an email reply to R. Fateman, but I now feel like
> posting it. (BTW, Richard, you probably meant to post your message in
> the first place):
>
>
> All I can say is that "we will ask you for a %-age of your future
> profit once you have your product ready for shipping" is a total deal
> breaker.
>
> I don't want to hire lawyers NOW to negotate with Franz when I'm just
> developing the product, and I don't want to get f*** (pardon my french)
> by Franz if I delay the negotiations until later. Score 1 for other
> alternatives.
>
> If I'm being unclear, image this situation: I'm Franz. You have naively
> developed a product using ACL, Allegro Cache, and other things that
> only I (Franz) can provide.
> You have two choices: pay whatever I ask you, or abandon the product
> (major rewrite included). As a business, I (Franz) will be inclined to
> ask you for just a little less than the cost of a major rewrite.
>
> Now if you are smart, you'll never get into this situation by either
> (1) Never using Franz (LW, CMUCL) or (2) negotating the distribution
> terms in advance (laywers, etc.). For most people (1) seems like a
> better alternative.
>

This is the response I got from Franz when asking about prising..

In addition, Franz Inc. offers two different types of Commercial licenses,  
based on how an application is used and
deployed.  Stand-Alone Application Systems or Client/Server Systems only  
used internally, require a Corporate End User
License. And all applications distributed to customers require a Value  
Added Reseller License. How do you plan on
distributing your application? How much do you charge for your  
application?  Does your application contain compilation
capability? Approximately how many applications will you distribute  
annually?
To give you an idea of the royalties, these ones vary between $150 and  
$800 for the Corporate End-User license, and
between 4% and 10% for the Value Adder Reseller license.

Hardly a question of being clueless about what to expect.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: ············@reillyhayes.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134736365.640132.317570@g14g2000cwa.googlegroups.com>
I would prefer not to use a language from a vendor that charges me a
per unit cost every time I ship something compiled with their tool.
But, I can accept that LISP is theoretically a "special case" and that
the runtime shipped with an application built with Allegro is much more
substantial than what is usually meant by the term "runtime".  That
said, this difference is defintely one of the things that alienates
people from using lisp.  The market has been moving away from that
model for 25 years.

What I cannot accept at all, and what guarantees that I would never use
Allegro to deliver a commercial product, is Franz's insistence on
charging a royalty based on my product revenue.  I know that the option
of doing things this way gives them a lot of flexibility on the bottom
of the market.  But it's death at the high-end of the market.  Let's
just say I went to a VC and I convince him that using LISP is a good
idea.  Now I have to tell him that by using Franz, I'm giving away 13%
to 33% of my net margin?  (assuming a healthy 30% net margin).  I will
be quickly shown the door.

The issue isn't that Allegro is expensive (it is).  The issue isn't
that it is not worth it (it can be, and I would use the product in an
end-user setting).  The issue is that the VC's want to make big bets
with big payoffs.  They'll fund an awful lot of up-front cost without
blinking an eye.  They'll even deal with things that increase your per
unit costs if you can justify it.  But in return, they want you to make
big margins as your volume increases and you start to be able charge a
premium for your product.  But the Franz approach sits there like a
leach, not only taking more as my unit sales increase, but taking more
as I move my prices up.

If I can convince a VC that Allegro is the fastest way into the market,
the VC might let me develop a salable prototype using Allegro.  But
after that he's going to be all over me to rewrite it in something
else.  And you know what?  From his perspective, he's right.  The VC
business is all about front-loading expense in exchange for a shot at a
hefty return at the back-end.  A back-loaded pricing structure like
Franz's is the opposite of what they want to see their companies
agreeing to.

But Allegro makes your programmers three times as effective, you say.
Your development budget will be 33% of of what it would be without out
it.  That's great up front, but no longer relevant at the back-end.
The VC expects you to manage your long-term development costs by
offshoring your non-core development once your organization is big
enough to properly manage it.  I'd be surprised if you can effectively
offshore development in LISP.

By the way, this model hurts Franz too.  I won't say that I know a
couple of firms that have used Allegro as a development tool but
actually delivered their product using Lispworks and/or SBCL.  But I
won't deny it either.

Franz has managed to make money in a very tough market.  They're not a
lot of people buying LISP tools.  And maybe this model has let them
survive and make money where they otherwise would not have.  But being
on the wrong side of that VC equation just makes it that much harder to
run a business built on their tools.  And as the premier commercial
provider of LISP tools, this isn't just bad for them.  It's bad for
LISP.

-r

p.s. This was originally going to be a two sentence e-mail:  You can
increase my expenses if I think you're worth it, but keep your f---ing
hands off my revenue.  The only people who're going to get paid off of
my revenue are the ones who bring it in (by selling it).


John Thingstad wrote:
> On Tue, 13 Dec 2005 22:38:14 +0100, <·········@gmail.com> wrote:
>
> > I wrote this as an email reply to R. Fateman, but I now feel like
> > posting it. (BTW, Richard, you probably meant to post your message in
> > the first place):
> >
> >
> > All I can say is that "we will ask you for a %-age of your future
> > profit once you have your product ready for shipping" is a total deal
> > breaker.
> >
> > I don't want to hire lawyers NOW to negotate with Franz when I'm just
> > developing the product, and I don't want to get f*** (pardon my french)
> > by Franz if I delay the negotiations until later. Score 1 for other
> > alternatives.
> >
> > If I'm being unclear, image this situation: I'm Franz. You have naively
> > developed a product using ACL, Allegro Cache, and other things that
> > only I (Franz) can provide.
> > You have two choices: pay whatever I ask you, or abandon the product
> > (major rewrite included). As a business, I (Franz) will be inclined to
> > ask you for just a little less than the cost of a major rewrite.
> >
> > Now if you are smart, you'll never get into this situation by either
> > (1) Never using Franz (LW, CMUCL) or (2) negotating the distribution
> > terms in advance (laywers, etc.). For most people (1) seems like a
> > better alternative.
> >
>
> This is the response I got from Franz when asking about prising..
>
> In addition, Franz Inc. offers two different types of Commercial licenses,
> based on how an application is used and
> deployed.  Stand-Alone Application Systems or Client/Server Systems only
> used internally, require a Corporate End User
> License. And all applications distributed to customers require a Value
> Added Reseller License. How do you plan on
> distributing your application? How much do you charge for your
> application?  Does your application contain compilation
> capability? Approximately how many applications will you distribute
> annually?
> To give you an idea of the royalties, these ones vary between $150 and
> $800 for the Corporate End-User license, and
> between 4% and 10% for the Value Adder Reseller license.
>
> Hardly a question of being clueless about what to expect.
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Pascal Costanza
Subject: Re: Pricing ACL
Date: 
Message-ID: <40fttqF19oahfU1@individual.net>
············@reillyhayes.com wrote:

> What I cannot accept at all, and what guarantees that I would never use
> Allegro to deliver a commercial product, is Franz's insistence on
> charging a royalty based on my product revenue.

This thread is very boring.

a) How do you know that Franz insists on charging such royalties? Have 
you asked them?

b) Why do you think discussing this in c.l.l will change anything?


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: ············@reillyhayes.com
Subject: Re: Pricing ACL
Date: 
Message-ID: <1134748190.536454.206590@g49g2000cwa.googlegroups.com>
> This thread is very boring.

Mostly true.  It's interesting to me because I think ACL is in many
ways a great product.  I do wonder if their business practices have
trapped them in a merely local optimum.

> How do you know that Franz insists on charging such royalties? Have
you asked them?

You are right, my statement is too strong.  I have received pricing
information from Franz consistent with the policies under discussion in
this thread.  I have not personally tried to negotiate with Franz, but
I am not aware of anybody who has succeeded in negotiating an
alternative arrangement.  This is clearly not a proof that they
"insist" on charging the royalties on this basis.  Change my comment to
read, "... is Franz's stated pricing policy of charging developers
based on their revenues."

>Why do you think discussing this in c.l.l will change anything?

I don't think it will anything at all.  But people talk about the
weather all the time with little expectation of changing it.
From: Raffael Cavallaro
Subject: Re: Pricing ACL
Date: 
Message-ID: <200512160902158930-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2005-12-16 08:31:37 -0500, Pascal Costanza <··@p-cos.net> said:

>> 
> 
> This thread is very boring.
> 
> a) How do you know that Franz insists on charging such royalties? Have 
> you asked them?


John Thingstad wrote earlier in this thread that Franz had outlined 
this pricing scheme when he asked. Note that I am not claiming that 
this is Franz's pricing scheme - I cannot and do not speak for Franz. 
I'm merely pointing out that John Thingstad wrote that Franz had 
outlined this pricing scheme here, two days ago:

"In addition, Franz Inc. offers two different types of Commercial 
licenses,  based on how an application is used and
deployed.  Stand-Alone Application Systems or Client/Server Systems 
only  used internally, require a Corporate End User
License. And all applications distributed to customers require a Value  
Added Reseller License. How do you plan on
distributing your application? How much do you charge for your  
application?  Does your application contain compilation
capability? Approximately how many applications will you distribute  annually?
To give you an idea of the royalties, these ones vary between $150 and  
$800 for the Corporate End-User license, and
between 4% and 10% for the Value Adder Reseller license."

This is where Reilly Hayes is getting his "13% to 33% of my net margin" 
figure, assuming 30% margin. (13% = 4/30, 33% = 10/30)



> 
> b) Why do you think discussing this in c.l.l will change anything?

Here I have to agree with you. I know people like to claim that Franz's 
pricing model is broken, but how broken would their management be if 
they took a major business decision based on stuff they had read on 
c.l.l ;^)
From: Damond Walker
Subject: Re: Pricing ACL
Date: 
Message-ID: <damosan-42DA98.18052116122005@comcast.dca.giganews.com>
In article <···············@individual.net>,
 Pascal Costanza <··@p-cos.net> wrote:

> 
> This thread is very boring.
> 

Yes it is but...

> a) How do you know that Franz insists on charging such royalties? Have 
> you asked them?
>

...this thread did cause me to send Franz an email asking about 
particulars based on *my* situation (hourly side work here and there).  

The result of that conversation?  Pretty darn good all things 
considered.  I can imagine a *real* company having a bit more leverage 
than a Mr. Basement Coder such as myself.
 
> b) Why do you think discussing this in c.l.l will change anything?
>

People like to complain about things.  That will never end.

Damo
From: jayessay
Subject: Re: Pricing ACL
Date: 
Message-ID: <m364prisb0.fsf@rigel.goldenthreadtech.com>
·········@gmail.com writes:

> I wrote this as an email reply to R. Fateman, but I now feel like
> posting it. (BTW, Richard, you probably meant to post your message in
> the first place):

So, now you've added "mind reader" to your claims of superior
abilities.  So, with this ability in your pocket and your professed
amazing business acumen, why haven't you left MS and Bill Gates in
the dust?  Why isn't alex.inc (or whatever) in the fortune 50?


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com