The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Time limits on software


I have a product thats nearing completion (end of jan release) and I am currently working on the license key and time limit side of the program. Most of it is done, but I wanted to ask what people think the best way of enforcing the time limit is, eg after 30days I want the program to deactivate, but what ways can I use to stop them getting around the time limit, eg rolling clocks back etc.

Do people tend to use the registry or hide files on the hd somewhere. Naturally I want it to be as tamper proof as possible without messing with the user too much.

Thanks for any help.

Steve Haunts Send private email
Monday, December 12, 2005
I don't like time limits because it may not give may a chance to use something. Another priority comes up and then by the time I get back to your software it's too late.
son of parnas
Monday, December 12, 2005
You don't need to hide anything. You can encrypt your release and security keys and just store them as base64 text in an INI file. If you find that the key is missing, just stop functioning. As far as clock rollback, I think the common solution is to store the date last updated as part of the security key.
MBJ Send private email
Monday, December 12, 2005
I was comtemplating how to go about this. Either use a time limit or reduce functionality for the demo, but I don't like the idea of turning features off as people can't test them.

What other options are there that are prooven to work for evaluation software. Obviously I want the user to buy the software if they like it, so I guess something is needed? What do all you other isv's do?

Steve Haunts Send private email
Monday, December 12, 2005
Tamper proof is not possible, and above some level, the cost & complexity of better protection goes up exponentially.

Hackers can and will disable your mechanism, if the software is any good.

I would suggest you implement a simple, "keep honest people honest" scheme on one hand (e.g., just watch the time since install, no specific handling of clock rollbacks or anything). On the other hand, make it worthwhile for people to register by providing on-line updates that allow you to track illegal usage if you so desire.

Shrinkwrap software is a tough business even when it's download only. "Service" style software is easier to build a paying clientelle with, in general.
Ori Berger Send private email
Monday, December 12, 2005
Personally, I would balk at the notion of disabling any product features after the expiration of a certain time period. Everyone's evaluation time will be different, and you never know how long it will take someone to get around to purchasing the product.

Take, for example, TextPad. I've used it for years. Six years ago, when I first started out as a web developer, I used it to edit HTML. And I still use it for all kinds of text-file tasks.

It took me several years to get around to buying a license, but I eventually did.

If they locked me out of the software at 30 days, I would have just uninstalled it and found a different editor.

Persoanlly, I think nag-screens are the way to go. Keep reminding the user that they're leeching. But don't ever force them to uninstall your software and choose the software of one of your less-restrictive competitors.
BenjiSmith Send private email
Monday, December 12, 2005
Winzip has a fairly nice nag setup.  (I didn't install it at work and I don't see this at home...)  After the 30 day trial, it shows the number of days installed and the number of archives you've opened, and it does a count-up to both numbers on the splash screen.  The longer it's unlicensed, the longer it takes to get past the splash.  I'm about ready to drop my own 29 bucks to make them leave me alone <g>.
a former big-fiver Send private email
Monday, December 12, 2005
How about instead of limiting the trial based on date, limit it on use? Keep a counter of how often or how long the user has been using the product and stop after a set amount, like 30 uses or 40 hours of use.
Former COBOL Programmer
Monday, December 12, 2005
For my monitoring product, I opted to have a 30-day limit on the trial, with a relatively small but noticable nag on the reports.  After 30 days, the product stops storing data and user accounts are inaccessible.  But, people can keep using it by either emailing a request for an extension license, buy a license (when I get that part working, anyway), or go through the setup steps and lose all the collected data.
Stephen Cote Send private email
Monday, December 12, 2005
The goal is to maximize sales of your product.  So the question is, what trial scheme helps you achieve this goal? 

In most cases, I have to agree that time limiting trials can hurt sales.  You want your software to be used/evaluated as much as possible and if it stops working after X days, the chances of a sale after that time is very, very low.  Why not use a trial system that provides unlimited use of all the features but limits a critical aspect of the final output. 

Some examples: 
A video capture program that creates a watermark on the captured video, or allows you to capture only 5 minutes of video at a time.  Image editing software that creates a watermark on the exported image.  An accounting package that allows only 50 journal entries to be posted to the General Ledger.  A help desk application that only allows you to create and work with 10 tickets at a time.

You get the idea, but the point is that what you limit should be domain specific.  Then you can add some nag screens/notifications in the appropriate spots once the limits have been met. 

This method offers lots of benefits:
- You don't have to worry about people cracking your reg keys
- No need for a complicated trial scheme
- User benefits by being to use all the features for as long as they want (or until they can't stand the limit you impose) –> hopefully, leading to more sales
Carmen Ferrara Send private email
Monday, December 12, 2005
Increasingly long delays is my favourite way. It encourages you to buy without locking you out.

Hmm. If my product ends up having a demo version I might do that on a number of key features: Report download commencing in T-30 seconds. Please purchase full licence for instant reporting, login, saves, etc..

hmm. Yes. I like this idea.
Monday, December 12, 2005
I think crippleware only works if you have a very-significantly-unique product. If you have any competition in the marketplace, the moment your software's performance starts degrading (watermarked output, significant delays, disabled features, etc), the prospective buyer will just uninstall your software and install the trial version of your competitor's software (which might not be crippleware).

Then, six months down the road, when your lazy and forgetful prospective customer finally makes a buying decision, he'll choose the piece of software that he has the most experience with: the one that has been sitting (uncrippled) on his desktop for the last six months.

You want *your* software to be the software he's using when he finally makes that buying decision (whenever that might be), or when his guilt finally induces him to cough up the $20 licensing fee.
BenjiSmith Send private email
Monday, December 12, 2005
Benji -
I'm not advocating "crippleware".  I'm simply saying that your software should provide all the features AND provide some useful output, just in a limited fashion (maybe the watermark example was a bad one).  A better example is Joel's Citydesk - he offers a "Free" version that allows you to create a website that can contain up to 50 files.  His goal is to entice you to upgrade to a paid version once you realize you can't really do much with 50 files.  I think this same concept can be applied to a trial scheme. 

I agree, you want your software to be the software being used when the customer is truly ready to buy.  If your software provides some level of utility and hasn't expired - then you'll have a better chance of a sale, over a competitor using "crippleware" or 30 day expiration trials.
Carmen Ferrara Send private email
Monday, December 12, 2005
Wow thanks people, there have been some really good suggestions here that have made me rethink my strategy. I'm going to re-engineer my security code to go for the nag screen option when the trial times out. And also due to the nature of the product I can potentially put in an output limit to the data in a similar fasion to CityDesk, so the program will still be very usefull to a point. Although I'm going to have a think about this first before I implement it.

When the site is finished I'll post it here for you to take a look :-)

Again thanks for your input.

Steve Haunts Send private email
Tuesday, December 13, 2005
Ideally, I think you would like to "lock in" the potential customer before you start nagging him. This could happen because he is used to your interface, or because he has invested a certain amount of work in your software and would lose it if he switches to a competitor (proprietary data formats spring to mind).

On an other note, any "simple" protection will be *very* quickly cracked if/when you software becomes popular. So I would start with a trivial protection until it is cracked - which is a sign of success - and only then really start to worry.
Tuesday, December 13, 2005

Why don't you make this product a freeware, or open..
If it is a good product you will find that a lot of people will use it and ask you for maintenance or who knows to develop some more features - which eventually will give you the money you planned to earn...
Just a thought..
scarmi Send private email
Saturday, December 17, 2005
Yeah, scarmi, great idea!!!
Saturday, December 17, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz