Selling Upgrades to Increase Profits
Every sales professional knows it’s much easier to sell to an existing customer than to find a new one. Some clever businesses even go so far as to track the “lifetime value” of a customer, understanding that the worth of a customer–over time–is usually much greater than the initial sale. The software business is no different: most successful companies make more revenue from selling upgrades to existing customers than they do from bringing in new customers. A further benefit is it’s usually less expensive to sell to an existing customer than it is to find a new one, increasing profits.
Any software upgrade should have three goals:
- Protect upgrades against unauthorized copying
- Make it easy for the customer to upgrade
- Make it easy for the ISV to publish the upgrade.
Fortunately, CodeMeter makes all three simple. And a new feature just released makes it so simple to protect upgrades. You’ll wonder how you lived without it. Read on:
Protecting Upgrades
Although CodeMeter is easy to update in the field, many dongles from our competitors are not. Vendors who protect an initial version of their application with non-updateable dongles have a difficult choice when it’s time for the next release: either ship a new dongle to protect the upgrade or release unprotected software. Both choices have costs: either you buy more dongles or you risk piracy.
The good news is that CodeMeter provides several methods for field updates. For just a handful of upgrades per year, file exchange is the easiest way to go. For larger volumes, License Central is the best choice.
In order to update a license for a CodeMeter CmStick or CodeMeterAct, you need a context file (from the CodeMeter Control Center) which can be updated and reloaded on the customer’s computer. You could publish directions to your users on using the CodeMeter Control Center to create a context file, provide an email address to send it to, update the file, and email it back to them with instructions on how to install it.
Whew! Sounds like a lot of work. For low-volume publishers, this is perhaps a feasible process, but not for ISVs with thousands of customers.
You can simplify the process by using the Wibu Core API to have your application create the context file and send it (via automatic email or TCP/IP) to a server which can perform the update and return the file. This would require you to write a lot of code, including some kind of license server. This makes it easier for your users but more work for your developers.
Enter License Central
In 2008, Wibu-Systems released License Central Internet Edition to automate this process. License Central provides a license generation and management tool that is fully compatible with CodeMeter along with web services interfaces using SOAP and XML. This makes it simple to connect to your application as well as your ERP system and e-commerce web sites. A properly designed implementation of License Central should make it effortless for your customers to manage their upgrade process. You can have an “Upgrade Now!” button in the application which takes them to an e-commerce web site where they can purchase the newest version, then via License Central the new license is generated and installed in the background. Normally a complete process like this would require writing and testing a lot of code but with License Central Internet Edition you can be up and running in a few days with very little code necessary.
Downgrade Rights
For the sake of argument, let’s assume you are at Version 5 of your product and you’re about to release Version 6. One of the decisions you need to make is if you want to allow customers who upgrade the right to continue to use all prior versions, or if you want to restrict the versions that can run in some fashion. Regardless, you can use the Feature Code to manage this.
When you protect your software with AxProtector, you must define a Product Code and also a Feature Code for each version. Feature Codes are stored in a 32-bit Feature Map, where each bit can represent some feature. You can use some of these Feature Codes to track versions. Here’s how:
| Version | Featured Code | Binary View |
|---|---|---|
| 1 | 1 | [00000001] |
| 2 | 2 | [00000010] |
| 3 | 4 | [00000100] |
| 4 | 8 | [00001000] |
| 5 | 16 | [00010000] |
| 6 | 32 | [00100000] |
The 32-bit Feature Map allows you to define up to 32 major versions. For example (see illustration), suppose we want to sell version 6 with the downgrade right to version 4 and 5. All we need to do is to set the Feature Map in the license to decimal 56 (8 + 16 + 32), or in binary 00111000. CodeMeter’s protection process (via either automatic encryption with AxProtector or via API calls), uses the Firm Code, Product Code, and this Feature Code (of this version) for encryption. On startup, your software searches for a license with this Feature Code. If the Feature Code is included in the Feature Map, the license is valid and can be used.
Now the customer has a single license, which can be used for version 6 or version 5 or version 4. If you think of network licenses this scheme also works well. If you sell 10 licenses the customer can use any combination up to 10 licenses. For example, eight copies of Version 6, two copies of Version 5, and no copies of Version 4, would work under this licensing scheme.
Introducing Maintenance Periods
One of the most exciting features we’ve added to CodeMeter in years is the Maintenance Period (available in firmware version 1.18). Many ISVs who sell to larger enterprises also sell maintenance agreements, where for a fixed fee all users get support, bug fixes, and any software releases, including upgrades, during the contractual period (usually a year). Before the introduction of the Maintenance Period, it could be a lot of work to keep track of which users had a maintenance agreement and ship them software, since each upgrade could require an update, which in turn required a context file.
Maintenance Period simplifies this dramatically. When you protect your software you specify a “release date”, then when you create the license you set a Maintenance Period. At a minimum the Maintenance Period requires an expiration date; optionally it can include a starting date as well.
Suppose your company signs a contract for 1000 copies of your product along with a maintenance agreement from Jan. 1, 2011, to Dec. 31, 2011 with a customer. So you create for them a license that specifies a Maintenance Period with expiration date of Dec. 31, 2011. Now further suppose that on March 15 you release a new version of your product, protected with AxProtector and with the Release Date set to March 15, 2011. Some customers will have to pay for the upgrade, so they need a new license. But your customer with the maintenance agreement? When they get the new executable, it will just run with no need for license updates, because the Release Date is within the Maintenance Period in the license.
If your company does another upgrade with a Release Date of, say, Feb. 1, 2012, your maintenance customer will need a new license for it to run, since it’s beyond the Maintenance Period. However, the licenses within the valid Maintenance Period will still run forever unless you set a Usage Period for the license separate from the Maintenance Period.
In those cases where, for business reasons, you want to restrict the use of older versions, you can set a start date, as well as an end date, in the Maintenance Period. No software with a Release Date earlier than the start date in the Maintenance Period will run under that license.
Finding new ways to deliver more value to existing customers is a guaranteed ticket to greater sales and profits. Using software upgrades may just be the way for you to do it.
KEYnote 21 – Edition Spring 2011