* Paul Wallich
| This sounds good, but it has a serious implementation problem: if you
| actually gave serious thought to who should have access to the source,
| you would spend far more time on the distribution/decision problem than
| on building working software.

  both economics and engineering are about using the available resources
  wisely and without undue waste.  both have long standing in our society
  as serious problem-solvers and even serious problem-inhibitors, meaning:
  by being aware of economics and core principles of engineering, we don't
  get into a large category of problems.  I don't see why it makes sense to
  dispense with economics and core principles of engineering just because I
  propose to give source access to people based on merit.  it has, however,
  always seemed a rather brilliant way to kill any form of proposal to say
  that it would _necessarily_ be reduced to a complete and utter waste of
  all available resources.  (pardon my cynicism, but Norway is holding its
  quadrennial local elections 1999-09-13 and the mass media user is now a
  hapless victim to an unprecedented level of braindamage that emanates
  from politicians and reporters.  it is physically painful to me.  I guess
  I'll vote for whoever can show a non-flat EEG at the end of the day.)

  people who have source code to offer today find ways to work with others.
  those who want to work with those who have source code, also find ways.
  one very simple way to measure interest and dedication is to ask them to
  sign various forms of agreements.  e.g., GNU Emacs contributors of any
  consequence have to sign over the copyright to their works to the FSF.  I
  didn't have a problem with that at the time and I don't regret signing
  it.  I have signed so many agreements and contracts over the years which
  in the minds of people who don't appreciate what any contract necessarily
  has to provide for if you enter into a limitation of your present freedom
  would mean in otherwise inaccessible and invaluable opportunities that a
  source license or a non-disclosure agreement as a prerequisite to taking
  part in something is not the hurdle it is for people who hate lawyers and
  legal complications when they just want to have fun.  but frankly, I'm
  strongly opposed to the view that others have to behave in certain ways
  because that's the only ways I think I can have fun, and this is probably
  because I believe the most fun comes about after very serious investments.

  the serious thought I want to give to who shall take part in a project
  should be doable once, in setting up the license and the contract that
  individual contributors have to sign.  in order to sign a contract, you
  have to establish a pretty clear image of what you will invest and what
  you expect in return, and that process is usually sufficient to sort out
  people who don't take it seriously enough.  on this topic, I might add
  that I have never quite figured out why employees don't interview their
  employers at least as rigorously as they interview them, but I have
  always been an independent consultant because I don't want to work for
  people who don't realize that they have to give me a very solid reason to
  work for them for at least 8 hours a day in a location of their choice,
  nor do I understand why people individually accept so horrible working
  conditions that they have to form labor unions so they don't have to
  accept them, anymore, but I digress.

  if giving source code to random people is such a panacea, the people who
  want the source code should have very convincing arguments why they
  should be given it, arguments that should make good business sense here
  and now.  the reason I don't believe in the panacea is that people aren't
  making solid cases for releasing source code that business people will
  listen to, and it is not _only_ because human beings are prone to act in
  contradiction with their personal or long-term interests.  put bluntly,
  if I have some source, what's in it for me if I give it to everybody?
  those who want other people's source code have failed to consider the
  transverse situation.  one person's want is not automatically the
  motivation of another; something has to come between that can motivate
  those who have something to give, and it is important to understand what
  would fill the need and stop the want, otherwise it is meaningless to
  give them anything at all.  if the value of open source was as great as
  its proposers want it to be, the only thing that keeps vendors from
  giving it out to everybody is a failure to understand their own (still
  the vendors') needs.  my advice is: stop talking about the value of
  source code to those who will get it for free, and concentrate on the
  value of giving away source code for free.

| Some people you think will be good will be disastrour, and some people
| you think will be bad will turn out brilliant.

  I keep wondering when this is _not_ the case, so why bring it up?  you
  appear to want to make it sound as if there is an inherent flaw in some
  _particular_ way to deal with people, but it's obviously an inherent
  problem in dealing with people qua people any way you decide to do it.

| So most people or organizations make a default decision: either don't
| release the code unless someone can onvince the hell out of you, or else
| release the code to all comers.  The first has been shown to suck in many
| cases, not least because people who may want the code won't want to
| bother with making a huge investment in convincing someone if the outcome
| is uncertain.

  as I said above: if source code access is such a boon to mankind, how
  come those who want the source are so incredibly bad at convincing those
  who hold the source today?  you appear to admit that there is very little
  obvious value and very significant obvious costs in giving people source
  access, yet don't appear to let this affect your desire for giving it all
  comers.  I actually wonder why you see this only from the _recipients'_
  point of view, when it is quite obvious that the _originator_ is the one
  who needs convincing.

  personally, I don't think the value of sharing source code and the
  programmers' mindsets with other people is uncertain at all: it is of
  _tremendous_ value to be able to discuss these things intelligently.  but
  that's precisely why it's an incredible waste to give it to everybody.

  let me add too much personal history to illustrate my point: I wrote to
  manufacturers of soft drinks, chocolates, toys, etc, when I was a kid,
  with whacky and useful suggestions alike, and they had the good sense to
  reward the most the suggestions they actually used.  to this day, I am
  concerned with what every supplier of mine does, from buying stock in the
  airline I use and making sure they get the most money out of my tickets
  while I get the lowest possible prices (squeezing out the middlemen), to
  asking for the site manager of a supermarket and suggesting they stock
  Water Joe because I want to buy it cheaper from them than from the few
  soft-drink stands that sell over-priced bottles.  I consider every single
  manufacturer and vendor to be a _supplier_ to my well-being, and I cannot
  understand why people don't do something on the personal level when they
  think their suppliers could do a better job, but instead wait to stage
  boycotts or make big stinks or demand that politicians take action when
  they could have obtained a lot more by just talking to the guys who do
  the work.  it doesn't take more than a fraction of a second to express
  concern, but it usually wastes a lot of energy not to.  the flip side of
  this is I have a serious problem with people who waste other people's
  time just because they don't see how much of their own time they waste --
  people who just plain don't _care_ bug me, big time.

  I have come to consider the clamor for source access for people who don't
  care (that's what this is about, since the people who care wouldn't have
  any significant problems in the first place) to be a gargantuan waste of
  everybody's time and effort, and a very strong reinforcer for those who
  want others to care _for_ them and who get bitter and demanding when they
  don't get what they think they have a right to.  my problem with getting
  this aspect of Free Software is that Richard Stallman is a guy who really
  cares about what he's doing, and he's caring about something valuable,
  but it won't work constructively as long as it benefits people who don't
  care more than it benefits people who _do_ care.

Still, I thinking that both of these ideas have severe scaling trouble
given the current and future size of the potential programmer base.

If a hundred people want source enough to ask you, and it takes you
five minutes to make a decision, that's a day's work. If 25,000 people
want source enough to ask you, that's an entire working year. Obviously
you may be able to reject a lot more of the 25,000 out of hand, but at
some point even reading the email will clobber you. For any project (like
an operating system) that has a potentially enormous base of interested
programmers, personal communication with everyone who wants to look
at the source code and has a superficially good reason to do so is going to
clobber the person who acts as a choke point.

I suppose you could delegate things to a cabal, but that has its own problems.

On the other hand, some kind of weeding-out mechanism may be needed;
I think Erik's example of the FSF license is a good one.

I've read this discussion with interest.

I've a couple of question for Erik.

I'm trying to understand your point of view.  Based on your posts on this
topic, it appears to me that you're advocating for source access based on
merit and/or investment.  What is your reasoning for this position?

Personally, I don't like open source software because of its quality.
Similarly, I don't particularly like source availability (I've only
ever modified three packages and I've only read the source for 3-4 others).  
I like open source software because it's:

        1)inexpensive.  I've always been amazed by the people
          who try to make out that this isn't a big motivator.  Does
          anyone else but me snort when they see a comment like "I'd
          pay for it even if it wasn't free?"
        2)lacking in administrative bullsh*t.  IBM's C compiler for the
          RS/600 cost $400.  Personally, I don't care about the $400
          (a cost of doing business).  On the other hand, I do care about
          having to chase down a PO.  I do care about having to install
          a goofy-a** license monitor to make sure I don't do something
          evil.  Similarly, I do care about having to call IBM sales support
          to get a new license key when we decide to move development to a
          new box with a faster network card. . .I could go on, but I'm
          even starting to bore myself :-).
        3)generally tailored towards use on commodity hardware.
        4)another tool in the fight against getting jabbed by your
          vendor.  To be honest, I believe a better tool in this fight would
          be open, understandable data formats so my data won't be held
          "captive" against it's will.
        5)community-oriented.  From what I can tell, open source projects
          tend to do an extremely good job of putting "customers" and
          developers together.  On the other hand, most commercial companies
          where I've worked went out of there way to keep developers and
          customers apart (counter-productive in my view).

Why do I get the feeling I'll regret this?

BTW:  if you believe extension via "scriptability" (ie Emacs, Apache, or Gimp)
or dynamic linking (ie Apache's mod_so) isn't a viable model for dynamism, I'd
be curious to understand why.  

  and here I thought we were programmers, but instead you argue that people
  should do all kinds of things _manually_?  something wrong, here.

| Obviously you may be able to reject a lot more of the 25,000 out of hand,
| but at some point even reading the email will clobber you.  For any
| project (like an operating system) that has a potentially enormous base
| of interested programmers, personal communication with everyone who wants
| to look at the source code and has a superficially good reason to do so
| is going to clobber the person who acts as a choke point.

  if that person can be trusted to manage something as complex as an
  operating system, I sure hope he's smart enough to realize what a silly
  problem this is before it hits him.  otherwise, who knows what kinds of
  silly things the operating system will do.

  there's a reason companies hire more people when the work-load increases:
  most people who want something done and want to make money doing it have
  figured out that it is beneficial if they can actually train other people
  to do certain tasks and not have to do everything themselves.  given the
  wondrous society in which we live, several people come pre-trained or, lo
  and behold, from other, similar, jobs with a directly useful skill set.

  here's a fairly simple idea: write a program.  publish it.  earn money
  doing this.  support your customers.  include automatic means to get
  upgrades and patches.  include _some_ source, the stuff you'd like people
  to use for innocuous customization and generally to understand your
  program better.  also include a description of what it takes to get more
  or all source, such as printing a file, adorning it with a signature, and
  sending it by ground-to-ground mail.  then do the natural thing in our
  advanced economic society: charge applicants whatever it costs to process
  their application so you have money to employ people doing just that.  or
  write a web thingamajig that deals with the boring administrative stuff.
  it's like the _rage_ among managers and marketing people these days, so
  it's a little odd that programmers don't think about it, isn't it?  ;)

  I think more programmers should have business training or at least some
  _exposure_ to what it takes to start and run a business.  it seems it
  might surprise a great many people, but you don't _have_ to work alone
  and do everything yourself.  basements and garages do _not_ beat a corner
  office and an efficient secretary.  you actually do get a lot more done
  if you hire people who are smarter than yourself at whatever they are
  doing than you would be yourself.  rewarding competence is the best way
  to ensure that the team's competence increases, but it's sadly out of
  vogue in a world of programming where it matters more that people can be
  replaced than that they do outstanding work, because they will leave and
  need to be replaced, and the next guy won't be able to figure it out.

  if, out of 25,000 people who write you with a desire to learn more about
  your software, you don't get 250 "hi, I want to work for you" and manage
  to take proper care of those people, you're doing something _very_ wrong.

  however, I wouldn't hire people who only see problems and refuse to check
  whether the rest of the world perhaps would have to change somewhat if
  you changed one particular factor.  hell, even the free software/open
  source change has a whole lot of ramifications, not all of them equally
  apparent, but I guess I'm used to thinking in terms of cascading changes
  and see that there's no way we can avoid serious scaling problems if a
  lot of people get access to an insurmountable heap of inaccessible source
  as the answer to their _real_ need: software that should fade away into
  oblivion (i.e., not stand out and demand attention) and just do whatever
  it is intended to do, seemlessly and according to how people find most
  beneficial and productive on their own terms.  this kind of software will
  not happen if a whole lot of people value access to source code above all
  and want their mark on software that stands out and demands attention
  like a laser beam right into your eye.  we need to work on something much
  bigger than one person's individual egoboost.  it's _incredibly_ hard to
  do that reliably without forming a loyalty that lasts beyond the feeling
  you get from seeing your name in a ChangeLog entry.  and worse, you don't
  _want_ to work with people who aren't loyal to the goals you have set for
  your project.  if you can't get rid of destructive people, you will have
  very little time available to keep going in the right direction.  this is
  also something you learn PDQ if you try to run a business with employees.

  let me put it this way: I dread the situation where software is written
  by people who are satisfied with name recognition and status among their
  peers -- we'll just get MS-DOS all over again.  granted that we live in a
  culture that adores youth and reveres immaturity as a deity, but if
  everyone who succeeds in any way loses their position to someone younger
  than they were when they were recognized, it isn't just a whole lot of
  disillusioned people we have to deal with: those who aren't wiz kids in
  time won't even have a brilliant flash of youth to look back at.

  I'll do a giant leap to something entirely different: I think a whole lot
  of the issues that plague the world today is based squarely in a rampant
  fear that the world will end _very_ close to 2000-01-01.  Y2K is nothing
  more than fin-de-siècle all over again, as far as the societal response
  is concerned -- technically nothing important will go wrong.  reverence
  for youth is a pretty good sign people don't think they'll get old.  what
  better way to go than when listening to Abba revived by some jail bait?
  I think when the world wakes up with a huge hangover near 2000-01-05 and
  start to realize that the only thing that really ended was the _hope_
  that the world would end and we wouldn't have to take care of things for
  the next 50 to 80 years of our lives, a whole lot of people will start to
  work and value things very differently from what they do now.  when the
  world doesn't end and we aren't plunged back to the dark ages because the
  entire world electricity system didn't fail, after all, I predict that
  all the crap we're doing now with a three-month horizon at most will take
  on much longer horizons, again, like 50 years.  there are some signs that
  some people think like this already: a publisher in Norway has decided to
  revamp their renouned 16-volume encyclopædia of world history and publish
  a special hand-made leather-bound edition in only 2000 copies to those
  who think it's important to maintain excellent craftmanship and some of
  the traditions of the millennium past.  they used to say that nostalgia
  was better in the old days, but I think it'll get better and better in
  the coming years...  but, anyway, let's get this millennium nonsense over
  with so we can get back on track.  we have work to do, damnit.

  someone here accused me of confusing fact and right, but I think what you
  have posted is just that.  I have no interest in discussing numbers of
  people or magnitude of practical problems.  my interest is on an entirely
  different axis: dynamism in software.  it's right up there in the subject
  line, too.  I'm arguing that those who want dynamism and think they need
  source code will get less dynamism when they get source code than a they
  would if they (1) chose a dynamic programming language and (2) could do a
  lot of interesting things without source code.  we are obviously not
  talking about people who do not benefit from source code because they
  don't own computers, either, and frankly, I don't understand the point of
  arguing about "source access vs dynamism" in such terms.

  my purpose was to show that people _need_ dynamism in their software,
  which you might of course argue against by saying that only N people do
  it and the rest are happy without it, but I only care about those N
  people in my argument.  I argue that those N people will not learn to
  write dynamic software that can adapt without source access or even at
  runtime because they have source access and think that's great, when it's
  only great compared to _not_ having source access -- it is not great
  compared to having fully dynamic behavior in the software, and since they
  are used to 10% dynamism-via-source-code-in-static-language and don't
  even see what 40% dynamism-via-dynamic-languages-without-source would
  mean for them or even 90% dynamism-via-dynamic-languages-with-source in
  the case where you can experiment with a change to a function in a
  running system.

  I honestly wonder why so many people don't see the dynamism argument and
  only latch onto the source access argument.  is it because people don't
  really know why they want source access?  Christopher's argument appears
  to be that it isn't needed.  my argument is that people who don't need
  source code still need dynamic behavior.  take GNU grep.  wouldn't it be
  great if you could make GNU grep always print the filename with an option
  instead of tacking on /dev/null at the end like Emacs does?  wouldn't it
  be great if you could instruct GNU grep to default to case-insensitive
  searches?  how about enclosing the filename in double quotes so Emacs can
  find matches in files that happen to contain colons in their names?
  these would be simple local patches in a dynamic system, but it may just
  be too much work to fix the source, submit a patch, and argue for the new
  features.  as you correctly observe, local fixes die with source access,
  but if the fixes are in the form of manageable advise code, they would
  survive an upgrade.  again, dynamic languages win on all points, but
  since people have source access, they won't think they need it, even with
  the many problems caused by source access, such as the ones you bring up.

  I'm advocating source access to people who express an actual desire and
  need for it.  "investment" here isn't monetary, as in "an investment of
  time and effort", but a concern that one has limited resources and want
  to maximize the value of using those resources.  without a sense of
  "investment", people are likely to waste what they get.

| 1) inexpensive.  I've always been amazed by the people who try to make
|    out that this isn't a big motivator.  Does anyone else but me snort
|    when they see a comment like "I'd pay for it even if it wasn't free?"

  of course it's a big motivator for the users.  who argues against that?

| 2) lacking in administrative bullsh*t.  IBM's C compiler for the RS/600
     cost $400.  Personally, I don't care about the $400 (a cost of doing
     business).  On the other hand, I do care about having to chase down a
     PO.  I do care about having to install a goofy-a** license monitor to
     make sure I don't do something evil.  Similarly, I do care about
     having to call IBM sales support to get a new license key when we
     decide to move development to a new box with a faster network
     card. . .I could go on, but I'm even starting to bore myself :-).

  of course it helps to deal with non-stupid people.  however, there are
  lots and lots of license-restricted software products that doesn't need
  any of this administrative bullshit.  if "PO" is a Purchase Order, it is
  unclear to me whether that is a requirement of IBM or of your company.  I
  have worked for companies where senior programmers are given budgets to
  purchase tools and time alotments attend courses without individual
  management approval.

| 3) generally tailored towards use on commodity hardware.

  this implies that commodity hardware would have been ignored if it
  weren't for the current crop of freely available source-based tools.  I
  don't think this is the case.  the quality of implementation may be an
  issue, but SCO Unix and even SUN Solaris for Intel are certainly present
  in the market.

| 4) another tool in the fight against getting jabbed by your vendor.  To
     be honest, I believe a better tool in this fight would be open,
     understandable data formats so my data won't be held "captive" against
     it's will.

  well, I worked with SGML for half a decade because I believed it would be
  a means to free the data, but that turned out to be false, it makes no
  difference whatsoever.  if your data should be less captive, I think the
  way to go needs to be the ability to call functions to retrieve objects
  and manage them.  again, dynamic languages win big in my view.  there
  might be an issue of just how much you get access to even in a running
  system, but at least the world isn't closed up.

  I personally fail to see why people don't take this "getting jabbed by
  your vendor" thing much more seriously.  if you're afraid of it, and you
  don't tackle the issue head-on, is it because you _fear_ the vendor?  do
  you actually _need_ products that will likely cripple you in the future?
  (I don't think so.)  have you ever talked to the vendor and expressed
  your concern?  if you haven't, do it now.  if you have and was dissed,
  why do you still deal with them?  this is the labor union thing all over
  again, except now with entities you'd expect were able to defend their
  own interests much better.

| 5) community-oriented.  From what I can tell, open source projects tend
     to do an extremely good job of putting "customers" and  developers
     together.  On the other hand, most commercial companies where I've
     worked went out of there way to keep developers and customers apart
     (counter-productive in my view).

  yup, counter-productive in the extreme.  if you use a software tool for
  developers, and you can't talk to the developers of the tool, you have
  made a mistake in purchasing it.  however, this is not a function of
  source access, but of smart people who actually care about what they do.

  you have pointed at several issues that point to why people should choose
  source-based products instead of shrink-wrapped products, and I agree
  with all of them, but at issue is not source vs shrink-wrap, in my view:
  at issue is a lot of incompetent people who are mortally afraid that if
  anyone saw their source, they'd be exposed as the frauds they are, and I
  actually believe that a certain major software company in Redmond, WA,
  would be history the day its sources were released in a much more
  important sense than any other company would fold if its trade secrets
  were dispersed.  I have argued elsewhere that I think a big motivator in
  the source-based software world is legitimate rejection of said company
  and its extremely predatory behavior.  however, defense against idiocy
  and evil is not an end in itself -- you have to have a pretty clear
  picture of what you're fighting _for_.  while destroying a company that
  has defrauded millions if not a billion of people is a very worthy goal,
  we need to consider what comes after it, and we need to consider what we
  want to accomplish when the idiotic evil is gone, otherwise, we'll just
  give rise to another.

| Why do I get the feeling I'll regret this?

  beats me.  and you don't come with source, so I can't fix your problem.

Erik Naggum <e...@naggum.no> writes on comp.lang.lisp:

It looks like to me the "make people responsible and trust them" attitude
is the winning one. You said it many times about the CL vs C++ attitude:
CL trusts the programmer, whereas C++ distrusts them, and the result is
trustworthy CL programmers, and untrustworthy C++ programmers.
The same argument applies to free software vs proprietary software.

There will always be stupid and evil people; no policy will prevent that.
The question is how to make such people harmless to anyone but themselves.
Reminds me quite of F.A.Hayek's "the Road to Serfdom"...

Former ILOG LISP users and developers unhappily know _perfectly_ well
what I'm talking about...
The motto of the AFUL is "liberté, stabilité, perennité":
liberty, stability, perenniality.
Oh, and if what the company sells that has so much value
is their great service, then it has nothing to fear
from "competitors" who'd just sell unsupported copies of the software...

Of course, there are exceptions: CommonLISP and Dylan are dynamic languages
that have been mostly developed as proprietary systems
(despite heroic free implementations); but they have limited success
among proprietary systems; they don't fit the proprietary software model
of separation between provider and consumer.
On the other hand, there are static free languages (SML, OCAML, Haskell),
but even they have interactive top-levels,
and they have a hard time capturing free software developer mindshare.

Best regards,

Money is simply an interchange medium for "stuff I'm interested in"
and "stuff you're interested in".  If you do something in
life--anything--that someone else really wants, they'll give you money
for it.  If they won't, you have to question whether they want it.

You can create barter systems in which money is not exchanged, but they
are hard to account for and you get people who don't pull their weight.
That's why the world uses money and not smiles as a way of counting who's
done what for who.

So if you're willing to trade the money you have for someone else, all
that says is that it's of value to you.  And if you're not, then maybe
it's not as much of value as you think.

If people are willing to give away what they do, that's fine. That
just means they don't value it or they have enough money that they
don't feel a need to charge for everything they do.  One would hope
that all people could be philanthropic sometimes.  But they have to
eat and I don't see giving them a hard time about that.

Now, I agree completely that the idea of restrictions on "independent
creation" (software patents) are a nuissance that should be struck
down because they arbitrarily and capriciously restrict the right of
an alternate content creator to show that an idea wasn't as hard to
come up with as the original creator thought.  But that's where I stop
in the "free software" area.

I also found that this is often far more useful than source access. If
you describe the symptoms of a bug to a developer he will often know
immediately where or what is the problem. Even with source, it would
take a large investment of my time to get that familiar with the code.

This also happens in the open source world. Far more bugs get resolved
by people like Alan Cox for Linux or Jeff Law for gcc through bug
reports on the mailing lists than that the user who found the bug
starts digging through the code himself. The only reasons this doesn't
work very well for most of the closed source proprietary software is
that it is written in a language like C without much debugger support
to generate useful bug reports and that a lot of firms ship their
stuff without even that meager support by stripping the executable of
all debugging symbols. Since dynamic languages generally have
excellent support for this without having source, I think Erik has a
point.

PDQ: pretty damn quickly?

Vassil Nikolov.  (See header for additional contact information.)
  Abaci lignei --- programmatici ferrei.

  yes.

  incidentally, can you please fix the bug in your newsreader which causes
  it to copy the References header unchanged from the article you respond
  to if it has any and only do the right thing when it has none?  it is
  annoying that it doesn't work to go back to the article you replied to
  and the threading in other newsreaders gets all messed up, too.  thanks.

References header of Vassil's article to which you were replying:

  | References: <3144404199547...@naggum.no>
  |  <37C17E00.D039A...@elwood.com>
  |  <_Mfw3.358$m84.6201@burlma1-snr2> <3144558626572...@naggum.no>
  |  <u7ogfwcgcl....@ebi.ac.uk> <3144569678548...@naggum.no>
  |  <l03130309b3ea9ce7b...@195.138.129.122>
  |  <pw-2608991934540...@166.84.250.180>

References header of its parent article (reformatted a little):

  | References: <3144404199547...@naggum.no> <37C17E00.D039A...@elwood.com>
  |  <_Mfw3.358$m84.6201@burlma1-snr2> <3144558626572...@naggum.no>
  |  <u7ogfwcgcl....@ebi.ac.uk> <3144569678548...@naggum.no>
  |  <l03130309b3ea9ce7b...@195.138.129.122>

The last item in the References of Vassil's article is the Message-ID
of the article to which he was replying. This all looks perfectly
in order to me.

That calls into question:
   "So why does it seem to be economically viable to give away
   computer software, particularly in source code form?"

The answers seem to me to lie in the legal gyrations that surround the
"licensing" of the things that get called "intellectual property."

It may be pretty easy to take a slab of steel, kick it, and say "That
slab is worth $50,000, and if you sign a purchase order, you can have
it."

In contrast, it is vastly more difficult to work out the value of
giving somebody a copy of the source code to Emacs, as the results of
giving that to them can vary dramatically based on what they do with
it.

So we head down the path where no decisions can be made without having
a veritable army of lawyers examine the situation, and put their seal
of approval on the notion that the parties have made a legal agreement
to transfer source code from A to B with some precise set of legal
restrictions on what they can do with the results.

Microkernels are (at least in potential, if not always in practice)
more dynamic; the academics have commonly denigrated the monolithic
approach as "passe," and the Torvalds-versus-Tanembaum "flame war" was
pretty exemplary in that regard.

It strangely enough turns out that it is almost as easy to add some
modularity to the monolith and let it do the things that they thought
only a microkernel could do; Linux kernel modules being the canonical
example of this.

With regard to the "grep" issues, it is not difficult to provide a
parallel to "dynamism" via constructing script-based functions to add
suitable filters.

- If I want a grep that defaults to be case insensitive, that is as
  easy as "alias grep='/usr/bin/grep -i'"

- If I want a grep that encloses filenames in quotes, and I'm quite
  sure I follow your thinking there, my first thought would be to put
  a thin layer of Awk/Python/Perl on top that does suitable parsing of
  the results.

  that's OK, but it's been a while since I signed off with #\Erik.  ;)

* Erann Gat
| It's because for some people the alternative is to be destitute.

  no, that is not the explanation, although some would have you believe
  that people can be forced to accept anything under threat of becoming
  destitute if they don't.  the problem is not that they would become
  destitute, but that they want something so badly they will accept the
  worst possible conditions because there's something at the other end to
  hope for.  some people are good at defrauding people of their present and
  future in this particular way, but I wonder why so many fall for them.

  at issue is why people "invent" solidarity at the wrong time and accept
  absolutely everything as long as they are alone, but speak up only when
  they think they can gang up on others, and especially why they have to
  wait until things are really, really horrible before they react.  this is
  the stuff I don't understand.

  historically, labor unions arose when people had gotten a taste of a
  different lifestyle and were willing to pay a lot more for their basic
  livelihood and had gotten into a fix they couldn't get out of -- because
  they had accepted the unacceptable to begin with.  accepting something
  you have to form a labor union to fight after the fact only tells me that
  people were acting against their own best (or even good) interests for a
  long time.  I don't see any rational, coherent explanation for this sort
  of behavior in humans, but it's all over the place.

  I guess it's the same basic argument as "yes, we do fear the vendor": a
  complete failure to grasp that the roles people play in a complex society
  do not change their nature or (other) qualities as humans beings.  why do
  people give their money to people they fear will screw them in the future
  _because_ they have given their money to them in the past?  don't they
  _see_ that their capacity to screw them and hence their fear of them, is
  a function of giving the wrong people money to begin with?  Microsoft is
  the ultimate fraud operation, but it's always extremely easy not to get
  defrauded: just don't deal with them at all.  if you fear you will be
  screwed by someone you deal with, whoever forces you to deal with them?

  here's my line: don't _ever_ grin and bear it, speak up when you aren't
  happy with what you experience.  you'll piss a lot of people off for a
  while until they figure out that you are actually very happy when you are
  happy with things and that most things actually do improve when you care
  to express your concern, and then it dawns on a few people that _because_
  you consistently speak up, you don't bear grudges or get bitter at people
  for not caring.  if you can't accept something, don't.  don't prostitute
  yourself because you want something you can't have without prostituting
  yourself -- just stop wanting it when you realize what you'll have to go
  through to get it.  reject the "future religion" which attempts to tell
  people they should accept to suffer now because some future will be so
  good: somebody is ripping you of your present if you believe that crap.
  if you _don't_ accept to suffer now, the historic evidence shows that the
  future _will_ be better.  the good future doesn't _come_ to people who
  sacrifice today for any rosy promise of a better tomorrow, because there
  will _always_ be a "today" that can be sacrified to a "tomorrow", and if
  somebody, such as Bill Gates, benefits from your naïve belief in this,
  they _will_ rip you off again and again, and the future never comes, it
  will remain "the future" for as long as you believe in it.  only when you
  stop believing in the unreasonably brighter and better future do you have
  a shot at improving the present.

  although I have not made the point specifically here, my preferred way to
  get one's hands on an exportable subset of the source code is to sign a
  prewritten (i.e., non-negotiable) license agreement and go from there.
  at issue here is two things: (1) you need to establish sufficient need
  and desire to at least read and sign a license agreement, and (2) the
  owners of the source code knows who you are and what you have obtained.

  on earlier occasions I have briefly discussed how I want things to work
  out, in a few classes of users: class A users receive the product and
  direct support, only.  class B users obtain some source for their own
  education and use, persuant to executing a license agreement.  class C
  users obtain more source and are encouraged to submit fixes, which they
  continue to own separate rights to.  class D users join the developer
  team as volunteers, and still retain their rights.  class E users get
  paid to fix problems they find and may even get paid to fix problems in
  their fields of expertise on demand from the vendor, but as soon as they
  get paid, they agree to relinquish the rights to whoever paid them.  all
  through this scheme, exchange of actual values is an essential ingredient.

| But what if their marketing department decides that this software is no
| more profitable and will no more be supported?

  then you either have a breech of contract situation or you go talk to
  them and make it profitable.  this happens all the time in the world of
  actual businesses.  part of the deal with bankruptcy and reorganization
  is to let creditors recover their money, and only a few creditors will
  consciously and purposefully deny themselves the opportunity to recover
  more rather than less money.  you'd be surprised how much of a company's
  assets you can get your hands on if you make like a vulture and pick the
  guts of dead companies.  (yes, that's intentionally gross.)

| With free software, you just move to another service provider (who may
| perhaps hire the employees of the former company).

  why is the parenthetical comment restricted to free software?

| With proprietary software, you just bite the dust; no possible long-term
| warranty.

  just because you don't see any options doesn't mean someone else doesn't
  see options that you are ideologically prevented from seeing.  people
  have been known to buy up parts of companies or their assets in the past.
  it will happen again, I promise you.

  and let me just ask you a simple question: what exactly do you need from
  a company after you bought the software (or licence to same)?  you keep
  arguing on the one hand that you buy broken crap from fraudulent shops
  that you subsequently fear will screw you even more, and on the other
  hand you want long-term relationships with them?  I don't get it.  just
  how desperately in need of this broken crapware do you believe you are?
  and why don't you go talk to a shrink about this rather than believe that
  this is due to something wrong with the entire world?

  it appears to me that you want source so you don't get screwed, but it
  seems to me that you're better off buying quality products to begin with,
  stuff that actually continues to work for years and years because the
  bugs you found and they fixed are not going to bite you again, and the
  old software that needs the long-term warranty isn't likely to be in
  active development and thus isn't likely to hit upon new bugs.

| Former ILOG LISP users and developers unhappily know _perfectly_ well
| what I'm talking about...

  for any dire strait people _might_ get into, there's always someone it
  actually happened to, and which you can blame on your favorite factor.
  to people who know some statistics and propaganda, this is _supremely_
  unconvincing.  _nothing_ is less convincing in a debate than throwing
  examples at eachother.  it's what politicians do when they want votes
  from people who don't know any statistics and don't grasp propaganda at
  all, but why the hell should anyone except politicians care about such
  driftwood in society?  it's not like they are going to have any _say_ in
  anything of importance, is it?  if you want to argue effectively, aim for
  the people who take increased insight away with them -- they will quietly
  spread the word.  if you want to argue to win _points_, however, I'd say
  go for the examples, and the more emotional they are, the better, but at
  least be _aware_ that they are competely ineffectual: whoever beats you
  with another better example nullifies your point completely.  that's what
  _doesn't_ happen with insight: people don't un-see an old issues because
  you bring up a new issue, you'll just have to keep adding to the insight.

  so, how about the fate of Symbolics' Genera?  as far as I hear from
  people, somebody actually bought up the rights to the product and
  continued to support and sell it, and they are constantly arguing that
  it's the _best_ software environment in existence still.  maybe ILOG was
  a weak product with good marketing and management which could nonetheless
  not sustain it, and Symbolics' Genera was an excellent product with weak
  marketing and management that wiped out its financial foundation?

  the interesting question with ILOG TALK is: would you, personally, have
  started, or invested your own money in, a company that would do support
  on it, if the software were freed now that it is defunct, anyway?  if
  not, who's to say the exact same fate would not have happened to a free
  software project?  just because it's free software doesn't mean it's free
  of all the well-known consequences of human behavior.

| Oh, and if what the company sells that has so much value is their great
| service, then it has nothing to fear from "competitors" who'd just sell
| unsupported copies of the software...

  I'll believe this when it comes from the owner of a business, not from
  someone who very explicitly wants to loot businesses.  in other words:
  again, feel free to risk your own money, and shut up about others until
  you have proven that you put your own money where your mouth is.

| Yes, we do fear the vendor.

  thank you for stating this up front.  now I know you're actually insane,
  more specifically a raving paranoid.

| Think of it as meme stability: the meme of dissing users is co-stable
| with the meme of proprietary software, but not quite so with the meme of
| free software.  We DO organise in unions to fight vendors who diss us,
| and the result is called (surprise!) free software.

  and this ranting proves you've _really_ lost touch with reality.

| I can't imagine one's favorite C compiler vendor providing developer
| contact to all its customers, there are too many of them.

  I'm sure that's how a lot of people think when they buy anything at all,
  but you gotta understand that if you don't even try, and are so deranged
  as to _fear_ your vendor, then you _will_ be treated harshly by the real
  world, not because people want to, but because you set yourself up for it.

  I actually think that fear of authorities of any kind should be listed as
  a serious mental disorder that causes people to become dysfunctional in a
  modern society.  people who suffer from it should seek psychiatric care.

| Dynamic software WILL win; it will win WITH free software, not against it.

  well, I have the exact opposite opinion, but at least I make an argument
  for my case, I don't just repeat a mantra.

| Proprietary software has brought upon us the domination of FORTRAN,
| COBOL, PL/1, C, C++. Static languages.  Free software has always
| developed its dynamic tools: LISP (pre-Common; elisp; Scheme), shells,
| Perl, Python, etc.  Dynamic languages (of various quality).

  this is downright ridiculous in its lack of adherence to fact.

  |...|
  >   incidentally, can you please fix the bug in your newsreader which causes
  >   it to copy the References header unchanged from the article you respond
  >   to if it has any and only do the right thing when it has none?  it is
  >   annoying that it doesn't work to go back to the article you replied to
  >   and the threading in other newsreaders gets all messed up, too.  thanks.

You are quite right that such behaviour is annoying, and I apologise for
all inconveniences caused.

I can't fix the program but I can fix the headers (or at least I believe
that will work, I'll test it now).

I would like to note that what actually happens is this: the message id
of the article that's being responded to is placed in the In-Reply-To
field, rather than appended to the References field.  I admit I don't have
the time to locate the relevant RFCs to find out if this is a feature or a bug,
i.e. if this doesn't happen to be legal though strange.^1  Of course, that isn't
very important as the really important fact is that people using
non-broken software have not been getting the links between articles
right.  (To be honest, I knew this but hoped that good newsreaders
would be smart enough to make use of In-Reply-To, but apparently
I assumed too much.)
__________
^1 I am posting via a mail-to-news gateway (Deja's), i.e. using an e-mail
   program to send posts, so this might be fine for e-mail but not for
   news

(By the way, this happens to be also an example where the problem could
be solved by having access to the source but where a solution using
dynamism would be better.  In my particular case now, I have no source
available, and I fix the problem by modifying the file containing
the outgoing message---whether this qualifies as a dynamic solution,
I can't really say.)

Vassil Nikolov.  (See header for additional contact information.)
  Abaci lignei --- programmatici ferrei.

You know, it's hard enough to argue with two sets of arguments at once,
by two brilliant people (Erik and Ken), each with one's own personal mindset.
It leads to contorted messages that mix without matching
several points of views at once, and that hence are long and hard to read.
Since the debate has (once again) slipped from dynamic software
to free software, I propose that the latter topic be discussed outside
of comp.lang.lisp, for instance on the cybernethics mailing-list
        http://lists.tunes.org/cgi-bin/wilma/cybernethics
(please propose other places where to move the debate, if you will).
Whatever messages remain on comp.lang.lisp should focus more
on the technical aspects (such as "what exactly is dynamic software?";
"what does it become in presence of concurrent and distributed systems?").

   #f d
------>8------>8------>8------>8------>8------>8------>8------>8------>8--- ---
T'was once said on comp.lang.lisp:

Maybe current free software hackers have been working mostly for nothing,
but it's not been because they like it and want it that way;
it's been because capitals have been completely diverted from free software
development by proprietary software development. Happily, things are now
moving fast, and despite all the disbelief of even fine people like you,
people are nonetheless understanding that free software means more business;
and apparently in the last few weeks,
some people have been betting 4.5 bn$ on it with the RedHat IPO.
Not much, but it's only one company among so many, and only a beginning.

Oh, they might be interested if a lot of customers pooled their money;
but if they had a lot of customers, they wouldn't kill the software;
or better even, with the same money, them same united customers would
more profitably associate to develop their own software,
and both avoid paying licenses anymore and be master of their fate,
without paying licenses for years and depending
on the vendor eventually selling out.
Consortia of big software-using companies will happen.

Of course, some people where I work and elsewhere unhappily buy such crap,
and I do argue that proprietary software gives an edge to fraudulent people.
But the problem with proprietary software is _even_ with
good-willing, proficient people who sell quality software.
(Re)read "The Road of Serfdom" about that.
It's the problem of liberty vs protection, of quality-driven
vs politic-driven technical decisions, of perenniality of investments
vs throw-away computing.

I may trust people; I cannot trust anonymous companies.

Real code isn't needed.  Rideau has (with much help) already produced one
of the biggest helps to OS developers yet -- a thumbnail survey of
existing work.

Not every necessary task is noble.

And not every useful deed is a main goal.  Even if Tunes is never finished
the useful deed is done.