Successful Shareware

and Kagi

Hookware

["Hookware" is a term I've just invented for software that pesters the user in some fashion in order to get him or her to pay the shareware fee. The following discussion of Hookware was written by Kee Nethery of Kagi, and is presented here with his permission. -- Rick Holzgrafe]

The Hook

For any product distributed on the internet there is a slider that goes from (Full Functionality and Payment Optional) to (No Functionality until Payment Received). Finding the optimal balance between these two extremes is not easy.

You want to provide enough functionality for a long enough period of time so that people become addicted to your product and so that they become enticed to pay you.

Here are some examples of ways to do this.

Desktop Appearance Manager - Imagine software that beautifies the desktop. This software pops up a message maybe once or twice a day that asks for a payment. The message it delivers is humorous and sincere and the unpredictable appearance of the message causes people to want to have it stop interrupting them. The software is fully functional because it is not essential to anyone's business. When they pay, they are mainly paying for the code number that causes the annoying dialog to cease.
Game - Imagine a network based multi-user action game. Imagine an annoying dialog that pops up during every 5 games or so that comes up at a critical moment and requires that them read it to figure out how to make it go away. During that time, the other users will most likely kill their character and they will lose the game. Most people will pay to keep that from happening.
Graphical Utility - If the utility does graphical manipulations, you could put an advertisement along the edge of the resulting image. When they pay the advertisement goes away.
Network Utility - For network utilities, you could require that they restart the program after every ten actions, you could randomly hide some results, you could limit them to at most two simultaneous actions, you could timer the software so that after 30 days it starts to become annoying, it depends upon the product.
Word Processor - You could limit the size of the document that can be produced, require that they print one page at a time.
Network Server - After a month, every couple of weeks you could pop up a dialog at 2am that stops that service from functioning until they click on it. If your server software is critical to their users, having users complain early in the morning will probably get you a registration fee.

You need to spend time brainstorming with friends and your beta testers on where to draw the line between the two extremes. You want to entice them to pay without causing them to be so annoyed that they stop using the product.

Common Mistakes

Some people develop massively complex password schemes to prevent multiple users from using the same password key. You want to be careful about this. You don't want to make it so difficult for a legit paid user to move their software to their new hard disk, etc. If your protection is really secure your normal paid users will be unhappy with the product and not recommend it to friends your time with support questions.

Some people provide very short trial periods for their software. Few people will install some software and then devote the next two days of their lives to a massive testing of your software. Most people will install it, launch it, and see what it does then not use it for another month until the need for your software presents itself to them. Do not use short trial periods. Instead consider actual hours used. If they have been using it actively for 10 hours over a period of a year, chances are they have a pretty good idea what it does and whether they should purchase it or not.

Do not use a specific calendar date to determine when the software should cease to function. We still receive payments for 3 year old software that people have just found on a floppy and are just now trying. If you kill the software on a specific calendar date, you will lose sales. Worse, you will receive support questions from these people on that date.

Protection

Many software authors spend a great deal of time on how to prevent people from stealing their software. Some of the most successful software has the least restrictive protections. In my opinion, you should accept that there will be theft and primarily focus on providing the best product that you can. Here are the various protecion schemes that I have seen.

None - Clicking on the "I've Paid" checkbox in their preferences causes the "Please Pay" dialog to cease to appear.
Secret Move - Some software has a field where you can enter the registration code but nothing entered into that field will ever unlock the software. Instead there is some secret move that unlocks the software. For example: click on the red shoes three times and then type OZ.
Secret Code: Universal - There might be one secret code that you give to everyone who pays. They all get the same secret code.
Secret Code: Random - The secret code might be randomly constructed where specific caharacters in the code are derived from the other characters so that your software can determine that the code was probably generated by you. Otherwise the characters are random.
Registration Code: User Data - It is very common to derive the registration code from information provided by the user and then to display that user information in the software so that their information gets passed to anyone to whom they give out their code.
Unlocked Version - When someone pays they are sent or they are given instructions on how to download the unlocked version of the software.
Tricks - Do not just put your payment request message at startup. People will treat it as a normal part of using your software and they will ignore it.

Do not dismiss the payment request message through a keyboard button press. Pressing that button could be automated. Instead, swap buttons around, make them read the buttons and press on the correct one with their mouse.

Do not tie your software to someone's hard drive parameters. People reformat their hard drives, they upgrade to larger disks, sell their machines, etc. You will do lots of support for legit users every time there are changes to their hard drive.

Do not threaten to erase their hard drive if they are using a known pirated registration code because you will get blamed for the next bad thing to befall their computer.

Do keep track of the published public rgistration codes and in future revisions, disallow these registration numbers.

Do check for registration code validity in several places in your code and only enable some of these various checks on, for example, odd weeks or even months. If someone publishes a patch for your software, it will work until the next month and then it will cease to work. The cracker will have moved on to other programs and everyone who was using the pirated version of your code will find that it ceases to function.

Summary

Write a good product and lots of people would want to use and make it easy for them to try it and bug them just enough to get them to pay but not so much that they stop using your software.

Introduction Product Patience Polish Pay Up Propagation Promotion Politics Links