To Limit, or Not To Limit

(Edit: Hello, Slashdotters. Thanks for coming. Please don’t mind the mud, the Diggers yesterday were a rowdy bunch. 🙂 I kid, I kid.  The conversation I refer to in my first paragraph, which ranged over many topics in a monster-thread, began here.)

Recently I (foolishly) allowed myself to be drawn into a conversation about software piracy on Slashdot, where I said something to the effect of “My software has the least restrictive registration scheme I could devise, just enough to keep honest men honest”. This is not very popular at Slashdot, where the consensus is that you should put up a Paypal button and ask for donations and if you’re worthy you’ll make even more money.

This is, well, complete and utter rubbish. If you intend to make money by selling software, you need to limit your trial version. The only question is how. If you’ve got altruistic motives, if don’t like charging money, you can do whatever you want.

In the days of yore when shareware was a bright new idea on the scene and the ASP had an ironclad “no crippling” policy, Colin Messitt performed a brilliant experiment. He took a utility which had just written and had it secretly flip a coin on first installation: it would either function in unrestricted mode without being registered (and have two nag screens for donations) or it would be feature-limited (and have two nag screens offering the upgrade). When orders came in, Colin was able to track whether the order had been generated by the limited or unlimited version of his software. Keep in mind that this is a perfect experimental design: there is a control group which is guaranteed to be indistinguishable from the experimental group, and nobody but yourself knows whats going on.

Anyhow, to make a long story short, the limited version outsold the unlimited one. Five to one. Colin calculates that the experiment cost him $17,000 in sales versus having 100% of the installations be limited. Crickey.

Lets look at another example: Movable Type. Its a wonderful program and powers thousands of blogs across the Internet, including some of the biggest names out there. Movable Type was once donationware. Do you know how much the average donation was for? Note: average donation, not donation per user. Of all the people who thought Movable Type was worth paying real honest-to-God money for, the average donation was… 38 cents.

So if you’re going to limit your software, would you rather limit it based on features or based on elapsed time? I have a feeling this is highly specific to the actual software you have designed. For example, Bingo Card Creator gets used in many classroom once or twice a month. A full-features trial for 30-days is out of the question — “Oh, I only used that twice, why should I pay $25”? And I was worried that teachers would use Bingo Card Creator like they do many teaching supplies — fire it up, print up one master copy of all the included lessons (30 cards for each subject they need), and then just store those against need later in the year (and they can then just photocopy the cards and keep the master copy around for next time).

So here was my plan: I provide cards for free on my website and Bingo Card Creator will happily spit out cards for you, but there is no way to get enough cards to teach an entire classroom on anything. After you print out 15 copies for any particular word list you’re gently disallowed from printing more, told the reason, and if you attempt to circumvent the block you’ll find you keep getting the same 15 cards no matter what you do.

You can see, after Bingo Card Creator prints out 15 cards, that they will work for your classroom (or you can see that they won’t — I think its important that folks know exactly what they’re getting into). But you can’t teach class without 10 more cards, and those 10 cards cost you $24.95. And after you’ve made the leap saying “Well, I really want to play bingo on next Tuesday” you can justify it by saying “And hey, I can play bingo another 5 times this year and if I do this is really, really cheap”. (Making a set of bingo cards takes an hour, buying a set for class costs $10-15.)

The reason I can limit my software like this is because I know enough about my target market to know what feature I can disable which will keep the software attractive but render it very close to useless. For software which appeals to more people, this can be rather difficult. What feature would you knock out of Direct Access, for example? I’m at a loss — you could disable, say, autotext but many people don’t need autotext, and the folks who do need it would likely not use the rest of your program without it. So Direct Access is a timed trial — and, if you’ll pardon me tooting someone else’s horn, its absolutely brilliant at it. You see, if you’re the kind of person who really needs Direct Access, after you’ve used it for a week you can’t. Live. Without. It. If I didn’t have Direct Access installed on my computer it would hurt my productivity as much as losing my tab key. So when you run into that 30 day limit and the convinience you have been relying on for 3+ weeks just shuts down, you whip out the credit card. Plus there is an investment in using Direct Access, in that you’ve configured everything so its exactly to your liking, and if you had to investigate one of his competitors or Launchy (OSS with a similar feature set) you’d have to go through all the configuration again.

(P.S. Full disclosure: I bought Direct Access, at a discount to other Joel on Software readers he was offering, approximately 72 hours after installing it. The author doesn’t pay me to flog it and my opinions are totally my own. That being said, I love it love it love it.)

Edit: A few minor English improvements and more in-depth explanation of my “crippling” scheme. This got hit by a couple hundred people and I was embarassed about, e.g., spelling the man’s name “Colon” at one point.

Explore posts in the same categories: Uncategorized