Hide full article
[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 developer. We asked Rick if we could edit and reprint his work in TidBITS, and he graciously agreed.]
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/>
<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.]
