How Not to Promote Your Software
As part of the work I do for Developer Central, I look at a lot
of software products. Sometimes, sadly, the look doesn't get far enough to turn
into a review. You see, for the most part I look at new products the same way
that you might: by downloading and running trial versions of the software. Sure,
there are times when I'll get in touch with the marketing people and request a
review copy, or when they'll get in touch with me and send one. But I still
spend a lot of time cruising around the Internet, looking for new and exciting
products. Along the way, I've run across some corporate behaviors that I find
pretty frustrating. Here are five things that annoy me when trying out new
Don't have an evaluation version at all. Some companies don't make
evaluation versions available for download under any circumstances. In such
cases, how am I as a consumer supposed to decide whether the product is any
good? If the product costs enough that they can afford to fly out a salesman and
a laptop to do a demo, this might be justified, but the average product needs to
be available to potential buyers over the net. There are so many licensing
software choices now that you needn't really worry about your code being stolen
if you make a time-limited trial version available.
Tie the timeout date to the download date. I tend to download things
when I run across them, which may not be when I have the time to test them. More
than once I've run a setup program only to discover that the application has
already timed out. Timeout dates should be tied to installation dates.
Don't forcefeed me the libraries. I already have .NET and Java
runtimes installed on a whole batch of test machines. I don't have unlimited
bandwidth. It's nice to provide a link to the appropriate download sites, and
let me know which versions your software requires, but don't make me waste time
downloading stuff that I don't need.
Don't work in a VM. With the widespread acceptance and availability of
VirtualPC and VMware, the easiest way to test new software is to throw it into a
virtual machine. This has the benefit of not making me mess up one of my "real"
computers, and also lets me roll back changes to a baseline quickly. Despite
this, I still run across software that won't function in a VM. If there's a good
reason why yours won't (such as video incompatibility), make sure to document
this prominently so I don't waste time trying.
Don't provide documentation. Time and again I download and install
software only to discover that the documentation is sketchy or lacking entirely.
If you're making software available for people to evaluate, this is just silly.
If anything, evaluators need more documentation than continuing users.
Tutorials and samples are great tools to sell your software. Don't run out of
steam before creating them.
Fortunately, the majority of software I download to evaluate doesn't make
these mistakes. That means I've still got plenty to write about, even after
throwing out the packages that annoy me or actively interfere with evaluation. I
feel sorry for their manufacturers, but I'd feel even sorrier for developers if
I recommended putting up with this sort of experience.
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.