Path: utzoo!attcan!uunet!lll-winken!sun-barr!cs.utexas.edu!sdd.hp.com!hplabs!hpfcso!hpfelg!koren
From: koren@hpfelg.HP.COM (Steve Koren)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ASyncRun() doesn't work with pipe:xxx!
Message-ID: <13920090@hpfelg.HP.COM>
Date: 13 Sep 90 01:39:25 GMT
References: <13920086@hpfelg.HP.COM>
Organization: HP Elec. Design Div. -FtCollins
Lines: 66


> products come with source? Of course they *should* come with source, but
> they don't. This isn't a peculiar feature of ARP. Actually, I have yet
> to hear an argument for not including (for an added charge, of course)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> source code with a product that makes any sense. IMHO they are just
  ^^^^^^^^^^^
> throwing away money, because a lot of people would be willing to pay

For commercial products I can see many arguments for not including
source code.  However, I think there are still several for FD (freely
distributable, which is not = to PD) software.

The reasons I have not and will not publicly release source code to
SKsh until the "last" release are:

  * As soon as I do, modified versions will show up and be distributed.
    Some of these will be fine, likely better than the original.  Some
    will introduce bugs and break things that currently work right.
    It is the second class that I'm worried about, as 1) you can bet that
    people will call me when the modified versions break, even if someone
    else introduced the bug, and 2) they still have my name on them,
    and someone running a modified version which does something traumatic
    will likely avoid any future versions, even unmodified ones.  If
    I had an infinite amount of time to dedicate to the project (and
    others like it), I would be more inclined to release source right
    away.

  * I need to do alot of work yet to remove system specific dependancies
    from the code.  For example, the test scripts currently assume that
    certain things are in certain directories.  This is true for my system
    but not in general.  These things need to be hunted down, eliminated,
    and then tested on a system which doesn't "look" like mine before I
    can release the source.  This would require *alot* of time and energy
    which I don't have right now.
   
  * The source code is currently nearly 23000 lines spread across multiple
    directories.  As such, it is very complex, and since only one person
    wrote it in the first place, others are not likely to forsee strange
    problems which might crop up with certain changes.  There are
    test scripts which try to guarantee a certain level of robustness and
    upward compatibility, but I can guarantee, with 100% certainty, that
    some people will not run the test scripts before releasing another
    version.  Thus noncompibilities would be introduced between multiple
    parallel versions, which is an ugly problem if I want to release
    subsequent versions.  (It is actually an ugly problem anyway, but
    if I say "this is the last version from me", I can also say, "you're
    on your own with custom modified versions).  I can guarantee a similar
    thing for documentation updates, keeping the Check?.? scripts up to
    date, etc.  There are many "grunt-work" tasks to be done which are
    not fun at all, but must be done to give the software a quality feel.

My solution to these, and other similar problems is to simply not
give out the source code until I think I am *done* with the project. 
Even though the software is free, I would for the moment like to retain
a certain amount of control over what happens to it.  Giving away the
source also gives away this control to a certain extent.

I'm sure other people who release FD software with no source have
similar thoughts.  I hope this doesn't seem like an unreasonable
philosophy!  I would like very much to give my software a "professional"
feel.  There are certainly problems with it (for example, it doesn't
currently run on 3000's for an unknown reason).  But I think I can,
for the moment, keep the quality higher with this policy.

   - steve (koren@hpfela.HP.COM)