GMeredith.ES@PARC-MAXC.ARPA (01/24/84)
The purpose of the nets is the exchange of information,including reports such as yours. If the supplier of a product does not have access to the nets for reply, the fact that he is or is not aware that the report is being made does not change his position. Just to be fair, it seems to me that the supplier should be aware that a few thousand potential customers are sharing comments. This should be presented not as a threat, but as information given in the interests of fairness. You might accidentally benefit from the supplier's reaction to net exposure, of course. Guy B. Meredith
jim%rand-unix@sri-unix.UUCP (01/24/84)
Yes, it's amazing how differently SPR's are handled. I had the same response as you to my SPR to Manx Software on their IBM PC->Apple C cross-compiler. However, I've also had one good experience: Lattice, Inc. actively solicits SPR's for their C compiler and responds to them, often in a timely way. The first user to report a bug gets a free update to the next version, and so far the next version has had the bug fixed. So there are good guys out there. Jim Gillogly I/ / randvax!jim I_/ jim@rand-unix I
MKrigel.es@PARC-MAXC.ARPA (01/26/84)
"Just to be fair, it seems to me that the supplier should be aware that a few thousand potential customers are sharing comments. " I recently wrote to the makers of PFS about some of the things I liked and disliked about PFS:Write. I received a letter back acknowledging my points and received more feedback than I expected possibly because I ended the letter with: cc: info-micro@brl-vgr.ARPA, info-apple@brl-vgr.ARPA, AppleUsers^.es@PARC-MAXC If you are going to tell the net, I agree, let the manufacturer know about it. I now have a direct contact within the company. It may do me no good, but I can write to a person directly instead of a non-discript department. Marc
jsweet%uci-750a%rand-relay@sri-unix.UUCP (01/26/84)
From: Jerry Sweet <jsweet%uci-750a@rand-relay> I've often wondered what various companies do with Software Problem Reports (SPR). Once, when I sent in a report on Intel's Pascal-80, I received a phone call from one of their support people, who went over the report point-by-point with me. Another time, I called up Microsoft to report problems with their M80 assembler, got connected with a guy who tried out each problem right then and there, saying "yup, that's a problem, all right," but nothing else very constructive. Back in October, when I sent an SPR to Manx Software on their 6502 C compiler, I expected some sort of reply, even if it was nothing more than an acknowledgement of having received the SPR. No such luck. I finally called them up this afternoon and got a very candid response from one of their technical people regarding what happens to their SPRs: they get thrown into a slush pile and they rot, for the most part, which is apparently what happened to mine. To be fair to Manx however, this guy also said that they planned to change the way that they handled SPRs real soon now. Here's another horror story, this one about Anix 1.0 (essentially a shell program for Apple DOS) from Lazer Microsystems (yeah, amusing product name, ain't it?). I sent in a long SPR (about six pages, as I recall), but never received any sort of reply. When I called them up several months later, I found out that they had no plans to support Anix any further, in spite of direct claims to the contrary in the documentation (what there was of it). Made me feel warm all over. Well, about the only thing I can say about software right now, based on these experiences, is that it isn't a consumer's market. A company that takes any time at all answering its SPRs is something to be cherished. Probably the only case in which you're guaranteed a response is where you have some sort of printed media power, as (for one example) Jerry Pournelle seems to have. It would be nice if info-micro, or access to the net in general could provide this kind of potential power, but it would be wrong to hold it over the head of a software supplier if he couldn't reply. I don't see it as wrong, however, to make an after-the-fact report such as this one. Comments? Suggestions? -jns
sherouse@unc.UUCP (George W. Sherouse) (02/12/84)
I tried to mail this, but it wouldn't go: > Sorry, not an Arpanet gateway! > > > *--------------RETURNED MESSAGE---------------* > > Date: 28 Jan 84 23:39:48-EST (Sat) > To: jsweet%uci-750a%rand-relay@sri-unix > References: <15895@sri-arpa.UUCP> Note the confused look on my face. On rereading it, it seems sufficiently general for the net, so here goes... ---------- Two comments: 1) I have had a very similar experience with the Manx Aztec C for Apple. (Yours wasn't a problem with long integers was it? If not, be forewarned.) I find this sort of sloppy (non)support of paying customers frustrating as hell and say so every chance I get. But, golly, isn't that compiler nice? (... I mean the parts that work...) 2) I used to be on the other side of this. I had a stack of SPRs, some dating back 4 years, quite neatly filed away awaiting responses. For the most part, the ones that were older than six months were part of my orientation package when I joined the company. By the way, this was not a micro company and it is highly unlikely that you would ever have had any dealings with them, their market being extremely specialized. Anyway, it can happen that SPRs don't get answered because they are a) not serious enough to worry about right now or b) too difficult to worry about right now. In many cases the same staff who generate new software are the ones who also have to answer the SPRs. New applications bring in new money, answered SPRs do not (directly). Hence, the attitude of management is easily predicted. In my case, if I couldn't deal with an SPR directly, I tried to at least fix it for the (inevitable) next release and send along a friendly letter closing the SPR then, also suggesting that it might be worth the customer's while to get the new release for a nominal charge. This tended to keep everyone relatively happy. Incidentally, it really is a no-win situation for the software house. If you assign your (always insufficient) staff to chasing SPRs, you don't get the updates out and everybody gets upset. I noticed that it is usually the same customers who squeal loudest about minor bugs who also squeal loudest when a promised release is late. And so it goes... In short, as a consumer I want service yesterday. But, having been on the other side I know why I'm not getting it. Not that that helps. ------------------------- I would add that the software I was involved with was an *applications* package. In general I think it is more critical that *systems* software like OSs and compilers be serviced in a timely fashion. Of course, this is a wild generalization which ignores the realities of, say, factory-automation software and the like. But from the software developer's perspective, if your tools don't work you might as well go home. In this respect, kudos to S&H Software (of TSX fame) and rude noises to Manx. << The views expressed are my own and should be everyone else's. >> (the real) George W. Sherouse <sherouse@unc>