carpeaqua

Usually one of the last things I do before shipping a major product release is add in some sort of registration system. It is an unfortunate, yet necessary evil that adds nothing to the user experience, but helps keep honest users honest.

I never implement registration systems thinking they will be immune to crackers and others who are destined to find a way to not pay for my software. Instead, I opt to make a system that is the least amount of work for the user, as well as the least amount of maintenance effort for myself.

Today 1.0 and Check Off 4 both make use of the AquaticPrime framework. AquaticPrime uses RSA encryption and generates license files. I liked it because it was dead simple to setup on my end, but the concept of a license file has proved to be a support nightmare for anyone that is not a well versed computer user. The fact is people expect serial numbers and when you email them a file with a strange extension on it, they aren’t really sure what to do.¹ Cocoa Boutique aims to make the usage of AquaticPrime less painful for the end user by hiding the license file process from the user, but it currently requires using Paypal as your payment processor.

With Today 2.0 I opted to implement a traditional serial number system similar to what you’d find on the back of a shrink wrapped disc. The support load in terms of registration issues for Today has dropped significantly, but I still run into a few users a week who have issues with typing in their serial number due to not being able to differentiate between O and 0 or I and l. Telling the user they can just copy and paste the serial from their email into Today solves the issue, but it’s still frustrating that this is one of the first experiences the user has right after paying for my product.

This all has gotten me thinking about why we are still using things like license files or arbitrary strings of letters and numbers as the way of verifying a user has purchased our software. It seems like there should be a better identifier for a user to validate their software purchase.

This is what I had in mind:

1. User purchases a copy of Product X from the Second Gear store.
2. Upon successful purchase, the user can then enter their email address into a registration dialog.
3. The app will ping home, validate that the user has indeed purchased the software, and mark it as registered.

A single network transaction to validate the user. No per-seat licenses or periodic phoning home a la Adobe or Microsoft. The idea behind this is that a user’s email address is easier to remember and type rather than a string of random characters and numbers.

I chirped up on Twitter about this and got quite a few responses that I wanted to highlight and respond to.

Justin Pennington writes:

@justin I agree but think the reason is because of having to keep that server side process up forever in order for the app to work.

It’s honestly not that much work I wouldn’t think. A PHP script that takes an email address plus a product identifier and returns a pass/fail status is minimal effort both in terms of development and maintenance.

The forever aspect of software is not something I really take too seriously. There is very little software that I was using five years ago that I’m still using today. I’ve purchased upgrades or just found a better workflow. If need be, you could offer unlocked copies of previous releases to users who request them, or if you plan to go out of business or discontinue the product, offer an unlocked copy somewhere.

Alastair Houghton of Coriolis tweets:

@justin That’s what we do here; it causes far fewer problems and very few people mind the minor inconvenience of initial activation

I recently reinstalled iPartition on my Mac mini, and the process Coriolis has in place is seamless. I honestly can’t remember how it worked, which is a testament to how easy it is for honest, paid users. Coriolis goes a step further by having user accounts that are tied to each purchase. It’s a bit more work on the server side, but it seems to be working well for them.

Daniel Jalkut chimes in:

@justin Serial numbers are simple and allow customers to activate their own purchased software at any time under their own control.

This is actually the biggest reason I have against the idea of using an email address or order number as the system for registration.

Patrick Burleson and Steve Streza says something similar:

@justin My guess would be that email addresses are easy to guess. If someone knows I own a product and knows my email: free registration.

My initial response to this was that it’s just as easy for someone to pass around the user’s serial number, but this could be afford a larger uptick in blind piracy. If I knew that Patrick had a copy of FancyApp 1.0, I could download the trial, test out his email address and possibly have a free copy.

The workaround for this could be to replace the email address with the Order # as the identifier, but I’m not sure how much of an upgrade that is versus serial numbers as the possibility of mistyping still exists. Not to mention that order numbers are tied to your purchasing system, which may be a problem longer term.

Nick Peelman brings up the enterprise angle:

Please please please remember some form of enterprise activation… no matter how insignificant you think your app is in enterprise, help out the guys running a managed environment :)

This is something I hadn’t considered, and a valid point. I’m honestly not sure of a good way to handle this without adding a ton of infrastructure work on my end for a small use case.

I am honestly not sure if there is a better system than the traditional serial, but it’s certainly something to ponder.