At 09:54 AM 2/13/2002 -0800, Jim McGrath wrote:
>Geoff , Abdulrahman
>I would rather a good product, properly tested (within reason) be released
>rather than something I pay for and don't use. Any body remember
>Protel 99. I thought it sucked. Apparently  Protel must have gotten this
>from others also because we got SE at no additional charge.

My advice would be to watch this list when Phoenix comes out. There are 
some of us who will upgrade no matter what; see what we think of it, and we 
will write about our experiences. That's how it worked with P99, and a lot 
of people waited to upgrade until the list was saying, yes, this is worth 
it. I.e., until SE was released.

This is one of the advantages of a user-controlled list. It cuts both ways. 
It can hurt Protel if we don't like the product, but if they meet or exceed 
our expectations, it can really help.

I'd say that Protel should give us even better crash-recovery protection in 
the software. Once our files are secure -- and disk space is cheap, cheap, 
cheap -- even serious bugs are more tolerable *if they can be fixed 
quickly*. The upgrade should, as in the past, allow dual installation, and 
I'd suggest that it -- or possibly certain kinds of backups during a 
transitional phase -- default to the *earlier* file format. That way, if 
the new program seriously crashes, one can complete one's work with the 
earlier version. Obviously, any new features in the database will be lost. 
But those features are not yet mission critical.

To say this again, perhaps a little differently: the argument against fast 
bug fixes is that they can -- and often do - introduce new bugs and 
therefore, it is said, should be thoroughly tested before release. If the 
core of the program is solid and protected and there is crash recovery in 
place, that argument falls. Sometimes database errors are subtle and not 
noticed for quite some time, so the present system can fail.

Crash recovery, however, would take a file as a base and record all changes 
to the file. Then another tool would take a file and run the subsequent 
changes through it. The change file would be editable. In other words, if 
it crashes again when the same changes are attempted, one can go to the 
change file and delete the last command. The benefits would be numerous. 
Not only could we recover our work with ease, no matter what caused the 
crash -- except for total hard disk failure! -- but, effectively, backups 
could be made at much longer intervals; possibly even weeks or months of 
work could be kept. Change files, if written for clarity, could be used to 
verify ECOs, and some kinds of ECOs might even be implemented through 
change files.

And then, if a bug persists through crash recovery (i.e., repeats), it may 
be much easier for Protel to verify and fix it, by being provided the 
original file and the change file.

There should be a central and public bug report and status database. It 
should be maintained by a Protel employee whose job would be to collect 
reports from all sources, including but not limited to this list, 
categorize and log them and follow up to see that something is done, even 
if it is only to connect it to an earlier report and response. "We are 
examining this isse" should be good for a couple of days only, beyond that 
it might be "we have been unable to reproduce this" or "we have verified 
this but have not identified the cause," or "a patch is in preparation, 
estimated 3 days," or whatever describes the actual situation.

And the bug database should be *really well* indexed and categorized for 
search and browsing. Protel needs to bring the users in much more, if it is 
to take advantage of the tremendous possibilities of user-company 
interaction made possible by the internet.

Secrecy in Beta testing, yes, is the kind of policy that appeals to old 
thinking. One can imagine that there is an advantage to it. But this is an 
"advantage" that comes at a tremendous opportunity cost. Ultimately, the 
company the best serves its users is the most likely to succeed, and 
*secrecy does not serve us.* If the competition learns about beta, even if 
they get a beta copy, they will be playing "me-too" and "catch-up", or else 
it will be of little effect. If beta is a piece of garbage, it may 
encourage them to sit on their imagined laurels, thinking that there is no 
danger. But active users and a responsive company could turn that garbage 
into a diamond, could cause the software to rise like, .... a Phoenix.

I don't think that any CAD company has truly recognized the power of user 
involvement. We completely outclass every CAD company in terms of labor 
resources *and* financial resources, we could write our own thoroughly 
wonderful software *if we were organized.* But we are individuals, and it 
is the lack of organization which is the real opportunity of our time. The 
company that fills that mission is bound for success, major success. We 
already know that Protel has benefited from user interaction, and that has 
been a very limited interaction, mostly one-way. What if we could actually 
have a conversation?

Imagine an electronics company where the CAD department works in secrecy. 
The engineers send e-mail to the CAD department, telling it what they want, 
but the CAD department does not reply until the project is done. Then they 
send it to the engineers for examination, and then, again with no 
conversation, CAD fixes the reported problems until they are all done to 
CAD's satisfaction, and then the whole thing is sent to engineering again. 
Some companies are actually like this! Let me say that if I find out that a 
company is like this, I'd avoid their stock like the plague, they will not 
be able to compete for long, they might have some success because of 
history, but they are doomed unless they wake up.

The only reason that secrecy seems to be of value is that it is the 
industry norm. Like dongles. *Users do not benefit from dongles,* and it is 
quite questionable that CAD companies benefit from them either. They can 
make piracy difficult, to be sure, but it is quite unclear that piracy 
actually harms the CAD company, and, as I have written many times in the 
past, it may actually help the company unless it becomes the norm in the 
large markets.

The first question that any company should ask, considering a course of 
behavior, should be "will this benefit our customers/clients." If so, or if 
there is no injury to the customers or clients, then the next question 
could be "will this benefit us?" If it harms the company, then the company 
can look at the cost/benefit ratio, since every expenditure could be 
considered "harm;" obviously, the company must tolerate some "harm" in 
order to do business at all.

But dongles and certain other protection schemes harm the users, and the 
harm is not trivial, as anyone who has had a dongle fail when a job was due 
knows. So even a large benefit to the company could be problematic. So harm 
to customers should be the kiss of death for any proposal outside pure 
desperation. (In this case, again, "harm" must exclude normal and expected 
or otherwise reasonable expenditure. If a price increase is *perceived* as 
excessive by a majority of customers, that would be "harm" for this purpose.)

Protel could definitely earn $2K per year by providing really good support. 
I think, however, that they may unduly restrict their customer base, and, 
as I have mentioned, there are reasons to think, already, that it is not 
going to be $2K per year unless there is some way for customers to receive 
a lower level of service or to be maintaining a reduced set of servers or 
something like that.

In moving Protel toward the higher-priced CAD packages, even if 
functionality and/or service improves accordingly, there is the problem 
that the lower-end customer base is abandoned. Accel made this mistake with 
Tango, and I think it cost them dearly. Protel needs to maintain a 
graduated entry-level path into the software, or it is dropping a large 
market. Yes, the higher-end market is larger, but it is pretty well 
occupied, it will take a long time to penetrate it, CAD inertia being what 
it is. And this is why piracy can help Protel, it maintains an entry into 
the software, and an engineer who uses a pirated copy and likes it and 
becomes familiar with it may well, indeed is likely to, come into a 
position where he is asked "What should we buy?"

But relying on piracy for this is obviously undesirable if there is a 
better way. This is not a simple problem, but I think it's worth solving 
for Protel. Many CAD systems have pin-limited or layer-limited versions, 
that's one possible solution. Feature limits are another. Another is 
software rental or installment purchase, possibly with partial refund on 
surrender of license.

Consider deciding to pay $8000 for a Protel license when you are a 
struggling start-up. The consider paying $200 or $300 per month, with the 
first month free. You could put it on a credit card, but many small 
startups are already whacked pretty deeply into credit cards. Protel could 
be making that profit instead of the credit card companies! It would cost 
them almost nothing, which I why I thought it fairly dim for Protel USA 
sales to be really persnickity about selling on 30-day terms. The only 
reason I can see for doing this is that accountants think of it as a big 
loss if such a customer does not pay. If the customer pays almost 
*anything*, it is not a loss, it is a gain. Anything beyond perhaps $50 or 
$100 is profit, pure gross profit; and the whole sale can be booked 
immediately. Sure, there needs to be a reserve for bad debt, but that is 
true for any debt. That's the software business! It is not like any other 
kind of manufacturing or publishing (except, of course, for on-line 
publishing or publishing on CD).

hmmm.... I do go on a bit, don't I?

Abdulrahman Lomax
Easthampton, Massachusetts USA

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to