suppose one operating system (or language) lets you open an already open
  file by calling OPEN or whatever on the open stream.  since this is
  clearly beneficial to anyone who can do it, let's assume people start to
  do it and demand the same functionality elsewhere.  one easy way to do
  this is to use a function other than OPEN to do this, but this does not
  scale well: every request for a feature would need a new OPEN, and you
  would have to decide _which_ OPEN to call both in your code and in the
  implementation of the new functionality.  clearly, this is a very messy
  situation and migration from one system that did support a feature to one
  that did not would be a function of the number of features people might
  have added.  this problem would be solved if people had the source and
  could fix things themselves and then channel the fixes back to a central
  place that could "take over the world" with better versions.  consider
  the Unix way, which used to have the function call DUP, but recently has
  /dev/fd/<N> -- you can fake /dev/fd/<N> with DUP, but to do that requires
  getting under the skin in OPEN and parsing a file name and all sorts of
  cruft that the file system code would normally do.  ugly, but it would be
  necessary, right?

  the reason that source access is needed is the same as the cause of the
  problem: the inability to modify system behavior non-intrusively.  if one
  could modify OPEN on any given system to acquire new behavior _without_
  compiling a new OPEN or, even if you did, without re-linking the entire
  system (thus the need for dynamic linking and similar solutions, too),
  source code access would be entirely immaterial.

  so suppose you wanted to wanted to add DUP functionality when OPEN was
  called on /dev/fd/<N>.  you could grab the old OPEN definition and call
  it anonymously, while redefining OPEN to be your particular function,
  which acted only on a match to such pathnames, or you could redefine OPEN
  once and for all and add your stuff via a well-defined hook system, or
  advice or whatever.  whether you would try the new thing first or only
  after trying the argument the old way had failed would be an orthogonal
  design decision, subject to how easy error handling is and the expected
  frequency of failures.  this way of doing things would in any case cause
  a few simple improvements over static source: (1) the core system could
  upgrade its OPEN without the need to migrate the changes.  (2) if you did
  it right, you could also inspect, add, remove, and reorder your changes,
  and you wouldn't need the source for either of these operations, either.
  (3) bugs introduced by changes could be fixed the same way the changes
  were put in place, as opposed to rebuilding the system with the previous
  version of the dynamic library or whatever didn't fail.  (4) you could
  communicate your desire for a system-wide improvement to someone who
  could put it in the official sources and you could add your changes
  conditionally.

  compare this to a world where no dynamism is available and people don't
  think in dynamic terms, anyway.  you need to make OPEN change behavior so
  of course you need access to the source!  you want this functionality
  everywhere, not just in particular programs, so of course you need the
  ability to modify it and rebuild from scratch!  since this creates a
  maintenance nightmare, of course you want your changes to be part of the
  core system, too.  to get that to happen, of course you need to be part
  of a huge movement where people compete with eachother for features they
  think they need and the best way to implement them.  this is incredibly
  exhilarating, so of course this is the solution to all the world's many
  problems with missing features in software.

  suppose you drive down the highway and you suddenly want to go some nice
  place you saw just before you pass a forest.  you veer off the road,
  plunge into the wilderness and promptly decide that you need four-wheel
  drive, a huge cutting device in front of your car, much better shock
  absorbers, a bigger engine that could actually run on swamp water instead
  of getting all drowned, and then need an amphibious vehicle to get across
  the river on the far side of the forest.  you can't get all that right
  away after you made up your mind to veer off the road, and This Is Surely
  Somebody's Fault, so now you start this big protest movement to have auto
  manufacturers use Open Car Design by making your own cars and giving them
  away so people can modify them.  the obvious morale of this story is that
  it would have been a little smarter to see if there were another way to
  get there over existing roads or ferries or whatever, even if that would
  cost a lot less and be faster if not Your Way Right Now, and which didn't
  need all this add-on stuff to your car, and perhaps you would just get
  there instead of getting all worked up about all the neat stuff that
  other people had done to their cars while claiming that if it weren't for
  Open Car Design, they would actually never have gotten where they are,
  and they sure wouldn't have built this very versatile car, which they
  talk about a lot more than where they have used it and for what.  suppose
  someone adorns a commercial vehicle with a proprietary navigation system
  that let you discover any and all ways to get from point A to point B by
  talking to it, including scheduling and cost estimates so you could
  decide whether it was worth it, but refused to give it away to Open Car
  Designers.  why would anyone who weren't more interested in building cars
  than Getting There insist on home-made Swiss Army Cars with Open Car
  Design when the _real_ goal had become attainable?  why would Open Car
  Designers _not_ call the producer of the navigation system and find a way
  to deploy it almost everywhere?  and would they insist that a home-made
  navigation system would be better than buying it from whoever invented
  it?  although a ridiculous example, I don't see why anyone would insist
  on a way to do things that does not solves the real problem, but rather
  solve an ancilliary problem that is a problem only because someone is
  very stubborn.

  I keep wondering when and under which conditions the models employed by
  Free Software and Open Source make sense.  I don't think it makes sense
  when the design is _already_ flexible and open and so malleable that it's
  used as an argument against it by the very same people who want to change
  everything, but only Their Way.  in other words, if all you have is Unix,
  certain problems are so staggeringly tall that it takes an extra special
  genius to see what the _real_ problem is because all the people who are
  trying to climb it make it look as if doing something else is stupid.  if
  you have, say, Common Lisp and good access to the exposable parts of the
  internals, with advice support, hooks, etc, why do you _need_ the source
  code?  not that it wouldn't be useful, but would the demand be as great
  if the Smart Route to Yonder Place was at least available to intelligent
  people instead of requiring everybody to scale every mountain just to
  prove a point about inaccessibility?

  the problem is that scaling such mountains is much more fun than actually
  doing anything useful with computers.  mostly, computers are used to do
  Really Boring Stuff, especially if you don't have any dynamism, either,
  and if you're young and getting into computers because it is supposedly
  exciting, you discover that writing quality software for real people is
  tremendously hard and the real rewards are pretty far apart in real life,
  so it's a lot more fun to spend one's time cutting another cycle off an
  interrupt handler or bolt another semi-dynamic feature onto a system as
  flexible as a block of granite.

  the solution is dynamic _software_, but Open Source (etc) is the best way
  to ensure that this never happens on a large scale, because a pale shadow
  of the dynamism people actually need is immediately achievable using the
  static model that people accept without question through fixing a source
  file and recompiling.  ever better ways to overcome this inherent problem
  are created, such as Java and interpreted languages, dynamic linking and
  lots of nifty features.  to help people _find_ the solution, however, we
  need to show them that the problem is aggravated by the way they think
  they are solving the problem today: by making the static software model
  even more entrenched and unmaintainable.

  I think Free Software and Open Source addicts will get down from their
  current high and become tremendously frustrated when the obvious problem
  of having millions of pieces of source code available and they actually
  can't move in any direction because the ability to make modifications
  that they have so lauded in the past turn into a very serious problem
  when much bigger problems require modifications to much larger systems
  than the ones people today think are usefully modified locally.

 1. Free software and open source are a poor way to adapt and grow
    software.  
 2. Dynamic mechanisms that don't even require access to source are
    better.  
 3. Eventually the world will see this.

My measure of agreement diminishes in the same order.

Erik lists a couple of dynamic mechanisms that provide better
adaptability.  My personal favorite, which was not explicitly
mentioned, is the the "Open Implementation" work done at Xerox PARC by
the CLOS-MOP people.  (http://www.parc.xerox.com/spl/projects/oi/)  It
is worth noting that OI is still an area of RESEARCH.  There are
problems with it.  We don't know much about how to design OI
protocols.  We don't even know much about how to DOCUMENT the
protocols we've got.  

Consider, for example, that even amongst Lispers, many of whom
subscribe to OI philosophies, that CLOS STREAMS is still not
standardized and not wholly adequate for all the uses people hope for
it, and that CLOS PATHNAMES hasn't yet been designed.  Similarly for
OI environments, compilers and debuggers.  (Indeed, most mention I've
made of such things on c.l.l has been answered by more silence than
enthusiasm.)

This stuff is hard, and the existing technology doesn't solve all the
worlds problems, though it does help some.

So does free software and open source.  

We're familiar with Dick Gabriel's "Worse is Better" argument (from
http://www.ai.mit.edu/docs/articles/good-news/good-news.html). Gabriel
points out that under the right circumstances, something that gives us
some of what we want can be more successful, and by some measure,
even "better", than something else which addresses some specific issue
in
a fundamentally more direct, complete, or consistent way.

Open Source is a "worse is better" approach to Open Implementation
(and to dynamic systems in general).  

Open Source works (though not well).  It is successful (but it's not
clear how general or sustainable).  Its hard to argue with success.
The fact is, that Open Source is CURRENTLY meeting the immediate needs
of more computer users than dynamic systems such as Lisp are.

However, even with all this modularity, I still relied on source code.
First of all, when using ADVISE you have to know what to advise -- often it
was internal, undocumented functions.  The networking API that I hooked my
trailer code into was also not documented.

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.

Object orientation and dynamism generally only work well if the designer of
the system can anticipate where people will need to customize.  He then
documents an API appropriate for customizing those places.  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.

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

Or something.

(defun do-something (...)
  ...
  (setq z (+ x y))
  ...)

How do you insert your "let" form without rewriting that function?  And how
would you do that without the source code to that function?

Symbolics's ADVISE actually provided a way around this in some cases; you
could do something like:

(advise (func1 :within func2) ...)

and the advice would modify FUNC1 only when it was called by FUNC2.
However, this doesn't work for open-coded functions like + (in fact, you
can't generally ADVISE them at all).

  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.

Just my .2 Euros (or Euro? or Euri? or Eures?) worth.

Cheers

So, if people don't want to contribute: fine, let them fork and keep it to
themselves, no damage done (but to themselves). If they contribute: so much
the better, this kind of system appears to work.

* Philip Lijnzaad
| yes, but at the same time I cannot conceive of a well managed Linux that
| does not give source access.

  sigh.  neither can I.  _please_ note that my argument is not against
  source access, but against giving it to anyone, without restrictions or
  need or any concept of investment in it.  I have argued for source access
  so much that I really did believe it would be very hard to for anyone to
  confuse the issues, but let me phrase it differently in the hopes that I
  can transcend the apparently strong desire to see this as an access vs no
  access issue: I want source access to be granted by the author/owner to
  those deemed worthy as part of building a community of people who agree
  to co-invest and share knowledge.  I don't want source access to be a
  "right" to be demanded of authors/owners regardless of personal values or
  intentions.  on a higher level, I want to solve better the problem that
  source access is solving badly: helping people get software that works
  the way they, individually, want it to work.

| that might seem so superficially, but big part of the motivation for open
| source developers is to do something well, and be known for it (somehwere
| I read the strange term 'egoboo' for this).  The packages/projects that
| really last fall in this category.

  my argument is that you get more egoboost (I'm sure that's the word you
  saw) out of being part of a community with privileges than you get out of
  having access to source code.  with source access to any stray comer, it
  is actually _harder_ to build the community, and the time it takes to
  deal with the eager incompetents is alarming.

| No: first of all, most packages need recompiling of modified source code
| before the package can be said to have adapted.  This is simply not
| convenient, for neither power user nor layman, and there is clearly an
| incentive to make software adaptable in an easier way.  Secondly,
| adaptability necessarily involves generality and therefore complexity.
| Using this to its full extent will likely remain the domain of the power
| user, and this category of users overlaps with those who'd be inclined to
| change source code anyway.

  I think you miss my point, again: at issue is using _dynamic_ languages.
  I'm arguing that source access is a necessity in the static language camp
  and that by giving people access to source in static languages, you deny
  them the opportunity to do what they really want, which is to add or use
  dynamic properties of the system as delivered.

  if you reply, _please_ keep in mind that I'm not opposed to source
  access, nor do I think that source access is not necessary for a number
  of useful things.  I'm opposed to giving people access to the source as a
  means of "solving" their real problem: insufficiently dynamic software to
  deal with the complexity of real-world applications and people.  most
  people who code leisurely fail to appreciate the inherent complexity of
  every problem that actually deals with real people, and I'm NOT talking
  about the user interface, and I want to remove the source access from
  people who are likely to be hurting themselves and the whole profession
  by doing stuff that they should rather communicate in a human language to
  a human developer.

[..elided a car/software analogy...]

For my sins this make me think of the Monty Python Film 'The Life of Brian', a
deep and vitriolic attack on the stupidity of the far left in the UK. For
example "The one thing that we hate in this world more that the Romans,
is...splitters." Much of the white-noise that seems to be generated by the Free
Software community seems to be of this splitter ilk. There should be more
acceptance of diversity and tolerance of other peoples points of view.

A strange coincidence happened I was going for an eyetest yesterday. Bhe
traffic on the road between where I work and the place in town that I was going
to very slow moving. The ten minute that I had allowed 20 minutes for turned
into a 45 minute chug. Such are the problems with living in a seaside town on a
sunny afternoon. I missed the appointment and to quell my raging anger I went
to the local library. Quiet. Calm.

The Library in town has about 3'6" of books on computing. But next to the book
on 'BASIC for the Commodore Pet' and 'Work out your High School Timetable with
the BBC B Computer' was Richard Gabriel's "Patterns of Software".

(now back to the point). In this book Gabriel makes many good point that (IMHO)
have bearing on this:

Firstly, showing me (or infact anybody apart from the bloke who want to write
another cl compiler) the optimised code is pointless or infact worst than that,
it is confusing. To get the kind of optimisations based on I would want,
because I was writing a fast mail editor, or a large MIS or what ever, will not
be helped by looking at this optimised code. More generic patterns or examples
of code would what I needed.

Secondly, software engineering (or whatever you want to call it) is only 40 or
maybe 50 years old. If it were civil engineering and you want to build a
bridge, you have at least 2000 years of people building bridges, patterns,
experiences, writing books, trying out all the angles. Software engineering
doesn't have this. These are exciting times. But we need to give things time to
develop and settle down. And not be too critical of what other people are
doing. They may not have the answer. Or at least the whole answer. But neither
do I. Or you :-)

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 took me some time to read Erik's essay but I found it was well worth the
effort :-) Thank you.

Best Regards,

I've found source access (for pretty dynamic systems, including
Genera), extremely useful, even though I could not redistribute
changes.  Dynamic systems only let you alter behaviour down to a
certain level -- the `chunking level' or something -- below that and
you really need source.

I suspect that I'm agreeing with you here -- to me anyway the
important thing is *access*.

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

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

I think this is then about trust. Or access to big men with sticks. Or lawyers
with big sticks. This is also about me understanding what you are talking
about. I agree with you. There is no reason why licenses cannot be drawn up so
that anyone who asks for it has the ability to see whole or parts of the
source.

I think that anything worthwhile doing is never easy. Its what gives the
satisfaction. Even if it is digging a large hole in the ground with a spade.
I'm good at digging myself into holes ;-)

Have you any thoughts about how this fits in with planned as opposed to organic
development?

I would also like to also talk about things like design mistakes. I think there
are things to be learnt about setting about coding. But one thing that seems
like a big gaping hole in the scheme (sic) of things is the bits before and the
bits after the coding start.

Best Regards,

  $ gcc -O -fPIC hack.c -o hack.so
  $ export LD_PRELOAD=`pwd`/hack.so

Bruno

================================== hack.c ====================================
/* Hack function time(). */
/* It might not be legal to use this code to circumvent evaluation licenses. */

#include <sys/types.h>
#include <sys/time.h>
#include <dlfcn.h>

#define DAYS_BACK  2*30   /* two months */
#define TIME_BACK  DAYS_BACK*24*60*60

time_t time (time_t * ptr)
{
        static void* libc_handle = NULL;
        static time_t (*original_time) (time_t*) = NULL;
        time_t t;
        if (libc_handle == NULL)
                libc_handle = dlopen("/lib/libc.so.6",RTLD_LAZY);
        if (libc_handle != NULL)
                original_time = dlsym(libc_handle,"time");
        t = original_time(NULL);
        t -= TIME_BACK;
        if (ptr)
                *ptr = t;
        return t;

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. The second seems to be doing rather better,
but has scaling problems.

In the proprietary software environment, the "right" is transferred through
payment.

BTW, I think I've also heard "ego boost" pronounced as "egoboo".

I worked at MIT a couple decades ago on Macsyma.  It was not free
software, but it was also not read protected.  Those were simpler
times.  It was written in Maclisp, and everyone had source access.
Later, it had to be translated to a modern dialect and I was the only
one willing to tackle it.  (It was 100,000 lines of pretty intricate
code and took two or three months to convert, thanks to the Lisp
Machine's good tools for helping me.)  The big problem in converting
it was not the mechanical part, but the conceptual part.  Every thing
I changed was a potential incompatibility and I had no idea what
things people were using and what they weren't because they were never
previously forced to tell me, and in principle they could be depending
on even the most obscure little detail of implementation-specific
stuff.  And I have no doubt someone's code broke as a result.  The
code I was responsible for made it through ok, as far as I know.  The
original implementors never came after me with knives or stones or
anything.  But it was darned scary for the reason of knowing I had
this weird obligation not to break things and yet to know that the
definition of "porting" is "change" and an implication of "change" in
a system where sources are known is probably "breakage".  So in a
sense my job was to break things and I felt bad about it.  After it, I
advocated a revised policy which was never implemented but that I
liked: source on demand.  That is, a system where you cannot have the
sources unless you tell me what you need and why then I'll either tell
you why you should use a different thing or I'll give you the source
you need.  (The idea was maybe a bit to be like a database keeping
track of read dependencies in a transaction so that it didn't have to
lock the whole database in order to get a consistent transaction for
one user.)  The problem with openness is that it provides no feedback
about what is being used and what is ignored, and it does not optimize
the case of update by the owner; it pessimizes that in favor of potential
(but not always realized) update by others.

ANSI had a similar problem when we said we wanted to put the draft
specifications out online.  Their immediate concern was "in the past we
have always known who got the spec, so if there were fixes/changes we
would know who to contact".  We had to compromise and say we'd tell people
that they could either continue to get directly from ANSI or else register
their desire for updates/fixes separately or else understand that getting
sources didn't mean a guarantee of any consistency or freedom from change.

People tend to depend heavily on open-source stuff not to change, but it's
absolutely critical in such systems to separate what things will and won't
change.  And for people depending on non-change to register that need.
Too often, it's not done.  I think because a lot of people think that
the whole point of open source is a selfish kind of "i can do whatever i want
and damn everyone else".  But when you build real societies of real people
who really depend on one another, there become rules whether you want them
or not.  The first thing you learn when you gain any REAL power in the
world is that REAL power requires responsible exercise, and that you were
a lot freer to do whatever you wanted when you didn't have any power than
when you do.  Or such, at least, has been my experience.

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

Just like having the *right* for anyone to repair a car
(as opposed to having to return it to the maker) doesn't mean
that everyone will repair one's own car, but that proficient people can
and will do it in a free market.

Dynamism does solve the compositional problems.
But to solve the decompositional problems, you need Reflection,
whose ultimate form is the ability to reify source code.

Access to source is also essential to get rid of the "hardware compatibility"
and "binary API compatibility" problems that tie computer science to
obsolete hardware and system software design.

Free software does not _replace_ project management;
but it _allows_ management to be proficiency-based,
rather than boss-hair-pointiness-based.

Stupid people will hurt themselves and other people stupid enough
to trust them not to be stupid. Let them do so, you just can't prevent that.
Just don't prevent good people from doing good things,
and don't force them to follow the whims of stupid people.
(hey, you had a .sig just like that, once!).

Best regards,

I deny anyone any claim to a "right" to control what I do with ideas
that are in my mind. If I come in possession of a poem, a book, a piece
of software, I may use it as I like. But I deny any "entitlement"
to access other people's private information, either.

If you have a program that no one else has, or are able to write it,
then it is fair that you ask me some money before to disclose or complete
the program; but once you disclosed it to me, I'm free to do whatever
I want with it. You may even convince me not to get the sources;
but if I have binaries, I should be free to copy or hack them.

If your secret software is worth one billion dollar to me,
I'm ready to pay for the _opportunity_ to use it.
Most usually, however, I don't expect people to pay such sums for software
that happens to be here and sits waiting for someone to purchase;
rather, they will pay for incremental and/or tailored development,
customization, bug-fix, support, maintenance, etc;
programmers will likely get continuously paid for small services,
rather than getting paid once (with a big risk)
for an essentially one-shot service.

Now, the recent release of Xanadu shows to me how big software
developed in secret doesn't work:
people reinvent well-known concepts in particular cases,
and cut themselves from widely available culture,
and end up with programs that may have a few interesting ideas,
and a whole lot of stupid cruft.
Actually, this is all an incentive for people to sell their secrets
while they are still worth it, at a fair price,
which is a much better system than intellectual property
so as to promote creation and publication of original works.

Hence, I don't expect _much_ software to stay secret for any great length
in the future world when intellectual property will have been abolished.

Regards,

In other words, if you give your user something, you have to allow them to
use it any way they want to.

Many Free Software advocates don't stop there -- they say some weasel
words intended to make the GPL look like a free license rather than a
pragmatic license.  The GPL fails to be Free because it places a
restriction on the redistribution of the software, so that you cannot
redistribute it unless you're willing to meet certain conditions.

I don't want to make the GPL sounds bad, because it's not.  It's merely
not completely free, as the X11, BSD, or Python licence is.  Claims to the
contrary should be met by a polite correction, and haughty scowls at the
"pragmatism" of the open source advocates should be met with violent
logical slapdown.

So to speak :-).

BTW, oddly enough, this means that I consider "freeware" (typically
MSDOS-only software which costs nothing but includes no source) to be free
software.  You're not given everything, but what you're given you're
allowed to do anything you want to.

I guess the whole point about limiting source code access to non-nitwits
simply isn't very important. The open source model has only gained visibility
fairly recently, and it may take the audience at large some time to realize
that open source doesn't buy you much unless you are willing to really get
involved and develop and contribute to a community. And in practice, ignoring
'demands' and useless contributions from nitwits may be sufficient.

There are two `traditional' (old-fashioned?) mechanisms that might help:
* decide to whom to give the source based upon their reputation (a good
  name vs. great riches);
* and/or based upon other people's recommendations (references).

I would like to note that good reputation is hard to fake.

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

I might agree to let my older daughter have an art supply kit IFF she
shares it with her sister.

The state might agree to let me drive a car on public roadways IFF I
follow the rules.  In my case, I'm additionally required to wear glasses
while I drive.

I might agree to let people use some software of mine for non-commercial
purposes.

I get the impression that there are those here who have a problem with
such conditional use restrictions.  (One problem is in defining
limitations such as "sharing", "non-commerical use", "dangerous use".)