Black Box 4

home *** CD-ROM | disk | FTP | other *** search

/ Black Box 4 / BlackBox.cdr / textinfo / guide.arj / GUIDE.TXT < prev next >

Wrap

Text File | 1990-05-15 | 82.7 KB | 1,686 lines

PROGRAMMER'S GUIDE Copyr. 1985, 1989, 1990 Nelson Ford January 1, 1985 Major Update: January 1989 Continual Updating Since Public (software) Library P.O.Box 35705 Houston, TX 77235-5705 (713) 514-6294 - CompuServe 71355,470 A limited license is granted to reprint short extracts from this guide as long as credit is given and a copy is sent to the address above. Individuals may copy this guide for each other as long as no fee is charged. No other copying of this guide is permitted in any form without the express written consent of the editor, Nelson Ford. ---- NOTICE: ALL INFORMATION, TIPS AND ADVICE IN THIS GUIDE ARE PRESENTED TO "GUIDE" YOU INTO AREAS FOR YOU TO RESEARCH AND STUDY IN MORE DETAIL ON YOUR OWN. IN NO CASE WILL NELSON FORD OR OTHER CONTRIBUTING WRITERS BE LIABLE FOR DAMAGES RESULTING FROM YOUR ACTING UPON INFORMATION THAT IS CONTAINED HEREIN. IN PARTICULAR, AN ATTORNEY SHOULD BE CONSULTED ON ANY QUESTIONS OF LAW BEFORE FOLLOWING ADVICE CONTAINED HEREIN. PROGRAMMER'S GUIDE Contents CONTENTS Forward - Does shareware work? Introduction - different marketing approaches. Chapter 1 - Marketing Shareware getting publicity sending out your program advertising a "pure" shareware marketing strategy shareware vs retail-only programs - the user's point of view - the author's point of view do users pay? crippled demo's pd/shareware distributors a sample shareware licensing agreement other protective measures sample disclaimer of warranty selling registered versions through shareware distributors selling registered versions through retail distributors Chapter 2 - Making Your Program User-Friendly on-screen help rules for BASIC programmers make the program and keys work naturally let the user customize put things back where you found them Chapter 3 - Writing the Documentation keeping your files together number each release multiple documentation files formatting, printing the documentation contents of the documentation file Chapter 4 - The Association of Shareware Professionals ("ASP") goals of ASP membership criteria vendor standards meetings on IBMNET Chapter 5 - Where to Get Supplies and Services telephone: 800#, answering machines, answering services disk labels blank disks disk duplication disk mailers & boxes credit card processing manual publishing Appendix A - Letters from Authors David M. Berdan, author of File Express Edward H. Kidera, author of PC-KEY-DRAW, letters #1 & #2 Frank A. Bell, author of Newkey PROGRAMMER'S GUIDE Forward FORWARD The purpose of this guide is to provide tips on marketing and writing programs that look and work like top-notch professional software. Another purpose is to get programmers to share their ideas with each other. This guide is also going to new program authors, so some of the points may seem obvious or elementary to experienced authors. The information and opinions in this guide are drawn from several areas of the author's experience: as author of a shareware program, Diskcat, which has been in distribution since September 1983 (and many other shareware programs since); as head of the Public (Software) Library since 1982, during which time I have reviewed many thousands of pd/shareware programs; as author of the column "The Public Library" for the late SOFTALK magazine; and as software reviewer for other publications. Information has also been solicited from shareware authors and users via correspondence and surveys. The complete text of the more significant letters is presented in Appendix A. This file is formmated for printing. Start the print head just below the top of the paper and copy the file to the printer from DOS. DOES SHAREWARE WORK? Andrew Fluegelman started the formal shareware concept (he trademarked the name Freeware for it). Andy did not say that everyone who spent an afternoon writing a program, uploaded it to a couple of bbs's and sat back and waited would get rich. He said that the shareware approach provides a way to let the users decide (rather than the people who control the advertising prices) which programs should succeed, based solely on the quality and usefulness of the program. Shareware is not some magic way to get rich from trivial or substandard, amateurish products of limited appeal or usefulness. Some shareware programmers who have failed prefer to blame the shareware approach rather than themselves. They think that millions of people are using their programs without paying and that the shareware concept just doesn't work. To these people we always reply: If shareware doesn't work, how are Button (PC-File), Wallace (PC-Write), Smith (Procomm), and Magee (Automenu) all making over a million dollars a year at it? "These are exceptions!" they reply. Sure they are exceptions. Anyone making a million dollars a year at anything is an exception. Many others are making lesser, but respectable, incomes. Not bad for a business that anyone can get into at virtually no up-front cost. Yes, shareware definitely works. Like anything else, how well it works for you depends on hard work, ability, and even a little bit of luck. And even luck often boils down to being prepared to take advantage of opportunities when they coming knocking. We hope this guide will help you get prepared. PROGRAMMER'S GUIDE Introduction INTRODUCTION You wrote a program to fill a particular need that you had or maybe just for the fun of it. Now you are thinking about selling it, but you are not sure of how to go about it. Well, what you do next depends on how seriously you want to pursue the marketing of your program. If you are very serious, you may find out that your work has just begun, and that the programming was the easy part. Going All Out: Some programmers quit their old jobs, hire people to write their manuals, have the manuals and disk labels professionally printed, send copies of their program to hundreds of user groups and shareware distributors, get an 800 number and credit card accounts, hire staff to take and fill orders and provide customer support, go to trade shows such as Comdex, go on speaking tours to user groups, advertise and publish product newsletters. They arrange deals with distributors and dealers in the U.S. and overseas. Taking a Smaller Step: Some programmers, not ready to go all out, keep their "day job", but still get manuals and labels printed, send out copies of their programs to lot of groups and upload to bbs's. If demand grows, they may hire an answering service to take orders. Some just have an answering machine. Others only take mail orders and don't publish a phone number at all. Taking it Easy: The least successful, or at least slowest to succeed, method is to upload your program to a few bbs's with a request for payment from satisfied users. You don't send out printed manuals, take phone orders, or hire any kind of staff. This is how Fluegelman first envisioned shareware working. When it does work, it works slowly. Take Vernon Buerg's LIST program, for example. Buerg originally released it in 1983, at first asking for nothing, later asking for a voluntary payment of $15. He relied completely on word of mouth, not trying to push it at all. As LIST slowly gained in popularity beyond the circle of hackers, magazines started recommending it in articles. Today, Buerg gets a healthy income from LIST. This is indeed a 1 in 10,000 story, however, and it paid off only because Buerg was willing to continuing supporting users and working on the program for years before getting substantial payback for it. Letting Someone Else Do It: Some programmers have formed partnerships in which the partner handles all the marketing. That may be a viable alternative if you don't mind splitting the earnings and have someone whose ability, dedication and integrity you trust. You might also be able to find an established wholesale or retail distributor to market your program, rather than using the normal shareware approach. If you do, you will probably find that the returns are very low. If a program is good, it will sell whether you sell it or a distributor does, but if an established distributor sells it, you may end up getting 10 cents on the dollar, or even less, and you may lose the rights to your program. PROGRAMMER'S GUIDE Chap. 1 CHAPTER 1: MARKETING SHAREWARE ------------------------------- GETTING PUBLICITY In 1982 and 1983, the relatively few shareware programs available were able to get exposure in the press simply because of their uniqueness. In 1984, there was a column on public domain ("pd") and shareware software in Softalk magazine, but the magazine folded at the end of 1984. After that, reviews of shareware in the computing press were scarce for a couple of years. The years 1987 and 1988 saw increased coverage of shareware in the press, but also saw an even larger increase in the total number of shareware programs available. (At the PSL, we screen over 400 programs a month.) Sending your programs directly to a magazine will probably do no good. PC Magazine and its ilk cannot possibly assimilate even a small fraction of those 400 programs a month. Even the few who get mentioned (in fact, even some who have been named Editor's Choice in comparative reviews in PC Magazine) report a short burst of activity that doesn't have that much impact in the long run. (Look back at 1982-1985 PC Magazines and see how many Editor's Choices are no longer around.) Sending press releases to non-computer magazines might get you more attention because the computer angle is more unique to them and their readers. For example, if you have a wonderful video tape cataloging program, send PR's about it to all the video magazines. SENDING OUT YOUR PROGRAM Rather than waste time and money sending your program to magazines where it will probably be ignored or at best, generate a short-term benefit, spend the time and money sending your disk to distributors and user groups and uploading to major BBS's, such as CompuServe. Make sure your program is stable for a while before doing all this, because you don't want to have to suffer the expense (and embarrassment) to send them all out again in a few weeks to fix a bug. You can often get a lot of good user feedback by distributing the early versions of your program to just a few places. After the feedback has resulted in an improved, bug-free, stable program, then start sending out to as many places as you can afford. You can get the names and addresses of user groups and numbers of bbs's from some magazines such as Computer Shopper. You can get names of distributors from ads and articles in magazines, but if you see an ad that pretends to be actually selling the software and doesn't explain what shareware is, you should give consideration to whether you want them misrepresenting your program to the public in that way. Update: The Association of Shareware Professionals now screens and licenses shareware distributors. Many ASP members restrict distribution of their programs to ASP approved vendors. After your first major, widespread release, you should probably aim for a major update about every six months to a year. Any more than that and people will get fed up with having to update their software. Any less than that, and some other program may out-feature you and steal your business. PROGRAMMER'S GUIDE Chap. 1 ADVERTISING In general, advertising shareware does not pay for itself in direct sales. Even the little low-cost classified ads in the backs of magazines generally do not pay off. And yes, that even includes ads in PSL NEWS! Such advertising is mainly good for increasing long-term public awareness of your product(s). Shareware programmers also report dismal results with those card decks which many people throw away without opening. Marshall Magee (Automenu) says: "I have done two card decks, PC Softdeck and another one. I don't think it was worth the money." The best form of advertising for your program should be the shareware version of it. If that won't sell your program, an ad surely won't. Spend your time and money getting your shareware disk out to users or to people who will distribute it to users. Shareware distributors can afford to advertise because it should generate repeat business for them that should pay off in the long run. Few shareware authors expect or get repeat business from the average customer. Let the distributors advertise your program for you by listing it in their ads and catalogs. Why should YOU pay for the advertising? Again - the best use of your time and money is getting your program out into people's hands by sending it to distributors and uploading to BBS's. A "PURE" SHAREWARE MARKETING STRATEGY Some programmers get so paranoid about stopping people from using their software without paying for it that they forget that these people are their distributors too. By cutting them off, you cut of your lines of distribution. Here is a "pure" shareware marketing strategy: Make your goal the first year to get as many people using your program as possible without worrying about who is paying and who isn't. That first year, you should either be working on polishing the program or on pushing the program all the time. If you can hit "critical mass", in terms of number of people really using your program, then the money should take care of itself. If your program becomes a clear standard then your leverage in getting people to pay becomes much greater. PROGRAMMER'S GUIDE Chap. 1 SHAREWARE VS RETAIL-ONLY SOFTWARE In general, a program that will not succeed as shareware will not make any money in the retail-only market either. In fact, it may lose money. Conversely, a program that sells well in one market would probably sell well in the other too. Games and niche products with a limited user base are difficult to sell in either market. Programs that can be used by businesses on a daily basis are the top money-makers in both markets. There are some differences, though, from both the user's and the programmer's points of view. As a programmer, you need to be aware of these difference so that you can plan around them. The User's Point of View: * TRY-BEFORE-BUYING: The theoretical advantage of shareware to users is being able to fully try a program before paying for it. However, this shareware advantage is starting to be negated by retailers who allow users to return retail software within a 30-day trial period. * RESPONSIVENESS: Shareware authors are generally more responsive in terms of making changes. An author of retail software who wishes to change his program may have to get back the old version from distributors and have new labels, brochures and documentation printed. A shareware author just puts out a new disk. On the other hand, authors of retail programs are usually available for telephone support, if you can get through to them, which may not be the case with shareware authors who have other jobs during the day. A major problem with shareware is that programmers move, but old versions of their programs continue to circulate with the old address. If possible, get a P.O. box and keep it after you move. I still get a couple of Diskcat registrations a week at a P.O. box that I haven't officially used for nearly three years. Another solution is to join ASP (discussed later) so that users can locate you through that organization. * COSTS: The argument used to be that shareware could be cheaper than retail software because you didn't have to pay for printed manuals that sit on the shelf and fancy packaging that gets thrown away. Ironically, today virtually all major shareware programs includes those trappings. It's felt that users have to feel that they are getting something for registering beyond fulfilling a theoretical legal obligation. Another alleged cost saving was eliminating the middle man - the distributor. Now many of the top shareware authors are selling through distributors too. These old, specious arguments ignored the fact that these "extra costs" also generated "extra income" that more than offset them for a successful product. In addition, Borland Software led the way in driving down retail software prices while registration fees for some shareware have increased dramatically. For example PC-File, which cost $25 in 1983 now costs about $90. Of course, at the same time, the functionality of PC-File has increased correspondingly, but the point remains that shareware is no longer just "cheapware". PROGRAMMER'S GUIDE Chap. 1 (Shareware vs. Retail, cont) * PROGRAM COMPLEXITY: Shareware programmers normally work alone while retail software companies can employ dozens of programs for large, complex projects. As a result, some types of shareware programs cannot match all the features of retail programs of the same type. For example, a graphics related shareware program may only support a couple of printers while a similar retail program may support dozens. * PROGRAM QUALITY: Many times, retail products contain serious bugs and there is little or nothing the user can do about it. The retail company may NEVER fix them. In 1985, we tried to produce a program for sale in the retail market using IBM's new $500 BASCOM 2.0 compiler which had so many bugs that our product, which we had finished on time to meet our advertising and other deadlines, would not run. IBM made numerous "unofficial" revisions (ie: we had to learn about them second hand), but never got all the serious bugs out. Evidently, they eventually gave up on it. We lost tens of thousands of dollars as a result. In contrast, if a shareware program has serious bugs, people just don't pay for it. In fact, some people probably use the existence of any bugs, no matter how insignificant, as an excuse not to pay. Therefore, shareware has to be in better shape than does retail software to succeed. The Author's Point of View: * COSTS: Advertising is horribly expensive. You can go broke quickly trying to break in a new program. The shareware approach offers a low- or no-cost alternative. Not only can you get into shareware marketing for virtually nothing, you can afford to take whatever time is required to establish your program since maintaining a presence in shareware can cost you nothing. Even so, if you want to have printed manuals and labels, to send out disks to user groups, to join and participate in the ASP, figure on spending at least a couple of thousand dollars, and be happy if you break even the first year. * TIMELINESS: A single magazine ad may make more potential users aware of your program in one month than shareware distribution will reach in a year or more, if ever. If you have a program that will be worthless a year from now and no follow-up versions are likely, you are almost certain to make nothing in shareware, and it will be difficult, at best, even in the retail market. The shareware authors who are now making over $1 million a year report that they got very few registrations for the first six months to a year. In shareware, patience is not just a virtue, it is essential. By the way, while a single ad may make a lot of people aware of your product, that doesn't mean that you will sell enough to break even on the cost of the ad. "Being aware" does not directly equal sales. PROGRAMMER'S GUIDE Chap. 1 (Shareware vs. Retail, cont) * COMPETITION: In 1984, we said that the retail market is more crowded and the competition fiercer. Now the reverse is true. There are more and more amateur programmers each year with better and better programming tools. Skyrocketing advertising costs force most of these people into the shareware market rather than the retail market. While improving on someone else's idea is a time-honored way to make money, people keep cranking out more and more of the same programs. When there are dozens of the same type of program available, it becomes more difficult for any one programmer to make money. Do yourself a favor and check on what is already available befor programming your brains out. The PSL's "PD & Shareware Reviews Disks" contains write-ups of thousands of programs, all arranged by subject matter. Look there before you leap. * IMPULSE SALES: The shareware author gets no money from impulse sales nor a user's mistake in buying a program that he doesn't need. Everybody with more than six pieces of retail software probably has one that he bought and has never used because his needs changed or he didn't like the program. The author doesn't care that much if you use the program or not - he has his money. DO USERS PAY? Commercial software houses' wildest claims wouldn't put the percent of people who haven't paid for their programs out of total users at over 50%, yet most shareware authors estimate that from 80% to 99% of people using their program have not paid. Are these estimates valid, or are they just sour grapes from people with bad programs? Nobody knows for sure. Certainly there a lot of people using software of all kinds, shareware AND retail, without paying for it. Retail software houses tried to get these people with copy protection, and it did not work. Shareware authors have tried crippling (limiting) their programs, and it has not worked either. In both cases, the crooked user is going to find a way to get his "free" software, so all the programmer has done is create ill will with the honest users. Here are traps programmers fall into which only serve to insure their failure: 1. Lack of patience. Remember that it usually takes six months to a year for a program to begin to reach a broad enough range of people to begin bringing in significant returns. During that time, if you want to succeed and really believe in your program, you have to keep pushing it and improving it just as if you were making a million dollars. PROGRAMMER'S GUIDE Chap 1 (Do Users Pay?, cont.) 2. Overestimating the program. Some programs are just not that good. It is easier for programmers to believe that ten thousand people are using their program and not paying for it than to believe that the program just isn't that good and to continue working to improve it. And a sad fact of life is that sometimes outstanding isn't good enough. Many authors have sent us press clippings saying how great their programs are and complaining that they have gotten few or no registrations. They blame shareware, ignoring the fact that many outstanding retail programs, highly acclaimed by the press, have also gone under. Homebase, now a shareware program owned by Brown Bag, was once a PC Magazine's "Editors Choice" as a retail-only program originally owned by Amber Software. 3. Overestimating the number of users. A commonly heard complaint is "200 people downloaded my program from CompuServe and I only got 2 registrations. I know more people than that are using it." Many people who download programs or buy disks from distributors do so out of curiosity or to get programs for their own bbs's or libraries. It takes TIME for these people to get your program out to the masses, and more time for the masses to use the program enough to want to pay. 4. Trying to sell trivial software. People are generally not going to pay for a trivial program, especially since there usually are a lot of free versions of the same thing around if a program is trivial. 5. Not working at marketing. It takes a lot of work to get your program out to people, to get it reviewed by magazines, user groups and shareware distributors, and to continue to improve it in response to users. Most people getting into shareware have no concept of having to market their programs. Marshall Magee, author of Automenu, has defied the odds by making big bucks selling a shareware program in a very crowded field - DOS menu programs. He does it by pushing his product to anyone who will listen. 6. Not continuing to improve. I have heard many programmers say that they were not going to invest any more time adding features or fixing bugs until they got some registrations. This brings certain failure. Most people originally write shareware for their own use or for the fun of programming. For the first year, your best bet is to not even think about registrations: continue to work on the program for your own use or enjoyment and don't worry about who might be using it. Remember, people who work at something just for the money seldom get pleasure out of what they are doing, and those work at something because they love the work usually find that the rewards come without worrying about them. PROGRAMMER'S GUIDE Chap 1 When programmers fail because of the preceding points, they usually start resorting to desperate measure such as the following: CRIPPLED DEMOS Crippled demos are what retail software houses sometimes provide potential customers. By disabling some critical function, such as the ability of a word processing program to save a file to disk, they allow the user to try out all the other functions of the program to see if they like it without taking the risk of sending out the complete program. You may wonder why shareware authors don't just send out crippled demos instead of fully functioning programs for which some users don't bother to send payment. The theory is that the more copies of your program being used, the more money you will get in the long run as your program becomes the standard. This is what happened with PC-Write and PC-File, both of which have reportedly made seven-figure earnings for their authors. But PC-File's Jim Button estimated in 1985 that fewer than one person in 20 using the program is paying for it. (We question the validity of that figure, which is surely pulled from a hat, but that's beside the point.) You would have to be an iron man to stoically accept the fact that, no matter how much money you've received which you might not have otherwise gotten, there are thousands of people around who are using your program without paying. So some shareware authors try the crippling technique. The most common tactic is to omit parts of the documentation that explain more advanced program features. When the user makes payment, he gets a printed man- ual with the missing sections which may not be copied for others. This tactic will only work for programs with large amounts of documentation and with advanced features. Other authors offer less powerful versions of a program as shareware that may be freely copied and more powerful versions that may not be legally copied. Remember that while these tactics may ensure a higher ratio of paid users, they also cut down on the number of total users. Since you are relying on word-of-mouth instead of paid advertising, you may get fewer "cheaters" but you may also actually get fewer paid users. Another reason that people don't pay may be because of shareware distributors who mislead the people into thinking they are buying the software when they pay the distributor's disk fees. PROGRAMMER'S GUIDE Chap 1 PD/SHAREWARE DISTRIBUTORS: In the beginning, the idea of shareware was that users would give copies to each other and user groups would give free copies to members. Everything was done for free. However, as libraries and user groups grew, librarians started charging fees to cover their expenses. Many libraries have over 1,000 disks and many groups have hundreds of members to make copies for. Also, today's groups are filled with novices who must be assisted in learning to use the public domain and shareware software and the library must be better organized to avoid confusing or overwhelming these novices. Ideally, programs in a library must be tested for functionality, bugs and viruses; they must be organized by topic; and they must be kept up to date. Gathering the people with the expertise to do all this is costly and time consuming and has long since been beyond the capacity of user groups to keep up with. In addition, a substantial number of people do not have access to user groups anyway, so the job of distributing shareware has passed more to the full-time, professional shareware distributors. Unfortunately, there are distributors who are just looking for a quick buck and who do little or none of the work normally involved in testing, organizing and keeping things up to date. These same quick-buckers usually misrepresent to the public that they are selling the programs without explaining what shareware is. For example, look at some of the shareware ads in PC or other magazines and see if the nature of shareware is being explained. The Association of Shareware Professionals has passed Vendor Requirements whereby distributors can be approved by ASP. Under these requirements, vendors would have to explain shareware in their ads that quote a price. I strongly recommend that you state in your documentation that anyone charging any kind of fee for providing copies of your program must have your written authorization unless they are recognized by the ASP. On the following page is a form that is used for Diskcat. The control number on the form lets you track where registrations are coming from. This can be very important as you may have dozens or even hundreds of bbs's, disk distributors or user groups distributing your program and if you know who is generating the most registrations, you know to whom it is worth sending updates. DISKCAT DISTRIBUTION LICENSING AGREEMENT Anyone wishing to charge people a fee for giving them a copy of Disk- cat must have the written authorization of the author, without which, the distributor is guilty of copyright violation. To receive such authorization, send this completed application, along with a copy of your software library's order form to: Nelson Ford, P.O.Box 35705, Houston, TX 77235. Include $7 to cover the cost of processing the application and of sending you the latest version of Diskcat. For distributors already recognized by the Association of Shareware Pro- fessionals, this application is not necessary. Name of Organization: ____________________________________ Your Name: _______________________________________________ Address: _______________________________________________ _______________________________________________ TERMS OF DISTRIBUTION OF DISKCAT: 1. The fee charged may not exceed $7, including postage, mailer and any other charges. 2. Your library's catalog or listing must state that this program is not free, but is copyrighted software that is provided to allow the user to evaluate it before paying. 3. The offering and sale of Diskcat will be stopped at any time the author so requests. 4. Copies must be made from the copy of Diskcat sent to you with this agreement. This is required for control purposes. 5. Problems or complaints will be reported to the author for resolution. In return for the right to charge a fee for the distribution of the program Diskcat, I agree to comply with the above terms of distribution. Signed, ______________________________________ ______________ your signature date __________________________ _________ ______________ Nelson Ford control # date PROGRAMMER'S GUIDE Chap 1 OTHER PROTECTIVE MEASURES Make use of trademark and copyright protection. Even if you don't actually register them, the symbols and notices may protect your future rights. Your copyright notice should look something like this: DISKCAT COPYR. 1983,1984,1988 NELSON FORD ALL RIGHTS RESERVED The (C) is generally not acceptable (the C must be enclosed in a full circle), so spell out copyright or abbreviate it COPYR. If you have revisions spanning multiple years, list them all. The complete notice should be on one line. Patenting Software - Attorney Jon Wallace tells us: Re patenting a program - it is possible, but extremely time consuming and costly. The program must be novel and non-obvious (terms of art) and cannot merely solve an algorithm or incorporate a law of nature. The process can take two years and cost thousands of dollars. Is it worth it? Well, if Software Arts had patented VisiCalc, Lotus 1-2-3 would never have made it to market. Trademarks: Generally, if you start distributing your program without a (TM) notice by the name, you lose the trademark protection. So spend the extra four keystrokes and put it on. Marshall Magee advises: The trademark office requires that you send them copies of artwork currently being used to market your product with the TM indicated next to your word or phrase. The patent & trademark office will then issue you a paper telling you that your word or phrase is now a Registered Trademark and then you have the right to use the circled R in place of TM. CompuServe has a service called IQuest that will allow you to scan the Trademark Data Base for less than $15. This is a cheap way to check on whether or not someone else has already registered your words. If you send in a name that is already registered, you will lose the $175 fee, but that is still cheaper than paying a lawyer to do a search. Warranties: You should also put a disclaimer of warranty in your documentation. Place it at the front of the documentation where the reader cannot miss it. The following is a sample disclaimer that you can use: DISCLAIMER OF WARRANTY THIS SOFTWARE AND MANUAL ARE SOLD "AS IS" AND WITHOUT WARRANTIES AS TO PERFORMANCE OF MERCHANTABILITY OR ANY OTHER WARRANTIES WHETHER EXPRESSED OR IMPLIED. BECAUSE OF THE VARIOUS HARDWARE AND SOFTWARE ENVIRONMENTS INTO WHICH THIS PROGRAM MAY BE PUT, NO WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE IS OFFERED. GOOD DATA PROCESSING PROCEDURE DICTATES THAT ANY PROGRAM BE THOROUGHLY TESTED WITH NON-CRITICAL DATA BEFORE RELYING ON IT. THE USER MUST ASSUME THE ENTIRE RISK OF USING THE PROGRAM. ANY LIABILITY OF THE SELLER WILL BE LIMITED EXCLUSIVELY TO PRODUCT REPLACEMENT OR REFUND OF PURCHASE PRICE. All of the above legal information about copyrights, trademarks and warranties is based on careful research, but is presented by one with no legal training. It is presented to give you an idea of the types of protection available to you. Talk to a lawyer or get a book on the subject for more detailed, more accurate and up-to-date information. PROGRAMMER'S GUIDE Chap 1 SELLING REGISTERED VERSIONS THROUGH SHAREWARE DISTRIBUTORS: Several shareware distributors have begun selling "registered versions" of shareware programs. Practices for doing so vary widely. Some may have you send them packages to sell on consignment, some may buy packages from you just like a regular dealer, others may sell the program but have you ship it. The percentage that the distributor gets also varies widely, from less than 10% to as high as 60%. Before signing with a distributor who will keep 60%, keep in mind that if you allow such a distributor to sell your program, for you just to break even, he must generate more than two-and-a-half times more registrations from people who would not have registered otherwise. If out of 25 registrations, 10 of those people would have registered with you directly anyway, you barely break even. If half of the 25 would have registered with you anyway, you have lost money to the distributor. We think more and more distributors will take to selling registered versions and in general, this will be beneficial to shareware. Obviously, if a vendor is offering PC-File for sale for $89, he can hardly mislead the customer into believing that a $2-$6 disk fee is the cost of "purchasing" the program. The main drawback is that you must be careful in selecting those you let sell your program. If they rip someone off, you may have to pay. And you may also have to cope with rip-off artists who claim to be selling your program, but who give you none of the money. SELLING REGISTERED VERSIONS THROUGH "RETAIL" DISTRIBUTORS/DEALERS: Some of the top shareware authors also sell their programs through normal retail channels. While there is nothing wrong with this from the shareware viewpoint, dealers and distributors often complain when they see "the same program" being listed in a shareware distributor's ad for a few bucks. Hopefully, in the long run, increased public awareness about the true nature of shareware and more truth in advertising by shareware distributors (both of which are major goals of ASP) will stop this from being such a problem. In fact, as more shareware distributors begin to sell both retail and registered shareware products, the distinction between the two may disappear, other than the advantage to users of being able to try shareware before buying. PROGRAMMER'S GUIDE Chap 1 SETTING PRICES: Costs were discussed a few pages back under "Shareware vs Retail Software", but now let's look at the problem of setting a price for your program. Truism #1: If somone doesn't need a program, the fact that you may have grossly underpriced it is not going to induce them to register. Truism #2: Users don't care if you "really need the money" or if you spent 10,000 hours on the program. They care about THEIR needs and the costs and alternatives for filling those needs. The two keys to pricing a program are the cost of alternatives and the value to the user. Check Out the Competition: To do a sensible job of setting a price for your product, you need to know the shareware and retail markets for your product. Find out what other programs are selling for and compare your program to them in terms of quality and features. For retail products, don't look at list prices, look at mail-order discount ads. That is your main competition. For shareware products, the easiest way to compare is to look in the PSL's PD/Shareware Reviews. The license (or "registration") fees shown there include shipping and handling, in order to make comparisons valid. Don't forget to check both the Small Programs Reviews disk and the Large Program Reviews disks. If you have written a simple program and you see other programs like it that are free or $10 or less, that does not bode well for the odds of your getting rich from your version. Even if you don't find any competition, if your program was easy to write and you overprice it, you can bet that others will write "improved" versions of your program and ask little or nothing for it. For example, one month we saw a program that was somewhat unique, but was clearly trivial to program, had a relatively high shareware fee, and on top of everything else, had very retrictive policies about who could copy it, plus the program was poorly designed. In a few hours, we wrote a version that we think was much better designed and had a much lower shareware fee. "Alternatives" are not always other programs. If you had the world's only program for keeping track of, say, telephone messages, you still could not charge hundreds of dollars for it because people still have non-computing alternatives -- writing the messages down on paper. Value -- and Pricing Flexibility: For a program to be a huge success, it must have a large target audience, it must have a value far in excess of its cost, and it must be appear to be better and/or cheaper than alternatives. If the use of alternatives is already deeply engrained in people's habits, then the program must be greatly superior to alternatives (not just cheaper) to get people to switch and to learn a new system. In effect, your target audience is made smaller when your program's niche is already dominated by a highly successful program. Sometimes a programmer will price a program very low because he thinks that will get more people to pay for it. This strategy is fine if it is based on a comparison of the program to alternatives, but it usually is based soley upon desperation and/or lack of confidence. PROGRAMMER'S GUIDE Chap 1 (Pricing... continued) This strategy of trying to low-price a program is most often employed with low-value programs or programs with small target audiences. It does NOT work. Large numbers of people are simply not going to pay for low value programs, no matter what the price. Likewise, pricing has virtually no effect on the size of your target audience. If you have a high value program, but a small target audience, you should keep your price up (still giving consideration to the cost of alternatives) and use the extra revenues to try to increase the size of your target audience (ie: get out and PUSH your program) or to to develop other programs. Charge for Value to the User, Not for Your Time: If you are fairly new to programming and it took you weeks or months to perfect your program, keep in mind that an experienced programmer might duplicate your effort in a day. Don't price your product based on the number of hours you spent, but on the value of the program to the user. Case Studies: BASIC compilers used to sell for hundreds of dollars. When Microsoft introduced QuickBASIC ("QB"), it had a street price of under $60, although its value ot the customer was clearly very high and it had a large target audience. The reason why was competition for Borland Software who was releasing Turbo BASIC about the same time and at about the same price. A company named MicroHelp sells add-on's for QB, usually at prices much higher than QB itself. Even though the time and money invested in these add-on's is undoubtedly many times less than in QB, and though the relative value of the add-on's is probably far less than QB itself, MicroHelp still enjoys very good success and, in our opinion, would have no more success if it lowered its prices. The reason why is because of two key elements: (1) the relative value of the add-on's compared to QB notwithstanding, the value of the add-on's to the user is still many times the price of the programs and (2) for most of these add-on's, there are no alternatives that are significantly cheaper. Rabinowitz's SWAP Programs: In the shareware arena, Chip Rabinowitz has cleaned up with some add-on's for many popular pop-up programs (such as Sidekick) that reduce the DOS RAM used by these programs to about 9k. Again, the price of these add-on's is much higher than the value of and time/money invested in the original programs, but that fact notwithstanding, the value of the SWAP programs is many times their price and the alternative (of not using the SWAP programs and continuing to waste precious DOS RAM) is not an attractive one. PROGRAMMER'S GUIDE Chap 2 CHAPTER 2: MAKING YOUR PROGRAM USER-FRIENDLY --------------------------------------------- ON-SCREEN HELP The first thing most people will do when they get your program disk will not be to print out and study the documentation; it will be to try to run the program. So your program should have enough on-screen help to allow the user to run the program at least well enough to get interested in it. One popular data base program has one place where instead of a self-explanatory menu, it shows a series of cryptic symbols and letters from which the user is supposed to select. Chances are, the occasional user will have to refer to the manual every time this part of the program is reached. (Since 1984 when this was written, the data base program has been improved.) The most desirable alternative is to have the program work in a natural enough manner and have enough information on the screen to allow the user to operate the program with no further help. The second best alternative is to have help screens that can be called up with a keystroke. The third best alternative is to have a well-written manual. The worst alternative is to have users calling you all hours of the day and night or even have them give up on your program. Supply defaults. If the user has supplied the name of a file to load, make that name the default when you ask him for a name to save with. While on the subject of files, if you ask for a filename, be prepared to let the user see the disk directory. Some programs make the user exit the program and look at the directory in DOS if he cannot remember the filename. A nice checkbook program in the PSL lets you put a vendor's name and address on a check by entering the vendor's ID#, but it doesn't let you view a list of vendor ID numbers! Trap errors. Nobody wants to have ten minutes of keyboard input dumped into the bit bucket because the program kicked out to DOS when it found a disk drive door open, or some other minor infraction. One very fine shareware program has scared off potential users because it gives nothing more than error code numbers for simple things like having a write-protect tab on a disk. In this case, the author would have been better off not trapping errors. The program would have aborted, but at at least DOS would have spelled out the error messages. RULES FOR BASIC PROGRAMMERS Here are two cardinal rules for BASIC programmers: 1. Compile your program. There are many, many users who have never run anything but 1-2-3 or Wordstar. They do not understand the intricacies of getting in and out of the BASIC interpreter. They expect to be able to run the program by typing in its name from DOS. Furthermore, your program will run faster. Also, some PC-compatibles do not come with a BASIC interpreter. On these, the user cannot run your program at all! (eg: DG/1, Tava) (Note: this is even more true now than when this was written in 1984.) 2. Avoid using the INPUT command. It allows the user to wipe out the screen and provides very little control to the programmer. Instead, use an INKEY$ routine. Almost all BASIC programmers are now following these rules, but they still bear repeating. Not a cardinal rule but still a very good idea for BASIC programmers is to use assembler subroutines for doing screen writes. Users are accustomed to instantaneous screen writes in professional programs. An alternative is to use the paging capabilities of the graphics card but then users with monochrome monitors must still wait. PROGRAMMER'S GUIDE Chap 2 MAKE THE PROGRAM AND KEYS WORK NATURALLY All programmers should allow full-screen editing. This simply means that the user can move back to a prior prompt with the cursor keys to correct an error. Thoughtless (or lazy) programmers make the user go all the way through a series of prompts and then asks if there are any corrections. The best time to correct an error is as soon as you notice it. That way, you can get your mind off the error and back on your work. Similarly, the Esc key should always allow the user to get out of whatever he has gotten into. Nobody likes to re-boot his computer just because he accidentally selected a wrong option and can't get out of it. I have seen retail programs that use the Esc key to execute a command. How perverted! Make the program as flexible as possible. What may seem to you like a natural, logical key to strike for a particular function may not seem so to the user. That's why keyboard modification utilities are so popular. For example, to page up, you could let the user press either Ctrl-P or PgUp or, better yet, select his own favorite key to use for that function. LET THE USER CUSTOMIZE Send your program out with black and white screens but allow the user to change colors. Some programmers use colors that are only visible on color monitors. Remember that some people use amber or green monitors on color graphics cards. Early versions of Diskcat tested for the presence of the color graphics card and, upon finding it, started using yellow (brown) for text. Of course, it did not show up on amber monitors. Allow the user to customize the program for his printer. Ideally, you should have the control codes for most printers in files on disk so that the user just selects his printer from a menu. An easier (for the programmer) alternative is to allow the user to enter the control codes for his printer, although figuring these out from the printer manual often seems to be beyond the capabilities of novices. When your program does printouts, allow pauses for each new page for people not using fanfold paper. (This is not quite as critical anymore. Most people now use fanfold paper on dot matrix printers or use lasers with paper trays.) End each printout with a formfeed so that those who do use fanfold paper can chain printouts into a print buffer. Make sound effects optional. Some heavily modified versions of PC-TALK sound like a calliope, there are so many warning beeps and tones built in. These are not appreciated by others when you are working in an open office or late into the night at home. Again, some PC-compatibles do not support sound (eg: Sanyo). PUT THINGS BACK WHERE YOU FOUND THEM One very useful utility in our library uses colors that do not show up on some monitors. Worse yet, it does not put back your colors when it exits to DOS, so you have to reboot the system to be able to see the screen again. Some other programs put you back in DOS with a 40-character display or in the graphics mode or with your printer set to print Sanskrit. PROGRAMMER'S GUIDE Chap 3 CHAPTER 3: WRITING THE DOCUMENTATION ------------------------------------- Keeping Your Files Together: If your files will not fill up a disk by themselves, they will probably be put on disks with other files. Even if you don't expect this to happen, it is still a good idea to give your files names that will cause them to be grouped togeth- er when a sorted directory is done and that make it clear which files are in a set. If you have files named READ.ME or AUTOEXEC.BAT, they probably will not survive being put on a disk with another program. Give them unique names. For example, the PC-DIAL files are named PC-DIAL.COM, PC-DIAL.DOC, and PC-DIAL.PRO. Since the files total only 90k and are likely to be combined on a disk with other files, these names will keep the files together. In contrast, see the names of a set of programs below: Original Names Alternatives -------------- ------------ MDSECRET.COM HIDE_MD.COM CDSECRET.COM HIDE_CD.COM RDSECRET.COM HIDE_RD.COM HIDDEN.DOC HIDE.DOC You should also put a lot of thought into the filename of your program if it is a short utility that will be mixed in with others. For instance, the average user is never going to make the connection that GREP is a text-search utility. A name such as FINDTEXT.EXE would have been better. One nice utility came out with three files: DOWNLOAD.DOC, DL.COM and RESET.COM. What typically happens is that these are put on a disk with 60 other files. Someone looks at RESET.COM, can't find any documentation for it, so they delete it. Same thing happens with DL.COM. The other problem is that someone skims through a listing of the disk, sees the name DOWNLOAD, and assumes that it has something to do with communications and ignores it. Doesn't matter, since the COM files have been deleted anyway. How much easier things would have been if the files had been named BKUP.DOC, BKUP.COM (this is a routine to backup a hard disk) and BKUP-SET.COM (sets the archive bit on a file so that it will be copied.) Number Each Release: Believe it or not, some people send out frequent updates to their programs and never put a date or release number on them. That makes it nearly impossible for you to control what versions of your program are in distribution and for users to know if you have released a new version. PROGRAMMER'S GUIDE Chap 3 Multiple Documentation Files: As mentioned earlier, if you have a large documentation file, don't expect the user to print and read it right away. If there are some key points that the user will need to know to get through a first trial run, condense them into a shorter file and have a batch file print it out for novices. Your terms of distribution and payment should also be in a separate, short file where software librarians and users can find them. Authors who bury their terms of distribution and invoice at the back of a 100k documentation file are just asking to have them ignored. ASP recommends putting vendor info in VENDOR.DOC. Formatting and Printing The Documentation: It is amazing how many authors put the documentation file on the disk with all of their word processor's formatting commands embedded in it. If the user can't read the documentation, you've already got one strike against you. Some people use file compression on the documentation file and the user must run a program to translate the file. Putting the documentation in a format that cannot easily be read from DOS is not a good idea because it reduces the odds that the user will thoroughly read the documentation But if you must compress it, it is even more important to condense the key facts into a shorter file. Even if the documentation is in straight ASCII, it is helpful if you add a pro- gram to print it out to the screen or printer. This makes it easier for novices to get a printout while the file being in ASCII still allows experienced users to access the documentation in other ways. The program should allow for pausing after every page to change paper, if the user needs to do so. Use a spelling checker. We have talked about how a professional-looking program will generate more revenues, and nothing looks more unprofessional than blatant misspellings. Contents of the Documentation File: Right after your title page, disclaimer of warranty, and table of contents, there should be a listing of all files that are supposed to be on the disk, along with a short description of each. If a file has dropped out in the distribution process, this will alert the user and save him some frustration. This information should also be included in your condensed documentation file. After you've recited all the dry facts in your documentation, try giving the user some illustrative examples. This can make things a lot clearer to the user and save you the headache of having to clarify things over the phone. List all the changes made with each version that's released. This lets poten- tial users see that you are supporting the program by making enhancements and fixing bugs and allows users to know if you have fixed problems that they had with an earlier version. Make sure that when you refer to a file, the file name on the disk has not changed. PROGRAMMER'S GUIDE Chap 4 The Association of Shareware Professionals ("ASP") The ASP was formed as an outgrowth of a Shareware Convention held in Houston, Texas in February 1987. Although I put together the Shareware Convention with the express goal of it leading to a programmers association and that dream did indeed become a reality, the people who deserve the credit for the success of ASP are the top shareware programmers such as Jim Button (PC-File), Bob Wallace (PC-Write), Marshall Magee (Automenu) and Tom Smith (Procomm). These people could have adopted the attitude that they were already successful enough without such an organization, but they did not. They paid their own way to the Convention even though they were the featured speakers! Button was elected the ASP's first (and second) Chairman of the Board of Directors. Magee became the first President. Tom Smith served as a director. And none of these are "honorary" positions; they involve a great deal of time and effort. Many others, such as Barry Simon, Bob Tolz, Joan Friedman, and others too numerous to mention have also done a tremendous amount of work for ASP as directors, officers, committee members, and just active members, but I suspect that had the top shareware programmers not taken such an active role, ASP would not have had much credibility and possibly would not still be around. ASP also owes thanks to the sysops of IBMNET on CompuServe. Sysop Conrad Kageyama was at the Convention and arranged, on the spot, a place on IBMNET for the shareware authors to meet electronically and continue our plans. We have been meeting there daily ever since in what must be a record for longest continuous business meeting. ASP also has an annual physical meeting at the Fall Comdex each year, thanks largely to the efforts of Marshall Magee. Goals of ASP (as extracted from the Bylaws): ASP, the Association of Shareware Professionals, was formed in April 1987 to strengthen the future of shareware (user supported software) as an alternative to commercial software. Its members, all of whom are programmers who subscribe to a code of ethics, are committed to the concept of shareware as a method of marketing. ASP's primary goals are: o To inform users about shareware programs and about shareware as a method of distributing and marketing software; o To encourage broader distribution of shareware through user groups and disk dealers who agree to identify and explain the nature of shareware; o To assist members in marketing their software; o To provide a forum through which ASP members may communicate, share ideas, and learn from each other; and o To foster a high degree of professionalism among shareware authors by setting programming, marketing and support standards for ASP members to follow. PROGRAMMER'S GUIDE Chap. 4 Membership Criteria: Regular membership is presently limited to authors of non-trivial programs which meet the ASP's definition of shareware. Implicit in that definition is that "shareware versions" should not be crippled nor artificially limited in features nor in number of uses or time-period of usage. Membership or associate membership may also be offered by ASP to people who have found other ways to make significant contributions to shareware. A membership application form is included on this disk as APPLIC.FRM. The Bylaws of ASP are included on this disk in the file BYLAWS.ASP. Vendor Standards: ASP has established standards for shareware distributors to follow if they want to be able to advertise that they are recognized by the ASP. Basically, the standards require vendors to be up-front about what shareware is and to honor any copying restrictions of authors whose programs they choose to distribute. Meetings on IBMNET: While the formation of ASP and the forumlation of its policies have gone far more slowly than anyone could have imagined, that is due largely to the fact that business is done primarily by electronic meetings. Discussions that might take an hour in a physical meeting may take days or even weeks in an electronic exchange. Also, unlike virtually any other organization in existence, many members get involved with the policy making of ASP on a daily basis on IBMNET. In addition to taking care of ASP business on IBMNET, members frequently exchange ideas, ask each other for advice, and generally share resources on the forum. And after nearly two years, the ASP is now on the verge of announcing new policies that should dramatically increase public awareness of ASP and member's programs. PROGRAMMER'S GUIDE Chap. 5 CHAPTER 5: WHERE TO GET SUPPLIES AND SERVICES NOTE: The information in this chapter is subject to change at any time. Check the date on this file. If it is old, this info may no longer be valid; get a new copy of this disk from PsL (1-713-524-6394). Telephone: AT&T has a low cost 800-line service called the Ready Line which is relatively inexpensive. For about 25 cents a minute out of state, about 35 cents a minute in state (for Texas), you can have a fancy 800 number just like the big boys. Most of the good acronyms are already gone, but you should still be able to come up with something. At the PSL, our number is 1-800-2424-PSL, which we think is easy to remember. However, we were not able to get anything like 800-PSL-DISK, which would have been better. Another shareware distributor had the number 800-IBM-DISK, but IBM clamped down on them for trademark infringement. The Ready Line 800 number is assigned to your regular telephone number, so you do not even have to get a second line, unless you just want to be able to know for sure if someone has dialed the 800 number. ASP member John Newlin reports: I purchased a product called the Complete Answering Machine ("CAM") after reading about it in the July issue of Home Office Computing. It's an outstanding system that includes a plug-in card and all the necessary software. It runs in the background so the machine it's running on is not completely dedicated. The system allows you to do all kinds of nifty telephone things like transferring calls, having the caller touch different numbers to get different messages, message forwarding, remote message retrieval, etc. All messages, greetings, etc, are stored on disk in compressed digitized form. For that reason, a hard disk is almost a necessity. The quality of the recording is phenomenal. CAM retails for $349, but I got it from 47th Street (800-221-7774) in New York for $214 plus shipping. The name of the manufacturer is The Complete PC; 521 Milpitas Drive, Milpitas, CA 95035. 415-434-0145. Answering Services can be expensive. If you cannot be available during the day, your best bet is probably to get a computer voice synthesizing answering device such as Newlin described. Many large companies are now using these to route calls, so there should be less of a small-timer stigma attached to them as there is to a simple answering machine. Fax Machines: All the experts are predicting that everyone will have a fax in a few years, but it seems a little premature for someone just starting off in shareware to get one right now. At PsL, we have been using the Intel Connection Coprocessor. A FAX card with its own CPU will let you receive and send messages in the background while you continue to use the computer for other things. PROGRAMMER'S GUIDE Chap. 5 Disk Labels: PsL sells sheets of laser labels. With font programs, you can make small quantities of labels at a low cost that look like they were custom printed. Avery Label Pro is the best laser label program, in my opinion. The Computer Label Company, 1-800-332-4223 (Ca: 1-800-331-4223) and MEI have the best prices we can find on standard 3.5" by 1" labels. PsL's sleeves were printed by Data Envelope (408/374-9720) at an average cost of about 5 cents each for two-color printing on both sides of tyvek sleeves, including a one-time charge for plates. This was based on a volume of 50k, but even in volumes of 1000, you can get two-color sleeves for as little at 10 cents each. The same company printed our labels, which you can get for as little as one cent each. Art work - If you can get someone to design a logo you like for as little as $500, you have gotten a bargain. Don't be surprised to pay $1000 or more. Your best bet is to find someone who works for a design agency and moonlights. Blank Disks: Flip through the pages of Computer Shopper and take your pick. It makes sense to us that if you are sending a copy to someone who should make a working copy from your disk and not use your disk much, the cheapest disk you can find should suffice, particularly if you are sending out a couple of hundred disks to distributors. Be aware that some colored disks (red or orange, in particular) may not be readable on some disk drives. Disk Duplication: In our opinion, disk duplication services are grossly over-priced. However, others use these services and are happy with them. If you are pushing out 1,000 or more disks a month, you might want to get a duplicator. You can get a stand-alone, four-disk copier for around $1100 these days, which is a real bargain; we have paid $2000 for copiers that require a PC. (Call Micro-Technology Concepts, Inc., 718-456-9100. Tell them Nelson Ford, PsL, sent you.) There are many public domain and shareware programs designed to make disk copying and formatting faster. Before spending even $1100 on a duplicator, try some of these programs. In the PSL, we have many of them on disk 1-UT-1553, Disk Copying Utilities. Diskette Mailers: A good source of plain, inexpensive, flat diskette mailers for one or two disks is MailSafe (800-527-0754). Mailers are less than $.14 in quantities of 1000. If you opt for a return address printed on it, it doubles the price, but looks pretty cheap. Instead, either print your return address labels or try the next company: If you want fancy mailers like the ones the PSL uses, try the Ames Safety Envelope Company, 312-279-9474, 188 Industrial Drive, Suite 431. Ask for Gary Traynor. You do have to order quite a few, however. For 5,000, the price should be about $.65 each. For 10,000, about $.45 each. PROGRAMMER'S GUIDE Chap. 5 Boxes: If you are mailing manuals, you will need boxes. PsL gets boxes from Fidelity (800-328-3034) and Iroquois (800-453-3355). Call and ask for a catalog. We also get some boxes from local box stores, although they cost a bit more per box. The companies mentioned also sell general office supplies cheaply. MC/Visa Merchant Accounts: In December 1989, after the bank our credit card merchant account was in failed, we called many banks across the country that would not consider any business that is primarily mail-order, despite the fact that PsL has a five-year, unblemished credit card history and a sound financial position. Tens of thousands of other small businesses are in the same fix, or even worse: they may have no credit card history and/or may be working out of their homes. After we finally acquired an account with a local bank, we received a call from Sharon McManus, of State Retail Service, in South Carolina. Our previous agent had referred our account to SRS, and Sharon was still working on getting PsL into another bank. (Nobody had informed us of this, unfortunately.) Even though we explained to her that it was too late, she spent a long time discussing the MC/Visa Merchant account situation for small businesses. SRS has an alternative to doing without. Before considering this, you should try ALL the major banks in your town. Smaller banks most likely process through the major banks, so you can probably write the smaller ones off if the major ones have a firm no-mailorder policy. We found that banks in Chicago, Indiana, and some other areas were more willing to talk than those in Houston, but they only want to talk to local businesses. If no local banks will take you, and you have no credit card history and/or you work out of your home, Call Sharon at 803-862-1409. Her company is affiliated with another company named Card Authorization Network. Working through CAN, which assumes 100% of the liability of your account to protect the processor, you can get MC/Visa processing capabilities, but at a higher rate than usual (7.48% on an average ticket of $50, for example). After six months with CAN, according to Sharon, you would have an established Merchant Account record that would allow your account to be converted into a Merchant Account with a regular bank. Also according to Sharon, you would receive cash for your charge tickets within 72 hours of taking the charge. You should be aware that a lot of unscrupulous businesses are taking advantage of merchants who are desperate for MC/Visa Merchant accounts. We have heard many complaints about some third-party services such as Sharon described. Our impression, based on our lengthy conversation with Sharon, is that her service is on the up-and-up. But we have no way of actually vouching for her. You will need to talk to her and make your own decision. We were not able to locate a phone number for AmCor, one of the largest merchant services in the country. Trans-Mark is another large service, but they do not want to deal with businesses that fall below the multi-million dollar level. In fact, Trans-Mark was the only company that was downright snotty with us; most were sympathetic, but still unwilling to talk. Another large company that we could not reach is BancCard, in Colorado. About 70% of PsL's business is on MC/Visa/Amex. A credit card account is obviously very important to a mail-order business. If you are determined enough, there is still a chance you can get one, even if you are small, work-at-home business, but you should be ready to commit to following every lead for however long it takes. American Express & Discover: While MC/Visa are the big guns, American Express was willing to give us an account when we were still operating out of our home. At the time, Discover was not willing to do the same. However, we have recently (5/9/90) been told that Discover has recently set up a branch for mail-order businesses. We do not know at this time if this includes in-the-home businesses. Printers: My number one choice for a printer would be a PostScript printer with HP and Epson emulation. The IBM is a good choice. NEC has gotten mixed reviews. The PostScript translation software that lets you print PS on most printers are VERY slow and imperfect in their translations. If you absolutely cannot afford $2500-$3000 for a PostScript printer, my next choice would be an HP LaserJet, purchased from a discount house. Other brands may promise more features, compatibility, etc, but as one who has purchased two non-HPLJ, our discovery is that clones might not be 100% compatible, and with the HPLJ discounted to about the same price, why risk it. HPLJ is *the* standard for non-PostScript laser printers, so anything new to come out for lasers is sure to work on the HPLJ, maybe not on "compatibles." If you really cannot afford an HPLJ, my next choice would be the HP DeskJet, an ink-jet printer with laser printer quality. The only drawback is that the ink smears if you get it wet. HP is said to have this problem about solved. If you need to do mailing labels and using laser labels in an HPLJ won't work for you, resist the urge to get the "industry standard" Epson. We got Epson's and the fact that the labels can only be fed in from the back causes endless problems. As the labels curl around the platen, they tend to come off in the machine, catch on the print head, etc. The owner of the Computer Label Company advised us to get a bottom-feed printer, such as an Okidata. We did so and have had no more problems. PROGRAMMER'S GUIDE Chap. 5 Manuals: If you are just starting, consider just having a manual on disk until the number of registrations is enough to convince you that you could use a thousand manuals in a year or so. A cheap looking, poorly done manual is worse than no manual at all. If you have a small manual (less than 100 pages), you should be able to get 1000 copies for about $1000. Check your local printers, but also check with Whitehall Press, who did PsL's Source Book. Their number is 312-541-9290. Many shareware authors have used and recommend them. We checked several printers for our book, and ended up with Whitehall anyway. For my Diskcat-5 manual several years ago, I just used a local printer to print a first run of 500 copies with a glossy, two-color cover. I also paid an artist about $1200 to do the art and color separations for the cover, the labels and ads. Don't worry too much about your manual being rendered obsolete by program updates (short of major rewrites). Even big publishing houses have adopted the technique of putting the latest info in a READ-ME file on the disk. Shrink-Wrap Machines: Almost everyone in the ASP who has a shrink-wrap machine has the AJM machine and is happy with it, including me. The system consists of a 16" sealer unit, an industrial 14-amp heat gun, and a 10" by 2000' by 75-G roll of film. APPENDICES PROGRAMMER'S GUIDE App. A David M. Berdan, author of File Express, offers the following advice: Be consistent. Keep the same style throughout your entire program. A user should be able to use the same commands and choices in all parts of a program for things like returning to previous menus and choosing similar options in different sections. Thoroughly test and debug your product. Typically, it takes about 20 - 30 percent of your time to actually write the code fo a program and the remaining 70 - 80 percent to refine, enhance and debug. Nothing is more disconcerting to the user than to crash out of a program in the middle of something important. Write thorough, complete, understandable documentation for the product. The manual should answer almost all the questions the user might have before he even asks them. Poor documentation can ruin an other wise excellent product. Edward H. Kidera, author of PC-KEY-DRAW, writes: The response has generally been poor, although I do get a lot of phone calls from unregistered users. I am just about ready to release a version with many more features, but I am in a dilemma: how should I release the new version? In analyzing the situation I have come up with the following break down (in no particular order) of possible reasons for insufficient interest: 1. Not enough time has elapsed. 2. The price is too high. 3. The price is too low. 4. The program is too hard to use. 5. The documentation is not sufficient. 6. People aren't honest. 7. The shareware approach is flawed in concept. 8. There are superior programs readily available. To begin with, I firmly believe that the shareware concept is a good one. It provides tremendous benefits to the user by allowing him to try first and by providing low-cost software. Secondly, I am convinced that people are honest. What then is the problem? In preparing the next version, I have held two convictions: that the program should be easier to use and that the documenta- tion should be expanded. The impact of these improvements cannot be assessed until after the release of the new version, so I don't know yet how much this will help. Price: $45 may be more than the home user wants to spend while the business user may think that anything that only costs $45 cannot be as good as something that costs $450. After all, it probably costs the company $45 just to process the payment. So here I sit in a dilemma that I must solve and soon. Perhaps I don't really understand the situation at all, but I must make a decision soon. Having put many long hours into a program, I now want very much to reap some benefit. Is shareware the way to go, or should I be marketing the program like so many others with copy protection and a $400 price tag. Perhaps someone can provide me with much needed insight. PROGRAMMER'S GUIDE App. A Ed Kidera followed up with another letter: Over the last couple of weeks I have been investigating further the various marketing approaches. In doing so I came across several interesting articles. One of them is the farewell editorial of Compute's PC&PCjr. It points out that the vast majority of IBM's and compatibles are owned for business and not for home use. In my previous letter, I suggested that the prices of shareware may be too low for businesses. Since it would seem that we should be aiming our efforts at this majority of the market, should prices be higher? The other articles were discussing software in general. Shareware needs better press. Users need to be educated. They must be shown that they have something to gain from this approach. Magazines tend to ignore shareware, probably because they do not expect any benefit from talking about it. Perhaps with a shareware co-op doing advertising, this would change. The average user is very limited in his use of the computer. He may use it for nothing but word processing or for spreadsheets. These users represent a big potential market, if they can be educated. This group needs programs that are very simple and easy to use. this again brings up the concept of multiple versions. Distribute an introductory version as shareware and sell the full working version at a considerably higher price. Editor's Note: Ed Kidera has followed up on his last idea with a file encryption program. His shareware version will encrypt a letter or similarly small file, and he has a more powerful version available for a higher price. [1989 Addendum:] Evidently, Kidera's encryption program never had any great success, once again pointing out that success depends more on a good product that a lot of people need than on gimmicks intended to keep people from getting to try out your best effort. By way of analogy, let's say you were going to buy an expensive, fully-loaded car and wanted to test-drive it first. If the salesman said "I'm sorry, we don't trust you to test-drive that car, but we have a little stripped-down compact car that we will trust you with. Try it instead." Would you be inclined to buy from this dealer? PROGRAMMER'S GUIDE App. A Frank A. Bell, author of NEWKEY, writes [in 1984]: I am glad to see someone getting the shareware authors together. It would be great if a shareware authors group could be formed to share experiences and ideas. I have thought of doing something like that myself, but I am not willing to give up the time it would require. I have decided to replace the manual on the disk with a tutorial designed to demonstrate the major features of Newkey. Users who register will receive the latest version of Newkey that can be copied for others, plus a printed manual that may not be copied. Jim Button told me that when he stopped putting the full manual on the disk he received a lot of registrations from closet users as well as orders for extra copies of the manual. I am also raising the payment to $39, still a great bargain, considering the manual and greatly enhanced features that will be available in 2.0. I was interested in the letter by the author of PC-KEY-DRAW. Unfortunately, I no longer have the same faith in people's honesty that I once had. I have had several good experiences and some not so good. [Editor's note: Both Bell and Button gave up on "short-sheeting" their documentation and now include their complete documentation on their disk. The following is a 1988 note from Frank Bell. In it he mentions a "delay screen". This is a screen at the start of a program which explains the shareware concept to users and it also serves as a minor annoyance and thus a mild incentive for a user to register and get a version without the screen.] [Most ASP members have reported a very positive user response to the "delay" or "shareware" screen as a method of encouraging registration without crippling the program or limiting the documentation. Note that the "delay" is just until the user presses a key. Actually forcing the user to have to look at the screen for 15 or 30 seconds is a sure turn-off. However, to keep the user from just blowing by the screen by pressing Enter without looking at it, many of us have had success with putting a random number somewhere on the screen and requiring the user to enter the number to continue.] Over the years, I have tried several different methods to encourage purchasing and none of them have made any substantial difference. However, I have been using a delay screen and have received several orders with comments such as "Ok, ok, I'll register. Send me the version without the delay screen." so I do feel that I am getting registrations that I would not have received otherwise. I have never received any negative comments about the delay screen. The purpose of the delay screen is to make integration of my program into the daily computer operations annoying, but not so annoying as to discourage evaluation. I have received many next-day air orders from businesses and consultants who want to install Newkey into a system and don't want the shareware screen coming up. Some of these might have ordered if there were no delay screen, but probably not all of them. Since I furnish the full manual and my product requires little support, removing the evaluation screen is the best practical benefit that I can offer. This way the user can feel virtuous and still get a practical benefit by registering.