From: Tom Lord
Subject: (re: kent) free software, business, lisp
Date: 
Message-ID: <v7kopot6b3i197@corp.supernews.com>
[Sorry to bust this out from it's parent thread "learning new things"
 but:
   (a) reading that thread, I think the three topics and their
       convergence are of fairly broad and relevant interest here
   (b) my newsreader is lame and I couldn't find Kent's original
       post to reply to.

 The thread has talked about how free software may be economically
 irrational for programmers, how the industry treats lisp, and 
 in my corner of this thread -- free software business models that
 (or "towards them" anyway) in which lisp makes a lot of sense
]



        But did you see my post i which I remarked that this means
        "capitalism" is in play, but if you think of capitalism as a
        feedback loop that hones the "product" that it is focused on
        (loosely, "the market"), cranking out better product, then
        capitalism is distracted from making better "lisp" and is
        focused on making better product.  This is maybe locally
        better for industry but is worse for "lisp".

And other than in short time-scales (you'd probably agree), that's
worse for the industry who, by such phenomena get stranded at local
maxima waiting either to be leap-frogged or to stagnate when the
capacity for big innovations using the tools at hand is exhausted.

Or as you put it:

	I'll go a step further here, to avoid simply having repeated
	myself, and say that I think the reason for caring about Lisp
	per se (which you might argue the world should not care about,
	per se) is to avoid a "hill climbing problem".  Capitalism,
	and, more generally, conventional Darwinism, is narrowly
	focused on "the moment".

Agree on "hill climbing problem" -- disagree on Darwinism.  My amateur
understanding is that best indications are: evolution, having been at
it for so long and thus having a lot of tricks up its sleeve, has
evolved ways to foster and/or hold in the background the evolution of
momentarily suboptimal mutations -- because (metaphorically) when the
next meteorite strikes, and there's a scramble for _anything_ to
survive, those odd-balls have a way of coming through.  But don't ask
me for cites or treat that as a biology lesson -- it's just something
I've absorbed from random, forgotten news-wires and such (that happened
to make a lot sense, so I thought there's plausibly some truth to it).

But never mind -- we agree so much.

I think that idealized free software licensing is a huge win (ignoring
money for the moment): source to everything; ability for any customer
to patch and rebuild on his own; fluidity of source borrowing and
other re-use; fluidity of who you can help.  I think those things are
simply just practical (and, yes, ethical) engineering.

So the challenge is: how to make it work with money.  As you say
(taking you _slightly_ out of context):

	investigating some alternate business models might wake things
	up.

(you said that in the context of a comment on labor organization).


Ok, what does a proprietary license buy you, nowadays?  I claim that
it buys you a negative value and some positive values.  A negative
value is a value you wish you didn't need.  Positive values are the
ones you're happy to pay for.

The negative value of a proprietary license agreement is: freedom from
being fined, sued, or jailed!  (Gee, thanks.)

The positive value of a proprietary license agreement are:

*) The product you're buying is less likely to become abandon-ware.
   You can have some confidence that it will be ported to the next
   release of your OS platform.  You can have some confidence that it
   will support HTTP 4.3.  You have some confidence that you won't
   have to re-pay the deployment costs for a complete replacement
   system in three years.  In short, you're paying partly just to have
   an actual firm there who is some vague way "promising" to stick
   around for a while and "be smart" about the future of the program
   you're buying.

*) Your supplier is going to study your customer demographic.
   That implies that for an incremental license fee next year or the
   year after, you'll get a better version that has some clever new
   features that help you run your organization better.   You buy a
   car and you expect it just get worse and worse over time -- but
   often you buy software, and via upgrades, you expect to get 
   better and better, at least for a while.

*) You get a user community -- often one facilitated by your vendor.
   You get the mutual support of fellow users.  You get job applicants
   who list familiarity the product on their resume.

None of that _requires_ proprietary licensing.  I think that, speaking
in very high level terms, it requires a subscription, probably
including a low-wall web-based garden to a user community that links
you to the developers and peer users.

There's lots and lots of variations on the "software was subscription"
theme.  Many of them share the "can generate a windfall" property that
many proprietary licenses have.

If you start such a subscription service, one of the elements of
competition in many domains is going to be your ability to
inexpensively flood it with responsive content -- a steady stream of
non-disruptive "improvements" to the basic system.  As we all know,
compactness of code, flexibility of code, and so forth are all
critical to that kind of agility -- as is hiring and retaining the
best programmers.  So, um, lisp (in the broad sense)?  Damn straight!

Taking giant leaps through my thoughts on this matter just to mention
one of my favorite resulting lemmas:  Gnome Sucks, Emacs Rocks -- it's
an architecture thing.  (Forget the AI winter -- did Lucid accidently
create an "Emacs winter" :-)


Aside from all that, just answering a question in your reply:


       > As an example: It isn't hobbiests who are killing the unix
       > industry.  Yes, volunteers provided a lot of raw materials
       > but, ca. 1994, those raw materials could not compete against,
       > for example, Solaris in the commercial market.  That critical
       > last delta came from short-term tactical R&D by the
       > companies, and sadly, it was implemented without any apparent
       > care in the world about where the next generation of "raw
       > materials" would come from.

       This is hard for me to follow because I haven't got enough
       background in the actual events and people you're referring to
       in order to parse through it.  Can you perhaps expand a bit?


That it's vendors closing the gap from Linux-as-hobby to
Linux-as-unix-replacement, one small example (of many) would be the
effort to pass validation test suites of various standards and
certification programs of various 3rd party apps.  I think if you
trace the patches back, you'll see it's pretty much all a tactical
effort of vendors (the only ones likely to run the validation tests).
I suspect you'll find mostly vendor-created patches -- plus also
volunteer-created patches that result from vendor-created bug reports.

Another area like that is scalability of the Linux kernel to
multiple-CPU machines.  It's tactical vendor-made patches and I
wouldn't be surprised (since this benefits-only-vendors goal gets so
much attention in venues like /.) if there are some vendor-inspired
volunteer patches there too.

Personally, I find that driving-of-volunteers by vendors ugly and,
more importantly in an economics discussion, unwise.

As for the vendors not worrying about where the raw materials come
from -- well, please, by all means, show me their strategic R&D
efforts for free software.  I don't see any.  My favorite quote from
an FSB exec on strategic R&D they get for free from universities is "I
don't think we're taking advantage of them enough" and my favorite
response is the recent-years retreat by universities back from public
licensing towards getting revenue from any proprietary IP they may
generate.

-t

From: Pascal Bourguignon
Subject: Re: (re: kent) free software, business, lisp
Date: 
Message-ID: <87llz9icne.fsf@thalassa.informatimago.com>
····@emf.emf.net (Tom Lord) writes:
> The positive value of a proprietary license agreement are:
> 
> *) The product you're buying is less likely to become abandon-ware.
>    You can have some confidence that it will be ported to the next
>    release of your OS platform.  You can have some confidence that it
>    will support HTTP 4.3.  You have some confidence that you won't
>    have to re-pay the deployment costs for a complete replacement
>    system in three years.  In short, you're paying partly just to have
>    an actual firm there who is some vague way "promising" to stick
>    around for a while and "be smart" about the future of the program
>    you're buying.

You mean, for  the happy few who bet the right  horse.  But what about
the thousand  who bet (bought) software from  corporations who finally
fail or are bought by competitor with the consequence of this software
being canceled?

Actually, this  is the  main reason why  _I_ won't buy  any commercial
software if  I can avoid it  any more.  I'm  just fed up of  seeing my
software unsupported after a few year each time.

 
> *) Your supplier is going to study your customer demographic.
>    That implies that for an incremental license fee next year or the
>    year after, you'll get a better version that has some clever new
>    features that help you run your organization better.   You buy a
>    car and you expect it just get worse and worse over time -- but
>    often you buy software, and via upgrades, you expect to get 
>    better and better, at least for a while.

Well, I already know that I'm just out of the mean.  There's a penalty
here  for people  (organizations) that  are  not plain  clones of  the
standard issue human (or organization).   The feature I want are never
implemented by  the commercial  vendors.  Strangely enough,  I'm often
contacted  by people  who have  problems of  customization  with their
commercial software,  and unfortunately, I  can only say that  I can't
help them  without the  sources. Needless to  say that the  sources of
these commercial software are never available.

 
> *) You get a user community -- often one facilitated by your vendor.
>    You get the mutual support of fellow users.  You get job applicants
>    who list familiarity the product on their resume.

Same occurs with free software.
 
> None of that _requires_ proprietary licensing.  I think that, speaking
> in very high level terms, it requires a subscription, probably
> including a low-wall web-based garden to a user community that links
> you to the developers and peer users.

-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
From: Kent M Pitman
Subject: Re: (re: kent) free software, business, lisp
Date: 
Message-ID: <sfwd6kkvj6m.fsf@shell01.TheWorld.com>
Pascal Bourguignon <···@informatimago.com> writes:

> ····@emf.emf.net (Tom Lord) writes:
> > The positive value of a proprietary license agreement are:
> > 
> > *) The product you're buying is less likely to become abandon-ware.
> >    You can have some confidence that it will be ported to the next
> >    release of your OS platform.  You can have some confidence that it
> >    will support HTTP 4.3.  You have some confidence that you won't
> >    have to re-pay the deployment costs for a complete replacement
> >    system in three years.  In short, you're paying partly just to have
> >    an actual firm there who is some vague way "promising" to stick
> >    around for a while and "be smart" about the future of the program
> >    you're buying.
> 
> You mean, for  the happy few who bet the right  horse.  But what about
> the thousand  who bet (bought) software from  corporations who finally
> fail or are bought by competitor with the consequence of this software
> being canceled?

Actually, although this is a problem with present law, it's not clearly
attributable to the concept of commercial software per se.  That is, it's
separable.  In principle, it could be solved by a correction to commercial
law that either followed on the concept of 'abandonment' and allowed code
that had fallen into disuse to lose its copyright status and/or by copyright
law itself allowing a sale to be contingent on use and allowing an author
to reclaim his/her rights (this could be a new 'moral right', a variant
of the defamation rights) if the entity to whom the item was sold or for
whom it was made for pay failed to use it.  Or the contract of sale or the
employment agreement (if we had the economic power to write strong 
employment agreements, which we don't because we've turned ourselves into
commodities ... but we once DID have that power back when the market of
programmers had that commercial power Stallman seemed to find so 
unnecessary).