Tips & Hints for
Shareware/Freeware Authors
Written by Matthias Kahlert, mkahlert@kagi.com
http://www.GeoCities.com/SiliconValley/Pines/8031/index.htm
General Information: Crippleware
Some estimates show that about 2% to 4% of all shareware users are paying for the applications they use. This is a very low percentage, so how can you convince the other users to pay for it?
The most effective way is to cripple your application. An experiment from Colin Messit showed that crippling software can really increase the number of registrations. Please read Why Do People Register, Does Crippling Work, Does Anybody Really Know? to get some more details.
In the following chapters you'll now find some ideas how an application can be crippled. All have advantages and disadvantages, so please decide for yourself what the best option is.
A good and simple way is showing a splash screen and shareware reminder. You should show this window and startup and when the user quits the application. If you use such a splash screen, you should show it not just at startup. Show it after the user tested the application, especially when he quits it.
You can include two buttons inside the shareware reminder, one the dismisses the dialog (normally called "Not Yet") and one that lets the user enter his registration code. Be sure that these buttons can't be activated using the keyboard or any other shortcuts, because things like that can easily be automated with macro recorders. You can also exchange the buttons based upon a random number generator (one the the dismiss button is on the left side, the next time it is on the right side, etc.)
You can also link this dialog with a timer, so that the user has to wait some seconds before he is able to close the shareware reminder. But don't make this period too long, 3 to 5 seconds are enough in most cases (and if the shareware reminders comes up three times during the usage it can be very anoying...)
Another more or less good way is to use trial periods. This offers two possibilities:
- When the user starts the application for the first time, set up a counter that is increased each time the program is run. You can limit the counter to 30 or 50 startups, and after that trial period some of the important features of your application are disabled. During the trial period all features of the software should be available, exactly like in the full version.
But be sure to use a reasonable number... Many users just double-click some applications they find on CD-ROMs, if they like it or if they think it is useful, they copy it to their hard disk. But nearly no user will really test the application this first time, the tests are often many days or even weeks later when they find it again on their hard disk.
- This leads directly to the next possibility: date limitations. When the user runs your application the first time, you can save this date anywhere in the preferences file. The next 30 days the application provides the whole functionality, but after that limit the important features are disabled.
But like I said above: Many user first copy the application to their hard disk and then test it many days or weeks later. So a time period of 30 days may be too short for most users.
- The third and best way is to use a counter that counts the hours and minutes the user is really using the application. Each time the user starts the software you can show a message in the splash screen showing that time, like "You have been using this software for 2 hours and 21 minutes".
If the time limit is run out you can show a message like "You have been using this software illegaly for more than 20 hours".
- In games there is another way: Count the number of times the user is playing a level or a round, and show him how often he really used the game. This way the user can see how often he really uses the software, and this perhaps convices him to pay the shareware fee.
If you use the trial period linked with the date, don't set a time-out date! If your application just works until 31. September 1997, you'll surely loose some registrations! If your application is included on any CD-ROM, there are surely some users that find your application many months later... And everything you post somewhere to the Internet will surely never disappear. Many shareware authors still get registrations for applications they wrote years ago...
Copying / Saving / Printing |
Another way to cripple your software is to cripple the clipboard, file and printing features.
If your application works with files, you can automatically add a string or any other advertisement each time the user copies, saves or prints something. Put a big "THIS HASÊBEEN CREATED USING ANÊUNREGISTERED VERSION OF MY APPLICATION" at they edges of each print, or put a "UNREGISTEREDÊVERSION" across each copy.
But if you restrict it in this way, you should carefully think about how you cripple it. The user should still be able to work with the results of your application, so it isn't a good idea if something is missing on the print or the saved file. But a big "UNREGISTERED" may be very anoying, especially if the user wants to give the results away to other users...
Another way is to restrict the file features. If you have a text editor, you can limit the maximum file size to 10 KByte, or in an graphic utility limit the resolution to 512x342 pixel.
You can also offer some professional features for registered users. Just some utilities or functions that make your application much easier to handle (additional printing capabilities, etc.). But think carefully about whether these features belong really only into the professional version. Do not exclude essential features in the standard version!
There are also some options, that are specific to certain kinds of applications. For example:
- In games you can pop up a shareware reminder at the climaxes of the game (e.g. at the end of the levels, etc.). These interruptions really disturb! But don't show them too often. Give the user some chances to win the levels.
- If you have a network or fileserver utility, you can popup a shareware reminder dialog on random days at 2 pm. that stops the complete server or service. And if that server is critical to the users you can be sure that the administrators will soon register for it...
Very important:
- Do not cripple significant features of your application, the user should still be able to work with it! A crippled software should not become a demo version!
- Time limitations force the users to register now or never, and they often choose to register never...
- Do never tie your application to someone's hardware parameters. Users often reformat their hard drives, they upgrade their hardware, they buy new computers, etc. This only creates a lot of support work you have to do, each time a user changes something you'll have to send out the new code.
A good source about crippling software is the experiment from Colin Messit, Why Do People Register, Does Crippling Work, Does Anybody Really Know? Just surf to it to get some more details and statistics.
Do you have any new ideas or aspects? Please let me know. Just send an e-mail to
mkahlert@kagi.com.
Modified on 9. September 1997
Back