How would I implement a "self-destruct" feature into the free trial version of my software?

Question

There is the ongoing argument of free trial versus a freemium model (that is, a free-for-life version of their software with restricted and/or stripped down features) for allowing potential customers and users to test run their product. Upon my research, I can conclude that the free trial is the way to go on both for the benefit of the user experience of the individual using the software and for the benefit of the vendor in both aspect of sales and maximizing usage. There are many factors for a free trial software that can greatly maximize user usage like the length of the free trial.

One keyword that reoccurs on my research for "freemium" is "frustrating". Many individuals chose to uninstall the software instead of having to use a piece of software where some features were unavailable to them. At the same time, these users never had the chance to use the "paid" features. Unbeknownst to them, and hidden by the very own vendors who are selling the software, they don't know and cannot know what benefits the Pro features will bring. Without first having to use them, a user will not know they have the feeling of "needing" something. Which brings me onto my next point of a free trial model.

Some opinions of a free trial user is "I cannot imagine using this software without the Pro features." This goes back to the point of "the user not knowing they need something until they first understanding the feeling of have." Those that have had 14 days to use a the "full" version features said they cannot imagine not having or using the features provided there. So when fourteen days were over, they were more likely to dish out money than someone who's never experienced the full features. The length of the free trial is also an important factor is creating a lasting impression on users. In an experiment conducted by Visual Website Optimizer, they noticed that for a 14 day free trial versus a 30 day free trial, while the number of sign ups and installs were the same, the usage for the 14 day trial increased 102%. This, of course, in turn increased their revenue as well.

Another very important point to mention is that "offering a useful and fully functional free version of the product" is VERY IMPORTANT. Fully functional free trials are effective in getting media coverage, and this publicity for new software and/or software vendors are fairly crucial.

One other relevant aspect is the importance for users to give feedback. Consider, in the fully functional time-limited free trial, the ability for users to give feedback.

One other feature important for our software is the need for telemetric data, that is, quantitative and comprehensive data on how a user uses our software. Some of usage statistics may fall into a legal grey area, as laws are different depending on the location in the United States, and the world. One way to combat this legal issue is to have an opt-in feature for gathering anonymous usage statistics. An opt-in feature would mean giving the user an option to turn off statistics gathering and at the same time, the user must be very well aware of what the gathering of anonymous usage information does. It is important to make it CLEAR to the user what data will be collected, what "we" will be doing with it, and make it easy to turn off any time, including allowing them to change their mind for turning it on or off. For more detailed statistics, like tracking individual activities of users, it could lead to legal issues. The Eclipse IDE logs detailed usage statistics, but it does it by the full consent of the user. We may have to potentially prepare a consent form with our legal team.

The Eclipse Usage Information Collection collects this information: 1. Plug-ins that are started by the system. 2. Commands accessed via the keyboard shortcuts and actions invoked via menus or toolbars. 3. When the "view" of the editor is given focus. 4. System information like the version of the software being used, the operating system being used. 5. Description of internal errors.

Kill Switch

A kill switch for our software can be managed logging the initial data, encrypting it with a salt, and whenever it's an invalid date, that is, the user tried to change it, it would disable the software. Another option is to have internet authentication on install, log that date to a central web database, and check the date every time the application is opened.

On disabling the software, we can delete vital DLLs. The option of having to pay to generate a report cannot be considered.

---

I am interested in implementing a free trial version to my existing software. I plan on having the trial last 14 days. Upon the 14th day, my software would prompt the user to either pay for the paid version, or have the consequence of not being able to use it. The free trial version is entirely unlocked, meaning all paid features are there.

However, my dilemma is about the "best" way to implement what to do for an end-of-trial solution. Do I delete vital DLLs? Have a user authentication system upon installation or use? Encrypt the initial time and date of use with a salt, and if it's an invalid date (AKA they try to change their initial date), disable the software?

I am interested in knowing what are some effective measures of disabling software.

Answer 1

There are two issues here - one is a programming problem, and one is a business problem. For the second one, asking programmers about business analysis is about as good advice as you can get from your local bus driver; which is to say it may be good, or terrible, but you aren't asking experts so assign no inherent weight to any of it. (As an aside, one of my bus drivers often gives me good ideas.)

But as for a programming problem, the downside is that it seems most people don't like the idea to start with. There's lots of good reasons for this, but they aren't really important here. Sadly, we are also in some ways a terrible group of people to ask, because by virtue of our position and knowledge most of us are pretty darn good at pirating software to the point that we think it pointless to try to implement trial measures at all!

The fact is, your core issue is a business analysis and sales experiment problem, and there is no answer save from getting to know your customers and experimentation. It doesn't sound like you already have a big pool of customers to talk with about their product sales pipeline and how you can implement trial software to improve it, so one must understand that we are now in a position of stabbing blindly in the dark. The first step to working in a dark room is know you are in one!

So, start somewhere. The goal is not the right answer, because I can only 100% guarantee one thing - you aren't going to start with the right answer. But start we must.

Give Your Customers a KISS

Also, "keep it simple, stupid." Or, from a programming methodology, "try the simplest thing that could possibly work." Then go from there.

So, when installing get a date. Store it. Get your data on installs and usage, and bask in the warmth that data analysis can bring. Disable whatever part of the software you want when the trial expires - I suggest if (trial_expired()). Then adjust.

First of all, get good data. Are you expecting to provide updates in the future for your software? Then if someone tries to beat v1.0, don't worry about it.

The easiest thing is uninstall the software, then reinstall it. New trial period (because your software deleted that old date). Do you care? If v1.0 is soon to be updated, then I strongly suggest you get a way to find out if this happens - but don't try to stop them (yet). It's like people who take 2 mints instead of 1 - it's just a mint, let it go. They probably weren't going to pay you for it (yet), anyway.

How? Well, in Windows this was usually done by shoving random orphaned keys in the registry and weirdly named files in various common installation directories. Your installer would explicitly pretend they didn't exist and just leave them there. The level of computer sophistication this requires to defeat is vastly more than uninstalling.

But if you don't try to stop someone from reinstalling, then you get data you are going to need. They aren't robbing your store, here - they are giving you a valuable opportunity to study a potential customer. Use it to tailor your marketing, software help prompts, email campaigns, 'special offers'. I'd try detecting the event and then, a day later, sending them a key they could enter into the program to extend their trial until next month. You might find a method that turns them into paying customers, or not; no way of knowing ahead of time!

This seems trivial, but lets face it - do you really need anything more than that? If you are collecting data, that's worth money to you. You'll probably want to spend time on making sure emails are good, designing in-software messaging that you can update to guide new users (invisible sales pitches, really), rewriting your app blurb, hammering out bugs that would prevent any sane person from buying your software in the first place, etc.

But the key here is you are communicating honestly and clearly to all potential customers - if you want this, you should pay us. Just because you are being (invisibly) magnanimous doesn't mean this is freeware - you are just going to be smart about it and not drive away customers because they haven't sealed the deal in the first two weeks.

If you think about it, these people are coming in to your store to really look over your product. They are taking a test drive, yet it costs you (nearly) nothing. No successful store got that way by driving out customers who weren't yet ready to buy! Yet we all know if you can get something for free, forever, why pay? So use the best of both worlds.

With each step you take you will be working a filter, and if your software is good you WILL be making conversions with every step. My simple suggestion:

1) 14 day free trial

2) Extend the free trial, no questions asked

3) Offer to extend the free trial again, if they'd be so kind to fill out a short form that communicates to you their opinions of your software so far.

4) Are you sure these people who are still actually using your software won't consider buying it? Find a way to entice them - or at least try to squeeze more info out of them on what you could do to get others to buy. Maybe allow them to 'request' an extension through a form, which your sales staff will kindly grant regardless and then use the info to see if they can deal with any objections they might have to buying your software.

What if this user is evaluating it for use in their entire department? If the budget meeting is next month, do you really want them to be unable to use the software until then?

5) Maybe you cut them off now...and maybe you invite them for a special offer a week later at a discount. Maybe not. Maybe you offer to extend to give a final extension.

These people don't owe you money, so treat them as potential future customers - not thieves, freeloaders, or people who need to pay their bill or get their service turned off. Everyone hates bill collectors, so don't act like one.

Programmatically, let's face it - this isn't actually hard. Use orphaned files to keep track of dates. If you have to have a valid account like through iTunes, this tracking is way easier. If it isn't required, then I would generally suggest you not require it for a first install - never turn people away from the first version because they don't want to fill out a stupid form. People hate forms! And they don't know your software, so why 'pay' to fill out a form if they don't even know if your app works?

On step 2, I'd get a signup/email to extend. Again, programming it is trivial.

3) After 30 days I'd probably require some kind of 'phone home' behavior. If people are going to crack that - like they do - congratu-friggin-lations! You must be getting pretty popular. But don't worry, if this isn't a video game people probably don't care enough to bother, so just change your code in the next version and make them go back to the drawing board.

TL;DR;

#1 Don't solve a problem you don't really have (you aren't Adobe, yet - DRM can be simple and effective if you don't over-think it). #2 Don't ask a programmer when you need to ask a marketer, business analyst, or salesman. #3 Treat your customers as people who might give you a living, not as people who owe you money, and especially not as thieves. #4 DRM is really, really, easy. Just don't think you are going to stop people from using your software who will almost certainly never, ever, ever give you money...at least, not today.

• I have bought software I've pirated, years later. So don't piss off future customers needlessly, either.

Answer 2

You're looking for something that's essentially impossible. Some of the biggest, best-funded companies in the software industry have spent years, and millions upon millions of dollars, looking for a way to accomplish what you're trying to do, and it's never once actually produced successful results.

First off, you can forget all about screwing up a local install. As long as the original installer still exists, (or can be backed up, or re-downloaded,) that's nothing more than a speed bump. Even placing something somewhere in system settings means very little when the user can install to a VM and then back up and restore the entire VM image.

The next obvious step is online authentication: set up a server and have the program "call home" each time it's started to check credentials. This doesn't work either. First, you run into obvious (and highly frustrating) problem of false negatives when the server is down or unreachable for any reason, or has some glitch in its software. And you can't make the software just validate the user automatically if it can't reach the server, or it's trivial to work around the authentication with a few networking tricks, or just by using it on a machine with the wi-fi turned off. (And of course, this means that people trying to legitimately use it with a good reason for not having a wi-fi connection, such as bringing their laptop along with them on the bus, will be locked out. That won't make anyone like your program.)

The other problem with online authentication is that in the end, it boils down to a boolean somewhere in your code. Somewhere it calls AuthenticateUser() and if it returns True, the user is in, and if it returns False, they're locked out. And no matter what you do to encrypt, obfuscate or hide the code, in the end it boils down to the simple fact that if a computer can read it at some point, so can a programmer. Someone, somewhere, is going to produce a crack where AuthenticateUser always returns True, and they'll put it up on the Web.

The fundamental problem of cryptography can be described as "Alice wants to send a letter to Bob, without Charlie being able to read it even if it were to fall into his hands." The problem with what you want is that Bob and Charlie are the same person, which makes your goal impossible.

If you want to make money from your software, twisting your users' arms is not the answer. What will work, the only thing that does consistently work these days, is basic market theory: offer a product that the user perceives as having a greater value to him than the price you're asking for it, and he will be willing to pay. Anything else will just be a waste of time and effort on your part.

Answer 3

Just my 2¢.

100% reliable self-destruction is impossible. There will always be a sophisticated way to crack your protection.

What you can do is to make using or cracking an expired trial more hassle than buying a full version for your target market.

If I were in your shoes, I'd try to ensure that my software is: (1) popular, so everyone interested at least tried it, and (2) reasonably priced, so those willing to pay can buy it, and you turn a profit. The rest of users can play with expired trials to their hearts' content: they'd not buy it anyway, but they do help popularity, and provide more potential hires for companies that actually buy your software.

I suppose that the target market for a Revit plugin consists of architects, building contractors, designers, all people handling relatively large amounts of money per contract, and no excess of free time or low-level computer expertise.

So make sure that your expired trial version sufficiently annoys them without actually breaking anything (or they'll hate you). People who need work done will eventually cave in and pay the [reasonable] price.

A few ideas:

• Make a trial version quickly (and cleanly) uninstall itself on expiration. Reinstallation should be possible, so that users see their work intact, followed by another automatic uninstallation shortly afterwards.
• Let output of an expired version include a mark or text saying "Made with an EXPIRED TRIAL version of [your software]". A serious user would not show such output to a customer. (And if he does, again, he's too cheap to pay for your software anyway).
• Make an expired trial version show message boxes at random moments, warning that the trial has expired and giving a link to the full version. Such things break the flow of work enough to make an upgrade worthwhile for a serious user.

Any combination of usual tricks can be applied to mark a computer as having an expired trial: cryptic registry keys, cryptic files at random locations (don't forget to restore the timestamp if you modify them), hiding timestamps in unrelated graphic files or other forms of steganography, etc.

Of course if the user e.g. reinstalls the OS, he'll get a free trial period again. Never mind: a serious customer will hardly resort to that. Of course this scheme will eventually be cracked; be sure that your software is popular enough by then that you can offer an upgrade with compelling features and a different protection scheme.

As one example of very successful "inconvenience-ware" I'd pick Balsamiq Mockups. You can use their software for free (on the web), with some features limited, including saving your work. The work can be "exported" and "imported" back with some hassle. That is, any high-school student that wants to play with the free almost-fully-functional version can do so, and even can have some work done. The student won't buy it anyway. But a serious designer that values their time and convenience will buy it.

As another very successful example I'd of course take MS Windows.

Answer 4

It's not difficult to do. It really depends on how much effort you want to put into it.

Remember, the purpose of a trial version is to increase sales. All trial version schemes for installable software can theoretically be gotten around by some means, even if it involves tremendous effort, since the code is executed locally and can thus be edited with a hex editor. This answer is working from the assumption that the original poster is asking about practical solutions to this business problem, not theoreticals.

As one of the other posters mentioned, the point is to make sure the effort involved in getting around the trial version scheme exceeds the cost in terms of time and effort than the cost of buying the software. Dedicated 'pirates' will simply download pre-cracked versions of your software using BitTorrent. Don't worry about them, as they wouldn't be customers anyway. The approaches below have been taken by countless software companies for decades, and as long as you are not crippled by the notion that such systems must be theoretically perfect, you will find they work quite well out in the real world.

At the simplest level, you could simply keep a start date/end date time 'window' in the registry (encrypted). Each time the program runs, you check that the system time is between those two dates, and update the 'start' component of that date. That prevents the casual user from simply setting the clock back to allow access to the trial version.

You can extend this by keeping track of that time window in several locations (both in the registry and in your application's data folder), and making sure they match on each start up. That prevents people from monkeying around with the entries - they have to know exactly where they are and how to unencrypt/encrypt the data.

There's a number of other ways to tighten things down as well, which I'm sure you'd encounter as you start developing the trial functionality.

If you don't want to do all this yourself, there are quite a few third-party libraries that provide this sort of functionality.

Note regarding actually deleting files: If you're application tries to delete files, it may get flagged as malware by the user's anti-virus software. Anti-virus software is very aggressive these days. And many end users will be convinced there is a virus in your software if their anti-virus program pops up an alert.

Answer 5

It depends on how hard you want to make it for your potential customers to circumvent that self-disabling features (sounds better than "self-destruct"). Assumed your potential customers won't try to manipulate the program code itself (which some of them will try, trust me), you have the following options:

• store the initial date time somewhere (hidden) on the computer where your software is installed: this has the drawback that your customers can easily circumvent it, for example, by installing your program in a virtual machine, and deinstalling it after the trial period by resetting the VM to its original state

• make sure each downloaded copy of your program has an individual hard-encoded download time somewhere hidden in the programs binary code. This will need a lot more administrative effort from you, and you still cannot be sure that the same person does not download a new copy of the program from your server after the trial period (perhaps, using a different identity)

• deliver the trial version only with a "dongle" where the end of the trial period is stored. This will be only feasible for programs with a handful of potential customers and a price far higher than the price of the dongle.

• make the thing a web app, or parts of it, or just a web-connected app. In this case, you could store the initial date on your server, but you will have to identify and distinguish the people who are using your software (for example, by setting cookies or creating a log-in). But again, you cannot be 100% percent sure that the people don't change their identity.

Answer 6

Whatever you do, make sure you test what happens beyond the expiration date very carefully. I once worked for a company which distributed software with a trial scheme much like the one you describe. The difference was that the expiration was a fixed date in the future.

We dropped the scheme immediately after we got a ton of calls from angry customers when their legitimately purchased versions also stopped working on that date.