Archiving Software

[Dave Dunfield]

> > > > I would spend many hours helping people understand it, explaining why
> > > It's odd, but I've released a number of classic computer-related programs 
> > I've been running a mail-order software company selling development tools
> > for embedded systems (of my own creation) for over 20 years. In the early
> > years, I distributed source code, and I would estimate that a full 80% of
> > the technical support revolved around issues relating to people who didn't
> > "know what they are doing" trying to make changes to my tools, and
> > expecting me to show them how, and to fix it when they made horrible
> > messes of it.
> 
> I've seen plenty of xource code released on the terms that the 
> manufactuer will not support it (I am sure some old HP calculator hackers 
> here remember those wonderful NOMAS listings for the 41 and 75 
> machines...). And of course the GNU license does not require you to 
> support anything.
>...
> It may be different if you're _selling_ something (and thus feel morally 
> or legally bound to support it), but for free software I don't see the 
> problem with telling people to get lost if they expect help in modifying 
> or understanding it.

I would not feel comfortable in releasing the code unsupported until I am
confident that it is mature and stable - Imagedisk is not at this point yet
(It's getting there, but I'm not ready to screw the cover on yet). Until it is,
I will keep it to a single platform and the development under my control.


> That said, I have received a lot better support from free (as in GPLed) 
> software authors than I've received from any software company. And in the 
> latter cases, I was simply trying to get the program to behave as 
> advertised, to do the job it was sold to me to do.

And this is relevant to me how?
For the record, in the heyday of my software company, I would spend about
3 hours a day answering tech email - every tech problem would get answered
the same day if possible. Even now I service my company mailbox "first thing"
each and every day.


> > On top of that, published source to my C compiler was ripped off in at least two
> > instances and used to create competing commercial products by companies
> > which were beyond my ability to persue.
> 
> You have already said you don't consider that Imagedisk is 'commercial' 

Here we agree.

> so this IMHO is totally irrelevant.

and here we disagree - this particular branch of the thread was not written
about ImageDisk - it was written in response to your statements about the
wonderful experiences you have had releasing source code. The intent was
to educate you to understand that my experiences have not been so
wonderful.   You know ... try and see how it looks from the other side and
all that.


> > about "having" to invent your own image format because you don't have
> > access to my source (when the existing format is fully documented) only
> > reinforces this impression.
> 
> It is my bitter experinece that documented interfaces (be they file 
> formats, routine entry/exit conditions, or hardware specs) have 
> undocument quirks and odd behaviour, and the only way to be _sure_ is to 
> read the sources or schematics as appropriate.

Now this is interesting - your "bitter experience" is justification for your assuming
that I have not done a good job at documenting the ImageDisk format and therefore
totally dismissing my work, yet my "bitter experiences", and my conservative
approach to releasing source code as a result of them are blown off with "you
deserve no respect from me" ... Seems to be a bit of a double standard here.

For the record, the Imagedisk format is quite simple, and completely documented
(It takes only one page to describe). If you want to "investigate it", Image some disks
and using the document, take apart the image and see if it lines up.

If you still don't take my word for it, you can use IMDU to convert the image to a
straight raw sector dump - just the data from all the sectors strung out in a big line
- I don't think you can get any simpler or more straightforward that this.


> For example, when I was writing my HP calculator file translation 
> utilities, I didn't just trust the information given in the manuals 
> (which was wrong in some cases), I spent many an evening reading the HP71 
> ROM source code in the IDS volumes. And the HP41 source listings for that 
> matter.

And this is relevant to my work how? (a variation of your response above)


> I guess you think I want ao make a few changes to your program and 
> recompile it. Not so. I have explained in another message why I'd like to 
> read the sources.

And I have offered to make them available for "personal reading", so I don't
see what the problem is.
 

> And if you think that's 'ripping off your code', well, maybe it is, but I 
> don't know a single programmer or designer who _doesn't_ read other 
> people's code/scheamtics.

Definately missing my point - it has nothing to do with worrying about people
"ripping off" of my code - It has to do with my wanting to keep a door closed
that I am not ready to open yet.

 
> > If you look back on the early ImageDisk postings, you will find that I stated
> > that I would release the source code when I felt it was mature enough, but
> 
> And that, I suspect is the real reason. I can actually understand that, I 
> once designed an I/O interface for the HP48, and I didn't release the 
> schemaitsc until I'd built everything at least twice (once on stripboard, 
> once on PCB) to help prove the design was sound. %deity that was an 
> expensive project.
> 
> Not being a programmer, I send out really awful code sometimes, but I can 
> understand why you'd not want to do this.

Well ... at least thats something.

At this point I am unwilling to clutter up the list with what has gotten very far
away from anything relevant to it's charter, so I will bow out.

--
dave04a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Collector of vintage computing equipment:
                http://www.parse.com/~ddunfield/museum/index.html