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

* William Deakin
| But where do you say anything about the educational function of Free
| Software and Open Source?

  actually, in numerous other articles prior to the one you comment on.

| The things that I most cherish about this model is that through exposure
| to Free Software and Open Source I have learnt much. e.g. I would never
| have tried to learn cl.

  why do you give Free Software and Open Source credit for source access?

  access to source code is not predicated on having the right to do
  anything with it other than read it and play with it for personal use.

  I really wonder why people have so much difficulty understanding that
  source can be licensed in ways that give anyone who ask for it the
  ability to see whole or parts of the source, but without thereby forcing
  the author to lose control over the source.  e.g., Franz Inc supports
  their customers with source to much of the surface functions in Common
  Lisp, but you have to agree not to give this away to others.  why is this
  not sufficient to learn from?  why do you have to be able to give the
  source to other people in order to learn anything from it?

| But how do you become a migration master?

  by becoming an expert at what you do and acutely aware of the impact of
  your decisions.  this is hard work and requires dedication and investment
  far above and beyond reading source code.  you have to write a lot of new
  code and also maintain systems _without_ source access to be able to see
  what it takes to support software migration.

| > I think that too much access to source code will cause a lot of people
| > to be exceedingly good at stuff that is antithetical to long-term
| > solutions.
| Why?

  because people take the road of least immediate resistance, not the road
  of least resistance.  it's far easier to hack a function to do something
  new than to figure out how the old and the new functionality should
  co-exist.  if you can't hack the function to do something new, but have
  to treat its current functionality as a black box and do the extra stuff
  outside of it, you tend to think more carefully about not changing things

| But I think we need to look at ways the ways in which code is developed.
| Be it Free or Open, Closed or Garden ;) coding.  People are making lots
| and lots of mistakes behind closed doors and then not telling anybody
| else about them.  At least Free/Open coding has more visibility.

  it's been said that architects raise monuments to their mistakes, while
  doctors bury theirs.  programmers tend to erase the evidence of their
  mistakes if they catch them before they need to document them and have to
  support them backward-compatibly in the future.  I would like to see ways
  to _really_ fix mistakes and produce backward-compatible code as an extra
  feature, effectively local changes to the code, instead of an integral
  part of the evolution of the system.

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