NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/graphics/13479

Internet Message Format | 1993-01-06 | 12.5 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!swrinde!network.ucsd.edu!dudley!nadeau
From: [e-mail] (Dave Nadeau,,45062)
Newsgroups: comp.graphics
Subject: SDSC Image Tools source
Date: 6 Jan 1993 23:24:11 GMT
Organization: San Diego Supercomputer Center @UCSD.
Lines: 244
Distribution: world
Message-ID: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: dudley.sdsc.edu


In response to the SDSC Image Tools release posting, Alaxander-James Annala
wrote:

    >I don't know what experience with other supercomputer centers may
    >be -- however, the gnu people don't have trouble with supporting
    >'modified' copies of their software.  From a user's perspective,
    >these binary only distributions can create problems -- for example
    >ncsa xdataslice from ftp.ncsa.uiuc.edu was available only binary
    >-- it has serious errors which caused it to crash -- when you got
    >down to it the real reason for binary only was the source is real
    >messy -- not particularly professional coding -- and that's a big
    >part of why it bombed.  I've fixed most of the common errors for
    >our environment -- and ported it to the Alliant FX/2800 (28 i860
    >SMP shared memory machine) -- only because a programmer sneaked a
    >source copy to me under the table.
    >
    >The same thing could probably be said about SDSC's proprietary SYNU
    >code -- the imaging/microscopy project was presumably funded with a
    >lot of public dollars -- but the project now claims it has to levy
    >a 'distribution fee' in order to make people report how the system
    >is being used -- and the system was pretty much limited to running
    >on SGI machines (which we don't have available at USC -- we mostly
    >have sun's in the labs, alliants at central sites, and some pc's
    >running various flavors of unix).  I'd like to see SYNU released in
    >source code form so it can be ported to new platforms and/or fixed
    >when errors appear -- and so I can understand what it really does
    >to my data.
    >
    >It's all and good to give away free binary code.  I would be the
    >first person to applaud such generosity.  But, I have a really bad
    >feeling about binary distributions -- I don't believe they are in
    >anyone's best interest -- except perhaps in the interest of a few
    >people who might want to develop products under government money
    >- and then put the finishing touches on with a few private dollars
    >before going to market.  This has already happened to several nice
    >scientific visualization systems -- and it puts them out of reach
    >for graduate students and new faculty who would most likely benefit
    >from their functionality.


As the developers of the SDSC Image Tools, we would like to respond to
this posting.


           Source releases and other topics for the
                SDSC Image Tools
           ----------------------------------------


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.

2.  The SYNU project is a different product, written by different people,
    funded from a different source, and with different aims.  While originally
    developed at SDSC, SYNU is now under the auspices of the University
    of California, San Diego (UCSD).  They have chosen to limit distribution
    of SYNU source and that is their decision to make.  As with any product,
    you are free to purchase the product, or not.  If enough people do not
    purchase it, the product's distribution strategy will be changed.
    Regardless, the UCSD SYNU product has nothing to do with the SDSC Image
    Tools product, other than the fact that we support their image file format.

3.  Coding style judgements of other people's code are opinion at best.  The
    style used by NCSA for their xdataslice may or may not be sloppy.
    However, this has nothing whatsoever to do with the SDSC Image Tools.
    They were developed by different people at different centers at different
    times for different reasons.  Judge us by our words, not those of others.

    We are, in fact, quite proud of the SDSC Image Tools.  They have proved
    very easy to maintain, very portable, and very expandable.  We include
    source for the tools and some of the file formats in the distribution.
    You are free to examine this source and evaluate its programming style.
    The style used in the distributed source is identical to that used in the
    rest of the non-distributed source.  Make your own judgements.  We welcome
    your comments.

4.  Supporting a source release is non-trivial.  The following table lists
    a number of release possibilities based upon the type of release (binary
    or source), the type of questions support staff are prepared to answer
    (none, binaries only, released source, or modified source), and the
    domain upon which bugs will be fixed (released source, or user source).

                Image Tools
           Release    Questions    Bugs fixed
        #  Type        Answered for    in

        1  Binary    nothing        our source
        2  Binary    binaries    our source
        3  Binary    our source    our source
        4  Binary    mod source    our source

        5  Binary    nothing        your source
        6  Binary    binaries    your source
        7  Binary    our source    your source
        8  Binary    mod source    your source

        9  Source    nothing        our source
        10 Source    binaries    our source
        11 Source    our source    our source
        12 Source    mod source    our source

        13 Source    nothing        your source
        14 Source    binaries    your source
        15 Source    our source    your source
        16 Source    mod source    your source

    This is certainly a simplification of the problem and is presented for
    discussion purposes only.  No flames please.

    Any support choice that offers a bug fixing service on "your source"
    takes a lot of human resources, disk space, and a wide variety of hardware
    and OS configurations available for the support people.  This is a very
    desirable situation, but one only large software developers can afford.
    We aren't that large.  Additionally, this is free software, so we have no
    income from it to pay support people to answer questions.  This situation
    rules out options 5, 6, 7, 8, 13, 14, 15, and 16.

    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.

    Options that release source but only answer questions on binaries aren't
    realistic.  Whatever you release, you get questions on.  This rules out
    options 10 and 14.

    When doing a binary release, answering questions on modified Image Tools
    source can't happen, so these options are bogus.  This rules out options
    4 and 8.

    So, we have the following options left:

           Release    Questions    Bugs fixed
        #  Type        Answerd on    on

        1  Binary    nothing        our source
        2  Binary    binaries    our source

        9  Source    nothing        our source
        12 Source    mod source    our source

    Shareware is often released using option 1.  What you see is what you get.
    No questions are answered.  No support is promised.  This is frustraiting
    for users and not a good option for a package the size of the SDSC Image
    Tools.  We have rejected this option.

    Similarly, option 9 is uncool, but is the case with most source released
    to the net.  If you see a bug, fix it yourself.  No questions are answered.
    No support is promised.  We have rejected this option as being an
    inappropriate attitude for a national supercomputer center to have.

    In a few rare source release cases, the releaser is big enough or the
    source is small enough that option 12 is possible.  The Image Tools,
    however, are over 100,000 lines of C code that are released on a dozen
    architectures.  Option 12 is admitedly very desirable, but just isn't
    practical for us at this time.  We are forced to reject this option as
    well, though this is what many on the net wish us to do.

    This only leaves option 2.  We release binaries, plus sample source for the
    tools.  We don't release source for the bulk of the library because we
    simply can't support user's questions.  And we do get user's questions,
    sometimes hundreds a day!  The Image Tools are used in virtually every
    graphics lab in the world (pretty daunting to think about).  We've had
    4,000 site uploads from our anonymous ftp area, and an unknown number of
    additional uploads from major network redistribution centers in the US
    and Europe.  Each of these uploads expands to between 1 and 10,000 users
    (such as large government labs and universities).  Our site alone has
    around 3,000 users.  At the low end we have at least 7,000 SDSC Image Tools
    users around the world.  At the high end it's over a million!  A
    conservative guess is around 50,000.  We have people on staff that just
    answer questions all day!  And that's with a binary release only.  A
    source release would easily quadrupple the number of questions we get and
    significantly increase the amount of time it takes to answer them.
    Increasing our support staff accordingly is simply not practical...
    especially for freeware.

    This leaves us with two realistic options:

        1.  Release for free and pay for a binary-only release
            question-answering support staff out of our own pockets.

        2.  Charge for the release and pay for the support staff
            with the income from the software distribution.

    As a free service to the net we have chosen option 1.  We believe that
    this is the most desirable for the user community given our constraints.

5.  One of the most common reasons users site for why they need source
    to the SDSC Image Tools is a desire to add additional image file formats.
    As of the version 2.1 SDSC Image Tools (now available from anonymous ftp),
    source code is provided for the master file format attribute table
    "imfmt.c".  This table is an array of C structs, each one of which
    describes a supported image file format and points to the read and write
    handler routines for that format.  To add another file format to the
    Image Tools, add another struct to the table and write the appropriate
    handler routines.  Compile that source and merge it with the released
    object files for the rest of the library.  Relink the command-line tools,
    and you're done.

    To help users get started on writing new read and write handlers, sample
    source for the Compuserve GIF, AVS X, PostScript, and EPS file format
    handlers has been included in the version 2.1 release.  A document on
    how to write handlers is planned, but is not currently available.  Pending
    the release of the handler documentation, please direct questions on
    writing image file format handlers to me at:

        Dave Nadeau
        [e-mail]

    I'll be happy to explain recommended procedures, tricks, and techniques
    in file format handler authoring.  Additionally, we would be pleased to
    include your file format handlers in future SDSC Image Tools releases,
    with credit to you, of course.  Should you wish to include your code in
    the release, you would have the option of releasing to the net the source,
    or just the binaries for your format handlers.


The SDSC consultants are prepared to answer questions for free about the
SDSC Image Tools, and other SDSC products and services, during business hours
Monday through Friday.  They may be reached by phone at [phone] or
by email to [e-mail].

Thank you.


---
Dave Nadeau                        [e-mail]
Advanced Scientific Visualization Laboratory        [phone]
San Diego Supercomputer Center
P.O. Box 85608   San Diego, CA   92186-9784