Limiting Your Product
When a new user starts to design a shareware product, there is one question that tends to get asked very frequently: how should I limit my product? How should I restrict use of the unregistered version so that people will have the incentive to pay?
This is one of the most important decisions you will have to make. It is a sad fact of life that, if you don't limit your product in some meaningful way, people will send you less money. Sometimes, much less money. If you cripple your product, however, and make the demo useless in the process, people will never grow to like your product enough to buy it. It's a tough balancing act, and one that is hard to avoid.
If you work for a long time writing a solid, worthwhile product, you deserve to be paid for it. Period. You should not waste one moment of your time feeling guilty for wanting remuneration for your work, any more than you would feel guilty wanting a salary for your job.
However, people usually won't pay you for your software unless you make them. This is not because people are inherently dishonest. Most people are basically honest, nice, friendly people. However, there is a greater force in the universe than greed: procrastination. Paying for your product takes work. A customer has to get up, call you, and make the order, or write a check and mail it, and then wait for you to respond. It does take time, and people won't want to do it unless they have to.
Customers don't like being made to pay for shareware. Get used to this atttude ... it's a common one. People don't go into a CompUSA and complain about being charged for the software on the shelves. People aren't offended when Software Etc. asks $50 for a copy of Quake. Yet, if you, the shareware developer, dares to ask $20 for a program that took a year of your life to write, expect to get some complaining E-mail. It's a sad fact of life, and something you will just have to deal with.
Deciding how to limit your product is difficult, and it's easy to make a mistake. Fortunately, you have plenty of options open to you:
* No Limitations - When shareware was first invented, this was considered to be the only option. The demo version is fully functional. When the user runs the program, he or she seems a message like "This program is shareware. Send $15 to such an such an address." The program relies on the honor system for payment.
Unfortunately, this doesn't work. While people are, by and large, honest, they also procrastinate. They feel they should pay for the program, but they don't get around to it. The end result: you don't get money.
* Nag Screens - Another popular method early on. The demo version is fully functional, but it brings up screens when it's run, saying things like "Please remember that this program is shareware." The screens sometimes come up repeatedly during use, and sometimes they will stay up for several seconds before disappearing. When the user registers, he or she gets a version with no nag screens.
This protection is fairly easy to implement and works to some extent. It is best used with applications that will be used repeatedly for quite a long time, so that the annoyance of the nag screens eventually forces the user to register. This is a less effective incentive with games, which are used for only a short time and discarded before the nag screen has time to wear the user down.
* Feature/Save Limitation - The demo of the program either has a limited feature set (certain useful features are disabled), or is unable to save the user's work. Upon registration, the user gets a fully functional version. This method provides a strong motivation for the user to register, but it can also be very dangerous.
As a shareware developer, your goal is for the user to enjoy using your program, so much that he or she will pay you for it. If you disable enough features to make the product useless, they won't use it. Thus, they won't fall in love with it. Thus, they won't pay you. You have to make sure to leave enough features there for the user to be able to use your program, but leave enough out for the user to want to register. This is a very difficult balance to achieve, and this method will only be useful for a small set of programs.
One sort of program this method is very useful for, however, is games. If the game is split into three or four chapters, with only the first chapter playable in the demo, the user will be able to get involved with the game while having a strong motivation to register (in order to get the rest of the game).
* Time Limiting (fixed time period) - This form of limit is very useful and popular. The program remembers when it was first run, and stops working 30 days after that date. Until that time, the program is fully functional.
One downside of this limitation is that users will try their best to get around it. You will have to be shrewd to find a way to make the program remember when it was first run in a way that keeps the user from getting around it by reinstalling (usually after using an uninstaller program). Preference files (on the Mac) or the Windows Registry (for PC-Windows) are ways to get around this problem, but you'll have to do some research and testing to make sure the program accurately remembers when it was first used.
Another downside of this form of limitation is that a user will often run the program once and then set it aside until it's useful. If the user only needs the program 40 days later, it won't work, and he or she will discard it. One way to get around this is for the program to provide a 10 day grace period when first run after the time limit has expired. A better way to get around this problem is to use a modified form of time limiting:
* Time Limiting (limited number of uses) - With this form of limitation, the program remembers how many different days it was actually used on, and stops fully functioning after 14 or 30 actual use days. This requires a bit more care in programming than the previous method, but makes sure that the user gets plenty of time to use (and like) your program.
Once you've decided what form of limitation to place on your program, you need to decide how the user will get the registered version of the program after paying you your hard-earned money. This is another difficult decision, which will determine how much and what sort of work you get to do after releasing your program:
* Code-unlocking - When using this method, the demo version of your program contains the full program inside it. To be able to run the entire program at full functionality, the user must enter a password of some sort, which they get by paying you.
There are several ways to do this. With the first several games I released, the games, when first run, randomly generated a registration code (a number from 1 to 30000). Each code has a different password attached to it (generated from the code by a secret formula). When the user registered, they gave us that code, and, in return, got the password. Once they put the password into the game, it became fully registered. However, that password would almost never register another user's copy. Unfortunately, if the user uninstalls and then reinstalls their program, or moves to a different machine, they will then need to be given a different password. This means more work for you.
Another option is to do away with the registration code the user needs to give. Instead, the user is given a word/phrase (like "Joe Smith") and a password associated with the phrase (like "143-3212"). The user enters both into the program to register it. While this is simpler than the previous version, if the user then posts this phrase/password combination to USENET, anyone who reads them will then be able to register their copies without paying.
Password schemes like these attract hackers like flies. Hackers will almost immediately crack your program and post to USENET how others can too. Also, users, who are often clueless, will misplace their passwords, and you will have to generate new ones for them. This can add up to a lot of work.
* Sending full program on disk (3.5" or CD) - When a user registers, he or she is mailed the full program on disk. This avoids any problems with code generation systems. However, this method involved a lot of time duplicating disks, extra costs from making and mailing them, and, of course, time spent replacing disks damaged in the mail.
There are services which will, for a fee, duplicate large batches of your disks. There are also programs which will help you duplicate disks safely and quickly. Unfortunately, disks getting damaged in the mail is a sad fact of life.
One advantage of this technique is that, if you send your program on a CD-ROM, you can include extra files that would normally be too large to put in a demo. This can be exceptionally useful for games.
There are tough choices to make, and the penalties for choosing incorrectly are grim. Also, no one answer is correct. Ten different programs will require ten different solutions. Be sure to download a variety of programs similar to yours, and see how they approach this problem. It's a great way to get ideas.
Back to Designing Shareware Page