🚀 go-pugleaf

In article <1ifpibINN2ov@network.ucsd.edu>, nadeau@sdsc.edu (Dave Nadeau,,45062) writes:

| 1.  The SDSC Image Tools are provided for free.  We do not charge for their
|     distribution or intend in the future to charge for their distribution.
|     We also do not intend on selling the source to anybody who will charge
|     for their distribution.  The SDSC Image Tools are a non-commercial product
|     provided to the network at large because we think people will find them
|     useful.  There really are no lines to read between and no ulterior motives.

  This is fine, and I wish I saved the original posting about where to
get it, but I'm sure archie will find it when I figure out the right
name.

|     Any support choice that releases source will inevitably get questions on
|     modified released source.  Well-meaning sysadmins and graphics hackers
|     will "fix" bugs and add "features".  Our support staff will be faced with
|     trying to help a user debug code that is failing not because of our
|     source, but because of unseen "fixes" to our source made by somebody else.
|     The only way to detect this situation is to upload the user's modified
|     release source and do massive diffs to find where things have been "fixed".
|     This is pretty non-trivial and requires a large support staff, lots of
|     disk space, and lots of hardware and OS configs.  Again, we are not that
|     large.  So, options with "our source" in the middle column are effectively
|     the same as options with "mod source" in the middle column.  This reduces
|     the option set by droping out options 3, 7, 11, and 15.

  I have released at least 15 packages in source through net source
groups, back as far as net.sources. I just haven't gotten this type of
problem. I've been associated with zoo for some years, and I haven't
heard of this problem. I've seen the info-ZIP work group generate a load
of software, and what happened was that people sent us suggested fixes
rahter than distributing their hacked code. I've seen PBM keep growing,
and Jef just adds the best fixes and new programs to the package. I've
watched the C-Kermit program grow over many years, aided by people who
wrote various changes and sent them back to the original author who kept
releasing new versions.

  In short, it's possible, but if you release bugfixes on a timely
basis, people will always want your official version rather than a
hacked version. There is a LOT of experience with this, and virtually
all of it is good.

  On the upside, you will no longer have to compile for every supported
machine, because people will do it for you, and send back portability
information, too. And they'll try your package on every new compiler and
machine which comes along, long before you get the chance.

  In my experience large groups write poor software, but they are great
tester and reviewers, and fixers of small subtle bugs. Posting software
is and getting these little fixes is like peephole optimizing. The
original author can keep track of the changes and release official
versions, while the testers and fixers can do final QA and ports to more
platforms than the original author.

  I hope you change your mind, not that I wouldn't use the binary if you
happened to have compiled for my machine, but I'd rather put the source
in a source tree and build it for every machine type on my net, as I do
for X, Kermit, and other programs.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.