views:

1423

answers:

5

I'm developing a shareware desktop application. I'm to the point where I need to implement the trial-use/activation code. How do you approach something like this? I have my own ideas, but I want to see what the stackoverflow community thinks.

I'm developing with C++/Qt. The intended platform is Windows/Mac/Linux.

Thanks for your advice!

+3  A: 

Whatever you do, keep a keen eye on the system date. The oldest trick in the book is to install an application at some point in the future and then return to the real date once the application stored the silly date on first run. Maybe synchronise the key with a online repository ?

Konrad
A: 

If you are [fairly] likely to have a network connection, you can have the installer register with your website, then check against it every time it starts.

If that's not feasible, writing a value into a world-modifiable point on the filesystem (a registry entry, entry in and /etc conf file, etc) may be workable.

warren
Be careful about this. Users are very wary of programs that "phone home" -- they have no way of knowing what it's sending back, it could be their credit card numbers and banking passwords for all they know.
Head Geek
+10  A: 

What to protect against and what not to protect against:

Keep in mind that people will always find a way to get around your trial period. So you want to make it annoying for the person to have to get around your trial period, but it doesn't matter if it's impossible to get around you trial period.

Most people will think it's too much work to try and get around your trial period if there is even a simple mechanism. For example people can always use filemon/regmon to see which files and registry entries change upon installing your software.

That being said, a simple mechanism is best, because it wastes less of your time.

Here are some ideas:

  • You can do a tick count somewhere in registry for every unique day that is run. If tick count > 30 then show them an expired message.
  • You can store the install date, but take head to check if they have more days available than your trial is supposed to be, then do tell them they are expired. This will protect against people changing their date before installing to a future day.
  • I would recommend to make your uninstall, remove your "days running" count. This is because people may re-evaluate your product months later and eventually buy. But if they can't evaluate it, they won't buy. No serious user would have time to uninstall/re-install just to gain extra use of your product.

Extending trials:

For us, when a customer requests a trial extension, we send them an automated email that contains a program "TrialExtend.exe" and a trial extend code. This program contacts our server with the trial extend code to validate it. If the code is validated, their trial period is reset.

Brian R. Bondy
+1  A: 

Brian's answer's great, but I'd like to add something.

Linux users generally aren't used to paying for software, and they tend to be more tech-savvy and possibly even "religious" on open-source issues.

For that reason, I'd really recommend keeping it simple - it's really just a small barrier to make buying the software at least as easy as stealing it.

I'd suggest that it nags or disables certain features (eg saving) after the trial period rather than dying completely. Just an observation, but feature-based restrictions seem more common in the linux world.

As an aside, making the linux version a "first class" version - decent installer etc will help.

If you're relatively small, or your program's relatively niche, there's a pretty small chance anyone will bother to crack it - so just concentrate on making a good product with a straight forward niggle once the time's up.

Draemon
A: 

Perhaps the real problem is the Time-limited trial. The company I work for does a lot of Active Directory work and we usually limit our software to a small amount of users for trial versions. I feel that limiting functionality in some way is sometimes better, easier to implement, and doesn't fail when the user simply changes the date on their computer.
There is balancing act in that you can't limit functionality too strictly, otherwise users get nothing out of the trial. At the same time, a limit that is too loose gives no incentive to purchase.