TidBITS: Successful Shareware

Series: Successful Shareware

Rick Holzgrafe shares his secrets to a successful shareware business

Article 1 of 4 in series

01 Sep 1997 | Print

Successful Shareware, Part 1

[Editor's note: This is the first part an article written by Rick that has appeared elsewhere on the Internet. We found it fascinating not only for the cogent advice to shareware authors but also as a personal explanation of how shareware works from the eyes of a long-time Macintosh developerShow full article

Hide full article

Hello! I'm Rick Holzgrafe of Semicolon Software, and I'm a shareware author. My friends all know better than to bring up the subject of marketing shareware with me: once started, I won't stop talking about it. When I meet other shareware authors, I find that they're just like me: we're all seeking ways to be more successful. I'm not the world's greatest shareware success story, but I have been at it for over a decade, and my shareware income is now a substantial fraction of my day-job income.

Much of the advice in this article was contributed by others: most notably Peter N Lewis and Jeremy Nelson of Stairways Shareware, Kee Nethery of Kagi, Tonya Engst of TidBITS, and the authors on the Kagi Authors mailing list. Thanks to them all.

What is success? I considered myself fairly successful several years ago, when I sold 500 copies of my first shareware product (an adventure game named Scarab of Ra). There weren't as many shareware authors then as there are now, and few had written anything ambitious. At $10 per copy I made a few thousand dollars over the course of about five years: enough to buy some good software and even a little hardware. I also acquired a small reputation and a few nice reviews.

<http://www2.semicolon.com/Rick/Scarab.html>

Right there you have several criteria for success: fame, praise, and, money. In addition, by choosing your own projects you can gain experience you wouldn't get elsewhere. You can also make friends - some friends I've met through shareware are among the best I have; some are not only good friends but useful people to know.

I recommend shareware authors decide what their goals are. Some people are more interested in reputation, experience, and friends than anything else: they are the ones giving away good-quality freeware. However, most will be interested in "all of the above," with a heavy emphasis on money. (You need not be shallow and greedy to want to make money. No one knows better than a developer how much all this hardware and software and time costs. Expensive hobbies are easier to support if they bring in a good income!) The rest of this article is therefore mostly a discussion of how to increase shareware sales. If you can do that, you'll not only make more money, but the rest of the rewards you might want will come along with the dollars.

After some thought, I've realized that there are seven keys to shareware success. I call them the "Seven P's" instead of the "Seven Keys."

1. Product
2. Patience
3. Polish
4. Pay Up
5. Propagation
6. Promotion
7. Politics

You'll see as we go that there's more to shareware than just writing good code. For most of us code is the easy part!

The First P: Product -- You must choose a product to create and sell. There's a lot of software available already, and coming up with something new can be a stumper. I think most shareware authors build products they want to build, rather than software they think will sell. There's nothing wrong with that. However, if you want your product to sell well, it must have an audience, frequent use, an elevator presentation, robustness, commercial-class features, and an attractive price.

Audience -- Let's say you think paleobotany is a totally fascinating subject. You've just spent two years creating a killer application, using your programming skills and your deep understanding of paleobotany. Your program is so powerful and useful that's it's an absolutely essential tool for every person in the world... who is a paleobotanist specializing in the early Cretaceous period who uses a PowerBook in the field. How many copies will you sell?

That's right, not many. A successful product must be attractive to a wide audience. There must be a large number of people who might want to own your product; otherwise your sales will be few and far between. That might sound obvious, but apparently it isn't. I've heard more than one aspiring author describe an application almost as limited in audience as that paleobotany tool and complain bitterly that no one was buying it.

Here are a few examples of successful products with a wide audience:

Anarchie, by Peter N Lewis. Anarchie is an FTP client, good for uploading and downloading files on the Internet. Five years ago it might have been a niche product with a small audience, but what with the recent popularity of the Internet, most computer users want an FTP client.

<http://www.stairways.com/anarchie/>

Aaron and Kaleidoscope, by Greg Landweber, Fred Bass, and Edward Voas. Aaron (now implemented as a Kaleidoscope Color Scheme called "Apple Grayscale") gave Macintosh windows, buttons, and menus a fancier appearance than the standard Mac OS 7, allowing users to taste the then-distant Mac OS 8. Kaleidoscope, the supercharged version of Aaron, adds a new level of flexibility, offering themed appearances and an open architecture that encourages people to create their own themes.

<http://www.kaleidoscope.net/>

Solitaire Till Dawn, by (ahem) your humble servant. If there's a human being alive who doesn't enjoy an occasional game of solitaire, I've never met her.

<http://www2.semicolon.com/Rick/STD.html>

You can also have excellent success with products that interest a large enough category of users, even if they aren't in the majority. Image-processing programs come to mind, for example: not everyone uses them, but their audience is still large.

Frequent Use -- Next, your product must be used often: daily if possible, and constantly is better than daily. I remember a shareware author complaining about poor sales. Why? His product was used only once by any user: it made some tweaks to the system software on disk; once made, the tweaks were permanent. This made the program easy to use and forget.

The author was right to complain that people used his product without paying for it. That's piracy, and it shouldn't happen. But the sad truth is that it does happen, and complaining about it won't change a thing. We'll talk more about getting people to pay later [next week -Tonya]. For now, the point to remember is that most users won't pay for a product unless they're constantly reminded about how useful or fun it is.

The three products above are good examples of programs used regularly. Anarchie is probably used at least weekly by anybody who likes to download software and updates from the Internet, and many people use it many times a day. Games like Solitaire Till Dawn are addictive, and people play them frequently. And Kaleidoscope, of course, is in constant use: its effects show in every window, button, and menu.

The Elevator Presentation -- Experienced salespeople know the value of a good "elevator presentation," a product description that quickly explains to a stranger what your product is and what its benefits are. In essence, an elevator statement must be quick and clear enough to be successfully delivered during an elevator ride.

There's a lot of shareware available, with more coming out every day. Drawing attention to your product in the middle of that stampede is tough. Nobody can try all the shareware available, so they download only the items that sound useful and interesting. You have about a paragraph (on a Web site, in a short review, in the Info-Mac Digest - wherever) to catch your audience's attention and convince it to try your product.

Robustness -- Here's one I'll bet you all understand, but it bears repeating: your product must be robust. No crashes, no bugs, no misbehavior - no excuses!

Perfection is difficult to achieve. I don't know anyone who has never shipped a bug. But you should hate doing that, and you should fix bugs as soon as you hear about them and release an update. Testing is a tremendously important part of your development process. When the major features work reasonably well, find a few people you trust and have them use your program and give you feedback about usability. Keep working and testing on your own until you think the product is ready to ship. At that point you must resist the temptation to ship. Instead, begin beta testing.

There are two approaches to beta testing: a small, hand-picked group or a large group. A small group lets you work closely with each tester, and you can choose your group so that every tester is a valuable contributor. But with a small group it's hard to get wide coverage of different hardware and software configurations, and different use patterns. A large group provides that wide coverage, but you'll have to settle for inferior bug reports (on the average), and you won't have time to maintain a relationship with every tester.

If you post a call for testers to a relevant newsgroup, you will have plenty of volunteers. I usually work with small, carefully chosen test groups. To find good people, I post detailed requirements in my call for testers. I reject those who fail to follow all the instructions in my posting because I don't think they're sufficiently conscientious. I require them to tell me about their system hardware and software, and to describe themselves, their experience with testing, experience with products like mine, and experience with computers in general. I use the answers both to separate the good testers from the bad and also to ensure a wide range of testers.

Allow at least two months for your beta test, and be prepared for it to last longer if significant bugs keep turning up. Run your beta test until the latest test version has gone at least two weeks without any problems reported. Nobody will buy a shoddy product. Make it work!

Commercial-Class Features -- Even though you're producing shareware, it must be as good as a commercial product. Anything less looks cheesy.

It's best if you can be as good as - or better than! - your best commercial competitor. That's not always possible, of course: few shareware authors can match the efforts of the army of programmers, artists, and writers that Adobe unleashes on every release of Photoshop, for example. You can still have success with a lesser product, provided it's a good one, and provided it's far cheaper than your competition. You can then be perceived as an economical alternative for users who don't need or can't afford the high-end product. An example that comes to mind is KeyQuencer 1.0, a $10 shareware program: not as fancy as QuicKeys, but cheaper and still a fine, powerful product. [KeyQuencer is now at 2.0 and sold as commercial software along with the shareware KeyQuencer Lite 2.0; see our review in TidBITS-351. -Tonya]

<http://www.binarysoft.com/kqmac/kqmac.html>

Attractive Price -- Shareware fans usually list bargain prices as one of shareware's primary attractions. If your product is as good as its commercial competition you might get away with charging as much; but my belief is that you're better off setting a noticeably lower price. Commercial products often come with materials like floppies, CD-ROMs, and printed manuals, which represent costs you don't have. Pass along some of the savings to your customers.

The Second P: Patience -- Maybe your first release will take off and make you a million bucks. Most don't, and that leads us to patience, a rather short topic.

Your first release probably won't be a raving success. That's okay: it's true for professionals too. The secret is not to give up. You'll learn from your first release: why people didn't buy it, what they didn't like about it, what features you should have added, what user interfaces were clumsy, what functions ran too slowly. In your second release you'll fix all of those, and your sales will increase. And you'll do the same thing again: listen to your customers and your non-customers, and make release three a real killer.

Consider Microsoft Windows. Version 1.0 was a dog. It was used by few and laughed at by many. But Microsoft didn't give up; they shipped Windows 2.0. It still wasn't a success but was better regarded than the first release. Real success didn't come until Windows 3.0 - and Microsoft still continues to improve it.

[Tune in next week as Rick discusses more keys to shareware success.]

[Rick Holzgrafe has programmed for a number of well-known Silicon Valley firms when he's not crafting shareware products.]

Article 2 of 4 in series

22 Sep 1997 | Print

Successful Shareware, Part 2

by Rick Holzgrafe

Hide full article

In part one of this article (see TidBITS-395), I introduced my list of seven "Ps" that shareware authors must consider when creating and marketing their products, and talked about the first two: Product and Patience. This week's installment covers the extremely important third P, Polish. Next installment I'll hit the last four Ps: Pay Up, Propagation, Promotion, and Politics.

The Third P: Polish -- "The first 90 percent of the job takes 90 percent of the time, and the last 10 percent takes the other 90 percent." It's true - when the programming's done and all the features work flawlessly, you're not nearly done preparing your product for release.

Another great quote is "Sweat the details." Tiny details matter more than many programmers think. Your potential customers want to have confidence in your product. The more flaws they perceive, the less likely they'll be willing to pay, even if the product performs perfectly. That may not be rational, but it's true.

So what kind of details are we talking about?

Make It Pretty -- People are more willing to buy a product that looks good. Prettiness is not a substitute for robustness or functionality, but the better looking your product is, the more copies you will sell.

If you are not artistically inclined, then find someone who is. Talk a friend into doing your graphics for free, or hire someone you can afford. A tasteful splash screen, a spiffy logo, cool icons, and button labels go a long way toward a good impression. Every time I've improved the appearance of Solitaire Till Dawn I've had a big jump in sales, and I don't think it's a coincidence. Pretty pays!

<http://www2.semicolon.com/Rick/STD.html>

Human Interface Guidelines -- Every platform - Mac, Windows, Unix, you name it - has a "style." The Mac especially has a reputation for a completely consistent user experience, due to Apple's early publication of its Macintosh Human Interface Guidelines. These guidelines specify in detail where icons and buttons should be placed, how large these elements should be, how much white space should surround them, the proper use of color, sound, and much more. This is why, in every application, you find the commands such as Quit, Print, and Open in the same place, with the same names and the same keyboard shortcuts. Most Mac developers have learned not to mess with these commands, because Mac users turn their noses up at applications that get the Human Interface Guidelines (HIG) wrong. But there's much more to good human interface design than those obvious points.

HIG: Lay Out Dialogs and Alerts Carefully -- Many programs have cluttered, crowded windows. Users prefer windows with only a few controls and plenty of white space. Controls and displays should be carefully organized: related controls should be together, perhaps grouped and separated from unrelated controls. Align checkboxes and buttons so your layout doesn't look sloppy. Place common elements consistently - the OK and Cancel buttons should be in the same place in all dialogs.

If you have too many controls, consider using swappable panels or some way for the user to select a category of controls so that the window displays only those controls and hides the rest. This technique lets you cram many controls into a small window without crowding. Look at Netscape Navigator or Eudora for examples.

HIG: Avoid Dialogs -- The fewer modal dialog boxes you present, the better. They interfere with the user's workflow (or "playflow"). Often they report error conditions of various sorts, so a good way to eliminate them is to reduce the number of possible errors that must be reported to a user.

A good example of bad dialog use is a solitaire game I once saw. To move a card, you first had to click it. Then you had to click the place you wanted to move it. If you clicked on an illegal destination, you saw an alert dialog, telling you that you couldn't make that move. Worse, if you clicked a card you wanted to move, then changed your mind, there was no easy way to cancel the move. You had to click someplace illegal, suffer the alert, and dismiss it before you could try to move a different card.

A better interface is to have the user drag & drop the card over the intended destination. When you release the button, the card drops. If the card is not dropped over a legal destination, the card quietly zips back to its starting point, and the user can try to move something else immediately. An improvement would be to have legal destinations highlight as the card is dragged over them.

If you can design your interface so the user can't make mistakes, you'll eliminate a whole class of user annoyances and avoid writing lots of boring dialogs.

HIG: Too Many Options Are Bad -- Whenever you have to decide whether a feature should work this way or that way, the temptation is to make it work both ways and give the user the choice. Sometimes this is the right thing to do, but too many options frighten users. Most people want programs that are simple to understand and use. Anything that looks too complicated will be tossed in the trash.

So how do you minimize options? One way is to ask yourself how many people will need the choice. If 90 percent of your users want the feature to work the same way, you might be better off hard-coding it that way and letting the other 10 percent be frustrated.

Sometimes options can be hidden. Peter Lewis's FTP client Anarchie puts up a progress window during file uploads and downloads. The window shows progress in a variety of ways, including a numeric estimate of how much longer the operation will take. Some people, however, prefer to know how long it's taken so far; others want to know what time it will be done ("5:35 PM" instead of "twelve minutes from now"). Peter could have put all those indicators in the window, but that would have made a huge, cluttered, unreadable display. He could have put the options in a Preferences window, but that would have resulted in a complicated interface. His solution was simple and effective. When the user clicks the numeric readout, it switches to an alternate form. Click again, and see a third form. Click again, and you return to the first. Power users learn about this by reading the documentation or the online Tips, but users who don't care may never realize that the feature exists.

<http://www.stairways.com/anarchie/>

Sometimes, options are the wrong solution to a problem. A utility of mine, The Tilery, lets you switch among open applications by clicking tiles. When you click a tile, The Tilery comes to the front, as all applications do when their windows are clicked; it then immediately tells the operating system to bring forward the selected program instead. The Tilery winds up as the second-to-frontmost application, right behind the one whose tile was clicked. This is fine until the user decides to quit from several applications at once by pressing Command-Q repeatedly. When the frontmost application quits, the next in line - The Tilery - floats to the front. But because The Tilery doesn't look like a normal program, users tended to forget that it is, so when they press Command-Q again, they quit The Tilery (which in most cases isn't what they intended). Very annoying, and I used to get a lot of mail about it.

<http://www2.semicolon.com/Rick/Tilery.html>

My first solution to the problem was to provide an option to have The Tilery ignore Command-Q (so you had to choose Quit with the mouse). That solved the problem, but in the wrong way: The Tilery would still quit unexpectedly unless you set that option. You had to read documentation to find out what the option was for, and the menu item that controlled it contributed to the apparent complexity of what should be a simple utility. Also, the basic problem still existed: The Tilery wound up frontmost at unexpected times.

The real solution was to keep The Tilery in the background until and unless it is deliberately brought forward. It took me a while to figure out how to do this, but the result is a great improvement. (Confession time: the old Ignore Command-Q option is still in there, because it was an established part of the user interface by then. The new feature brought options of its own, so the options interface is now even more cluttered. But at least the right problem is being solved now!)

HIG: Organize Menus Carefully and Sensibly -- Users shouldn't have to hunt through a maze of menus and sub-menus to find a command. Menus should be organized in a sensible, intuitive fashion. Examine each command's function - does it belong under File or Edit? If it's a command with a host of sub-commands, consider making it a new menu instead of creating hierarchical menus. This isn't always as easy as it sounds, but "sweat the details" and try to design a set of menus that is clean, simple, and elegant in its layout and wording.

The list of human interface details to attend to can seem endless. One source of good feedback is your beta team; after you ship, users are another. They'll tell you what works and what doesn't - not just bugs, but interface subtleties, too. Your job is to listen when they talk.

Spell Stuff Rite -- Good spelling and grammar are vital. All text that you display to your users, whether it's in the manual or an alert box or a menu, should be properly spelled and grammatically correct. It's part of the overall impression your software makes on every potential customer: the fewer flaws they see, the more confidence they'll have in your product.

If you're not good at spelling and grammar, find someone who is and beg or hire them to review and correct your work. Use spelling checkers if you like, but remember that a spelling checker won't tell you that you should have written "lose" instead of "loose" or that "its" should not have an apostrophe when it's a possessive. You may not think these fine points are important if you don't notice them yourself, but plenty of your users will, including reviewers. [We editor types cringe when we see these basic mistakes, and believe me, they happen even in big commercial products. -Adam]

Documentation -- A well-designed application may not need much documentation; it may be obvious how it should be used. Users never bother to read manuals anyway, so why waste time writing them, right? In fact, many users do read manuals, and I presume you at least want them to read enough to know how to send you their payment!

Knowing how to write a good manual is a career in itself; plenty of people make their livings doing it, and I can't teach you the art in a few paragraphs. But I can give you a few useful tips.

Unless your product is dirt-simple, you should ship it with both a short ReadMe file and a separate, comprehensive manual. The ReadMe should be a text document that briefly covers the following points:

Product name
Version
Ship date
Company name
Author name
Description (the "elevator presentation" - see TidBITS-395)
What's new (list of fixes and new features, if an upgrade)
Requirements (Mac, system software, RAM, monitor bit-depth, etc.)
Price
Payment instructions
Copyright
Distribution information and restrictions
Contact information (email, Web site, postal address, fax, phone)

Nearly everybody who might care about your product will want that information, including users, reviewers, and people who want to put your product on their Web site or CD-ROM. They'll be frustrated if it's missing, scattered, or hard to find. Put it all into the ReadMe file, and keep it short and to the point. See Tonya's article on ReadMe files in TidBITS-330 for a good discussion of this subject.

Before you begin writing your manual, think about how users will want to use it. Few will read it front to back before trying your product. Most will refer to it later, when they encounter something they don't understand, or can't figure out how to do something. To help these people, organize your manual in those terms. Instead of documenting every menu command in order, have a chapter labeled "How to..." Include a "Troubleshooting" chapter organized so that readers can look up problems and find solutions easily. After you've released a few upgrades, you'll know the most common problems. In your first release you'll have to guess.

The first chapter should explain the rest of the manual and mention what each chapter covers, so users can quickly find what they need. Use diagrams and pictures, which work better than text for explaining visual concepts.

Use any medium you like for your manual, as long as every user can read it. Don't ship your manual in Microsoft Word format, for example: far too many users won't have Word. A variety of ways exist to create stand-alone documents that can be displayed and printed on any Mac. If nothing else, save it as a text file.

Also consider online help. There are a bunch of ways to do it, but again, the key is organization: the way you see your product is different from the way the user sees it. The user will be wanting answers to questions such as "How can I..." and "Why can't I...", and your online help, like your manual, should be arranged so that users can find answers quickly.

[In the next installment, Rick will discuss the final keys to shareware success.]

[Rick Holzgrafe has programmed for a number of well-known Silicon Valley firms when he's not crafting shareware products.]

Article 3 of 4 in series

06 Oct 1997 | Print

Successful Shareware, Part 3

by Rick Holzgrafe

Part one of this article (see TidBITS-395) focused on two items from my list of seven "Ps" that shareware authors need to consider: Product and PatienceShow full article

Hide full article

Part one of this article (see TidBITS-395) focused on two items from my list of seven "Ps" that shareware authors need to consider: Product and Patience. The second installment covered the third P, Polish (see TidBITS-398). This week, I'm continuing with the P that is often the most difficult aspect of shareware publishing: Pay Up. Next time, I'll finish with Propagation, Promotion, and Politics.

<http://db.tidbits.com/article/04108>
<http://db.tidbits.com/article/04155>

The Fourth P: Pay Up -- Sad but true: most people don't pay shareware fees without incentive. I believe most people are honest - but I also believe most people are lazy and forgetful. Nothing's easier to forget than an unpleasant task, and bill-paying is high on everyone's List of Unpleasant Tasks.

Pay Up: Crooks, Solid Citizens, and Mouse Potatoes -- In my mind users fall into three groups. Crooks won't pay if they can avoid it. I don't waste much thought on them: thieves should be stopped or punished, but it's difficult to do either with regard to shareware. Solid Citizens pay every shareware fee promptly, or else throw out the product - no incentives needed. I don't waste much thought on them either, except for an occasional thankful thought that such people exist.

Those in the middle I call "Mouse Potatoes." These are basically honest folks who need a little help in order to be as good as Solid Citizens. At bill-paying time their minds are on the mortgage, the kids' tuition, and the auto insurance - not on the delightful game they'll play after they finish the bills. These are the people you can influence, and who will pay if you make it easy and attractive. Here are some techniques:

Pay Up: Reminders -- "Nagware" is software that reminds you to pay. Typically all it does is nag. It doesn't deny any functionality to unpaid users - it just tries to annoy them into paying. After paying, the user receives a way to stop the nagging.

Nagware can be effective. A number of successful products use it, such as Peter Lewis's Anarchie and NetPresenz, as well as my Solitaire Till Dawn. In fact Anarchie and Solitaire Till Dawn rely completely on the user's honesty: anyone can turn off nagging by clicking a checkbox in the Preferences window labeled "I Paid," whether they paid or not. This works because so many people are honest but forgetful. It may take them months or years to pay their fees, but they won't commit the dishonest act of clicking the "I Paid" button until they've sent their payments.

<http://www.stairways.com/anarchie/>
<http://www.stairways.com/netpresenz/>
<http://www2.semicolon.com/Rick/STD.html>

Pay Up: Incentives -- Another technique is to offer the user something valuable for paying. Usually this takes the form of "crippleware," a program that runs in a semi-functional demo mode until the user pays. Once registered, the user gets access to the full product, perhaps via a password, a special FTP site, or even by receiving the fully functional version via floppy disk or email.

Another incentive is to offer an add-on or bonus - a printed manual, a disk of goodies, another program - after payment is received.

If you sell crippleware, be prepared for some battles. If your product is popular, some criminal will immediately hack it so its full functionality is available for free. Or, someone may post one of your passwords. Any goodies you send to paying users will eventually show up on pirate bulletin boards. There are ways to wage these battles; if you relish combat, then good luck to you. My belief is that criminals won't pay no matter what you do; battling them wastes time. Put your effort into improving your product and convincing mouse potatoes to pay.

This philosophy doesn't mean the crippleware approach is bad. It works well on mouse potatoes because crippleware is even more annoying and inconvenient than nagware. Most top-selling shareware products I know of are crippleware. Just remember it won't thwart determined pirates, so don't spend all your effort trying to bullet-proof your protection schemes. Find a middle road that will influence mouse potatoes without annoying users who have paid. (Hell hath no fury like a paid user who is denied service because both he and the product have forgotten his password.) Remember that you have to send passwords to every paying customer, and deal with calls and mail from users who have forgotten their passwords. Design a system that will minimize effort and grief for both you and your customers.

For an excellent discussion of various incentives, their effectiveness, and their cost to the developer, see Kee Nethery's discussion of "hookware."

<http://www2.semicolon.com/Rick/ShareSuccess/ Hookware.html>

Pay Up: Make It Easy -- In my first few years, I required customers to pay in either U.S. cash or a check in U.S. dollars drawn on a U.S. bank. It was (and is) too expensive for me to convert foreign currency. I would have liked to take credit cards, but if you're a hobbyist it's hard to talk a bank into treating you the same way they treat a merchant with a storefront. This meant that to pay me, people had to write a letter and usually a check. That doesn't sound like much effort, but it's a stopper for a lot of folks. Foreign customers were worse off - it's no simpler for them to get American currency than for me to cash foreign currency.

Then Kagi came to my rescue. Kagi is a company that handles payments for shareware authors (among others). My customers send payments to Kagi, and Kagi sends me a lump-sum check each month, minus a few percent for themselves and for bank fees.

<http://www.kagi.com/>

This is great for my customers. Kagi provides a small program to include with my product, giving users an order form. They can pay with a U.S. check, currency from over a dozen major nations, by credit card, or other options. If they pay with paper, they just print the form and send it to Kagi with their payment. If they choose credit card or an electronic form of payment, they can fax or email their information.

When I started using Kagi, my sales increased by 50 percent. (Kagi doesn't promise this benefit and some Kagi clients haven't seen it, but many have.) Kagi makes it possible for customers to pay on the spur of the moment without messing with money or stamps. Kagi isn't the only firm offering such services, and I encourage you to explore options. I recommend Kagi highly - and no, I'm not paid for bringing them clients!

[In our next installment, Rick will discuss more keys to shareware success.]

[Rick Holzgrafe has programmed for a number of well-known Silicon Valley firms when he's not crafting shareware products.]

Article 4 of 4 in series

20 Oct 1997 | Print

Successful Shareware, Part 4

by Rick Holzgrafe

Part one of this article (see TidBITS-395) focused on two items from my list of seven "Ps" that shareware authors must consider: Product and PatienceShow full article

Hide full article

Part one of this article (see TidBITS-395) focused on two items from my list of seven "Ps" that shareware authors must consider: Product and Patience. The second installment covered the third P, Polish (see TidBITS-398). After talking about Pay Up and Propagation in the last issue (see TidBITS 400_), it's time to wrap up with the final two Ps: Promotion and Politics.

<http://db.tidbits.com/article/04108>
<http://db.tidbits.com/article/04155>
<http://db.tidbits.com/article/04181>

The Sixth P: Promotion -- "If you build it, they will come." I'm here to tell you they won't. If you don't advertise your software, few people will notice it or buy it. Promotion (also called evangelism) is the art of shouting good news about your product and getting other people to shout good news about it, too. It takes time and effort and perhaps a little money, but it's essential to your success. Here are some ways to start shouting.

Promotion: Advertising -- If you have the bucks, you can make people notice your product. Just buy advertising everywhere: in magazines, on Web sites, on TV, in inserts in other people's commercial products.

The trouble with that idea is that it takes a barrel of bucks. Advertising is hideously expensive, and few shareware authors can afford it. In ten years of selling shareware, I have never paid a penny for advertising. That's not because I don't approve of advertising, but because a penny buys precious little ad space and I've never had the ton-weight of pennies it would take to buy significant ad. Ads in major magazines, for example, cost thousands of dollars, and even in my dreams I don't have enough money to consider television ads, which can cost tens or hundreds of thousands of dollars.

Lately an alternative has appeared that might be worth considering. Many major Web sites support themselves by selling ad space, and the starting rates are in the low hundreds of dollars: high for anyone on a shoestring, but not out of the question for everyone. I haven't tried it myself, so I can't recommend it - maybe it's worthwhile, maybe not. But all publicity is good, so if you can afford a small Web ad, it might be worth the experiment.

Promotion: Your Web Site -- Set up a Web site of your own. This won't cost you more than $20 or $30 per month from most ISPs, and you may be paying for it already. If not, you should be: this is a case of spending a little money in order to make more. If you can't hack raw HTML, then invest in any of the good HTML editors that are now available - there are plenty, just pick one.

Your site should offer the same information that's in your Read Me file. Unlike a Read Me file, however, your site is primarily an advertisement, so organize it differently: put the boring (but important) info near the bottom, and put your brags and puffery near the top. Don't go wild with huge graphics: many users won't wait for a big page to load over a slow modem. Do make the page as good-looking and professional as possible (just like your product). You can put big screen shots on separate pages for people who are willing to put up with big downloads. Use smaller screen shots or thumbnails on your main page, along with your company and product logos. In your download area, for a Mac product, offer pointers to selected Info-Mac and UMich mirrors around the world. Redundancy is good, because not all sites are available all the time.

If your product becomes popular, your $20 Web site may not be able to handle the load. When that happens, find a more expensive site that can take the traffic. It's worth it! When you can afford it, register a domain name of your own with InterNIC for $50 per year. That way your site will be easier to find (www.semicolon.com is all it takes to find mine) and you'll be able to move your site to another provider without invalidating links and bookmarks to your old one, which can prove invaluable.

<http://www.semicolon.com/>

Promotion: Other Web Sites -- There are a zillion Web sites, and some of them attract people who should be your customers. Some are shareware sites, some are concerned with the work or play that your product offers. Find these sites and send mail to their webmasters. Give them your elevator presentation, ask them to link to your site promise to link back to theirs, and ask them to review your product. Evangelize! Be polite, but get their attention.

Promotion: Usenet News -- Usenet is a great, free way to spread the word. But be careful - you will anger many people if you use newsgroups for blatant advertising. Newsgroup readers will generally put up with brief, to-the-point announcements of your new releases; they'll regard those as public service announcements. But if you post every week with, "Check out this great software!" you will drown in hate mail. Respect Usenet: only post when you have news, and only post in appropriate newsgroups.

Promotion: Press Releases -- Use a press release to blow your own horn. News organizations want press releases; it's one of the major ways they get news about the business world. [If you post a press release on your Web site, make it easy for the press to locate it. Many sites have a press link on the home page, or link from the home page to an "About Us" page that then links to press releases. You might also reference a press release from the page belonging to the product it describes. -Tonya]

The Seventh P: Politics -- The last of our Seven P's is Politics: the art of making nice. You want to make as many friends as you can, for two reasons. First, friends are cool! Second, a good collection of friends adds up to a tremendous amount of goodwill, an asset for any business or person.

Politics: Be Nice -- Always be courteous, no matter what the circumstances. Say "please" and "thank you" a lot, just like Mom taught you. Before sending a message, read it, re-read it, and look for ways in which the reader might misunderstand what you're saying. Many shareware authors are not great writers, and it's easy to write something that unintentionally gives offense. Your readers can't see your face or hear your tone of voice, and they may not realize you're trying to be funny or sarcastic. If you distribute your product via the Internet, it's especially important to consider that English may not be the first (or principal) language of your readers. Be clear and precise.

Politics: Help Everybody -- I made the mistake in my early years of refusing to provide technical support to people who hadn't paid their shareware fees. One day I refused service to someone whose check I had misplaced. I apologized profusely, but the damage was done: that person will never buy my software again, and will tell others what a lousy person I am. Now, I support everyone, and I don't ask whether they've paid.

Helping everybody has another benefit. Many of your users (the "mouse potatoes" I talked about in part three of this series) won't pay until they need something from you. Give them a little support and - presto - a check shows up in the mail.

Politics: Make Friends -- I mentioned the benefits of making friends already. What kind of friends can you make?

Developers are good friends. They can help solve technical problems, and give advice on selling your products. In return, of course, you help them solve their problems, and share your own good advice.

Artists are good friends. Even if they can't contribute free artwork, they can offer good advice on graphic design, and perhaps point you to artists within your budget.

Journalists are good friends. They can offer advice on promoting your products, they can tell you about trends in your part of the industry, they may be willing to write reviews, and they will listen in a most flattering manner to any news, gossip, or opinion you can offer in their areas of interest. Plus, they're fun to listen to: they're knowledgeable and good with words.

Webmasters are good friends. They can publish links to your site, advise you on site design, and occasionally offer you an interesting opportunity,perhaps an offer of advertising space in return for a few free copies of your product to their raffle winners.

But mostly, friends are good to have. Friends are better than money, better than fame. I've met some of my best friends through my shareware business - even though I've never seen some of them face to face. So make friends, lots of them! It's the best advice I can give.

That's it folks. I've given my take on the seven P's of shareware success. If you'd like to further explore this topic, check out my page of links to more information.

<http://www2.semicolon.com/Rick/ShareSuccess/ SharewareLinks.html>

[Rick Holzgrafe has programmed for a number of well-known Silicon Valley firms when he's not crafting shareware products.]

Show the full text of all articles

TidBITS Watchlist

Find Next Without Using the Find Dialog in Word 2008

Recent TidBITS Talk Discussions

Series: Successful Shareware

Successful Shareware, Part 1

Successful Shareware, Part 2

Successful Shareware, Part 3

Successful Shareware, Part 4