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? [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/[email protected] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
