Logo Successful Shareware

Brought to you by Semicolon Software

and Kagi


["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.

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.


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.

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.


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