Why Do People Register, Does Crippling Work, Does Anybody Really Know?

Colin Messitt

Most authors…

…like I did, enter the Sharerware industry with the belief that nobody is going to pay them for their software unless they take some positive steps to ensure that happens. The real question of course is what the most effective steps are.

There are many, many things that must happen for a shareware program to become sucessful (and I define sucessful as producing a good income for the author, not just being a widely used and acclaimed program), but there are five that seem to me to form the fundamentals for success.

Five Fundamentals For Success

First, the program must be something that users actually need, which, sadly, a lot of shareware releases aren’t.

Second, it must actually be good, and again the vast majority of shareware releases are second-rate and buggy (and consider that this becomes more important for shareware because it is much simpler for the user to reject it than for him/her to reject commercial shrink-wrapped software if he/she doesn’t like it).

Third, potential users must be alerted to the availability and desirability of the program - good old fashioned marketing that, again, a lot of shareware authors either don’t enjoy or aren’t very good at.

Fourth, the product must get into the hands of the potential evaluator, either by his getting the evaluation version himself (from a BBS or Vendor or the Internet etc.), or by it being presented to him in some way (on a magazine cover disk, bundled with other software or hardware etc.).

And finally, assuming the user actually needs the program after all the preceeding steps, there must be a reason for him to pay for it.

Industry Myths

As anybody reading this will know, there are a vast number of “experts” in the shareware industry who purport to know what works and what doesn’t, and they put forward any number of reasons why a user would pay for a piece of shareware, including additional features, removal of nag screens, printed manuals and just plain honesty. These so called “experts” also often put forward the myth that crippled software doesn’t get distributed, doesn’t sell and harms the shareware industry in general.

However, if you ask for statistical evidence of any of these claims you won’t get any. And perhaps most sadly these mythical beliefs have been enshrined in what is known as the ASP’s Policy on No Crippling (PONC) and taken to be gospel without a shred of evidence. Indeed people who put forward alternative views were decried in almost the same way as people who suggested the Earth was round back in the Middle Ages.

When I started attempting to market my programs as shareware I effectively time-limited them, and achieved a reasonable if not spectacular measure of success. Then I listened to the “experts” and thought that maybe I was doing things wrong, and would have more success by removing the time-limiting.

My registration rates went down dramatically, even though there were the suggested incentives of a manual and more features in the registered version. After several months of waiting for the magical increase in registration rates to come I put the time-limiting back and the registration rates picked up again.

I hadn’t gathered statistics about exactly what the effects were but it seemed quite obvious to me that enforcing payment was crucial. Then a chance discussion presented an idea for a product that seemed like it would sell, presented the perfect opportunity for experiment, and would allow firm statistical evidence of the effect of enforcing payment to be measured.

The Experiment Begins

The program in question is called SmartDoc and is a Windows utility that allows the text to be extracted from a Windows Help File, or for the Windows Help File to be printed completely. As it only took a couple of days to put together I wasn’t too bothered about losing a significant investment of my time, and it seemed like the data would be valuable.

To ensure equal distribution there was only one version of the unregistered code. It determined in a purely random manner on a straight 50/50 basis whether to act in one of two different ways (and always acted that way even after deletion and re-installation).

In the first case (I’ll call it “PoNC Compliant” from here on in) there were no restrictions in functionality. There were two RRS’s (Registration Reminder Screens), one at the start and one at the end.

In the second case (I’ll call it “Restricted” from here on in) there were the same two RRS’s, but every fourth page of extracted text was reversed and every fourth printed page was replaced with an order form. The end-user could still see it was going to do the job, but he couldn’t make beneficial use of it without registering.

We could tell upon registration what behavior the user was experiencing because the program gave a slightly different release number, and printed a different order form for each case.

We did get quite a few “don’t knows” when people just scribbled on the back of a check, and particularly when people ordered based on an article in the media, but with significant numbers we could tell.

The registration fee for SmartDoc is 25 US Dollars. The program was released on 16th February 1994. The following table presents the registration statistics since then:

Table Here

The total value of all registrations comes to $34075.

So what does it all mean?

That must be left to interpretation, but it seems quite obvious to me that crippled software does sell, at a ratio of around 5 to 1 over software that relies on the user’s honesty and a couple of nag screens. As time goes by the ratio of “unforced sales” slowly declines, presumably as the software reaches out beyond the usual shareware community. The improved showing of PoNC registrations in June is, I believe, due to a major media article that encouraged corporate users to seek out the product.

Assuming that if all copies had been restricted the monthly registration count would have risen by the difference between the “PoNC” and “Restricted “ figures total sales, there has effectively been a loss in sales of 685 copies, for a value of $17125, which I guess is what the experiment cost to perform.

In Conclusion

Another interesting issue is that distribution was hardly hampered at all; you will find it on almost every BBS in the world and all over the Internet. It has appeared on many cover disks in Europe and in a large number of vendors catalogs including PBS’s. There was no secret made of the fact that the software reversed every fourth page - the removal of this feature was listed as one of the benefits of registration even though in 50% of cases the shareware didn’t actually reverse.

We also get quite a few (sometimes nasty) E-Mails from people who complain that we are treating them as dishonest, but if the figures here say anything they seem to imply that, given the opportunity, over 80% of people are. I find that incredibly sad and I really do wish that shareware worked on trust but the reality is it doesn’t. Just think - I could spend my time doing what I love, producing well crafted productive code, instead of trying to figure out ways of stopping people stealing my software. Ah well.

Bottom line in my view is that if you release a piece of shareware without a mechanism to enforce closure of the sale in some way or another you are likely to cost yourself a lot of money. Others will tell you different, and whose advice you take must be your own decision. But be sure you know what the commercial interests are of anyone who advises you differently - they may well be more interested in making money from the distribution channel than from authoring shareware.

###

[Colin Messitt is the President of Oakley Data Services, the company that produces the “Smart Range” of software. He is a frequent contributor to STAR’s CompuServe Section in the UKSHARE Forum.]

Webmaster’s note: This is an archive of the original spring 1995 STARgazer article, a publication of the Shareware Trade Association and Resources (STAR). This was retrieved from archive.org when all other links seemed to be broken.