Subject: Re: source access vs dynamism
From: Erik Naggum <>
Date: 1999/08/25
Newsgroups: comp.lang.lisp
Message-ID: <>

* Barry Margolin <>
| However, even with all this modularity, I still relied on source code.

  I thought I had already covered the value of source access to people with
  real needs.  in your case, doing systems programming as your job is
  certainly within the realm of licensing the source, and I can't see why
  this is an argument for full source access with unrestricted rights to
  modify and redistribute modified code to essentially random people, which
  is what I'm arguing against.  again, I'm all for source access, but only
  to those who actually need it and commit to using it constructively.

| First of all, when using ADVISE you have to know what to advise -- often
| it was internal, undocumented functions.

  well, I modified Allegro CL's pathname behavior long before Franz Inc
  shipped the sources to these particular files to all supported customers,
  and all I had was a good grasp of the SPARC assembler and the standard
  functions that let me peek at the actual running code.  Franz Inc has
  since started shipping most of the "surface code" to supported customers,
  and it's easier to change a function, except that when upgrading, retro-
  fitting fixing becomes more risky than making the initial fix.

| There were also many thing that I needed to do that I could only do by
| modifying functions.  If there's a place in a function where it does (+ x
| y) and you need it to do (- x y), there's no practical way to do that
| without replacing the function definition.

  communicating with the people who own the source would solve this
  problem, and there is still no need to require unrestricted rights to
  modify the source.  having that right, however, means you won't find the
  need to communicate with the owners of the source until you're really
  pissed at something you can't do yourself.  if you think this is an
  exaggeration, read GNU Emacs bug reports for a while -- a pattern emerges
  where those who think they have rights tend to demand instead of ask.

| Object orientation and dynamism generally only work well if the designer
| of the system can anticipate where people will need to customize.

  yes, and that's the point: if we never get any practice in anticipating
  it or feel the consequences of our mistakes, neither will be ever become
  good at it, and the less well-designed software is, the bigger the "need"
  for unrestricted source access.  the more people have access to source,
  the less they will be interested in more modular designs or ways to fix
  things.  by giving random people unlimited source access, you may tell
  them, if not in words, then in the consequence of what you accept and
  implicitly encourage, that end-user customization is a subordinate need
  in the software as delivered.

| But if someone comes up with a need that he didn't think of, often the
| only way for them to implement their changes is by hacking the source
| code.

  of course, but why should the implementor of such changes _have_ to have
  (1) the automatic _right_ to access the sources, (2) the automatic right
  to distribute it further to others without the owner's approval, and (3)
  the right to distribute his modifications?  if you want to make something
  new, I really don't see why building on the works of the past has to mean
  that the works you create must be modifiable by anyone even before you
  know where you're going with it.

| One other thing: this whole argument only applies to customization.  Much
| of the benefit of open source is the ability of anyone to implement bug
| fixes and general evolution of the code.

  when this happens in cooperation with the owner of the code, it is good.
  when it causes a myriad of independent fixes to the same problem and
  branches into a variety of incompatible "products", we have instead of
  causing people's creativity to be employed usefully, failed to contain
  the biggest problem inherent in the free market, that it costs too little
  to fragment the market.  look at Unix.  it was essentially open source
  before anyone invented the term, and that caused a large number of ways
  to solve the same problem and left the market to sort them out, which
  they didn't (the market never will sort out bad quality in anything but
  the single most important property of the products), and Unix got itself
  into a position where some horribly demented crapware from Microsoft
  could compete with it and fool a whole bunch of people for a while.

  Linux is a success because it is well _managed_, not because it is Open
  Source.  whether people would have to sign an agreement to get access to
  the source and be allowed to fix things or not is immaterial: people who
  want to commit serious work to GNU Emacs must already sign an agreement,
  and that hasn't stopped GNU Emacs from succeeding, either.

  it appears to me that the crux of my argument has been lost, however: by
  giving people something they don't need, but which covers a need by sheer
  accident, they don't discover the solution to their _real_ needs.  people
  don't need source code to modify if the system doesn't work, they need
  working systems.  people don't need source code to add functionality to
  some static function design, they need flexibility in the design.  the
  more we give random people unrestricted access to source code, the more
  we will design software that is expected to be modified just that way,
  and the less we will design software that is not intended to be modified
  by random users at the source level, and the less we will design systems
  that are actually able to adapt to people without changing the code.

| Emacs is a reasonable example os a system that has balanced the two ways
| that programs change.  If someone wants to change the way the garbage
| collector or redisplay works, or add support for floating point numbers,
| this is done by modifying the code in place; however, Emacs's dynamism
| was used when they wanted to add web browsing capability.  Sometimes both
| need to be done: often while developing an external package you discover
| that it would work better if there were a hook in a new place, so you
| make that one little change to the guts.

  none of this even hints at why it was a good idea to give source code to
  random people and give them the right to modify the existing source code.
  those who develop their own packages for Emacs already communicate with
  the source holders and other developers.  nothing in this requires that
  the source code be given to _anybody_.

  as I have said several times, I think source access is a good idea, but I
  think it should be regarded as an investment by both parties, probably
  more so by whoever gets the source access, and modifications to the
  source should be channeled back to the owner before they are spread
  further down the line or to other developers.  my goal is to educate
  those who want to be educated, not to let random people have "rights"
  that only hurt them in the long run.

  save the children: just say NO to sex with pro-lifers