The Do's and Don'ts of Shareware, Part 2Last time we were together we introduced a few ideas about shareware: what shareware is, expected startup costs, developing an idea, and sales strategy.
Now we will discuss some basic approaches for writing maintainable code, testing software, assembling a deliverable package, writing ReadMe files, and marketing and distributing your software.
In a previous installment we learned about the shareware life cycle. We learned how each new release results in increased public awareness of the software. And we learned how increased public awareness generates more sales. So there's a key element of the shareware life cycle: each new release. The more releases you make, the more public awareness your software will receive, and ultimately, the more sales you'll have. To this end, shareware developers should create long term strategies for releasing their software at reasonable intervals to keep the cycle going.
A large company that creates software has the advantage of dozens of programmers, testers, and marketers. A one-person shareware company has no such luxuries. To the rescue, there's an old engineering adage that says "keep it simple, stupid." But stupid is somewhat deprecating, so this author prefers the equally effective: "keep it simple, silly" (KISS). And it works for shareware.
|
DO remember that each new release will spawn renewed interest in your product. DO listen to your users. DON'T overcomplicate your 1.0 release. It may bomb, and you don't want to waste too much time on it. |
A good long-term strategy for developing a shareware product is to keep the first 1.0 release as simple as possible. Only implement the basic functionality of the software that is necessary to provide a minimal set of features to the user. Consider MoonMenu, one of this author's shareware titles. The 1.0 release did little more than calculate the phase of the moon for any given date and display the moon in the menubar, along with four relatively simple calculations. From there, features were added slowly to grow the software, adding only one or two new features for each release.
There are a number of advantages to growing shareware slowly:
|
Related Articles:
The Do's and Don'ts of Shareware, Part 3
The Do's and Don'ts of Shareware, Part 1 |
A small 1.0 release means a small code base that developers can focus on and fine tune for future growth.
Less code and fewer features translates to less complexity and fewer bugs.
A shareware author will know immediately if a product is worth the effort. If the 1.0 version of a product fails miserably, chances are 1.1 or 2.0 will fail too. Because you kept the 1.0 release simple, you didn't waste too much time on too many features.
You can let your users decide the direction for future releases. After all, who knows better what they want. It's the perfect marketing tool and a perfect symbiotic relationship. Your users will get the features they want, the shareware author will know what features users want, and everybody's happy. So we need to repeat this again: Listen to your users.
You don't waste your effort on features users don't really want.
|
DO keep your code clean. DO remember that although some operating systems have a greater share of the market, this doesn't necessarily mean greater sales too. DO listen to your users. DON'T rely on other programmers to test your software. |
There are scores of excellent books available that detail many great mechanisms for reusing code, testing software, using revision control systems, and more. Buy them. Read them. Unfortunately this article is not a venue for this type of discussion. Below, however, is a really quick list of things to keep in mind as you author your shareware program.
Keep your code clean.
Leverage the facilities of your programming language to allow you to reuse code wherever possible.
Do your best to adhere to as many standards as possible to help ensure that your software will be compatible with future versions of the host operating system.
When choosing a target operating system, remember that a larger market doesn't always generate more sales. There are so many more titles for Windows than Macintosh that it may be difficult for a small company to compete. Because of this, many Macintosh shareware titles actually do better than their Windows counterparts.
If your software requires collaboration of third parties, be sure you get everything you need up front. Miscommunications can delay or even cancel products.
All of the code you put into the 1.0 release will be the foundation for all future releases. So any time spent on better design will help streamline future efforts.
To fine tune your software, watch a friend or relative use it for the first time. This friend should have minimal information about how to use the software. If the user is lost, your new users will be too. Listen to all concerns and make changes to your software wherever necessary. Try not to ask people who write software for a living to test your software (unless your software is a development tool. :-) And again we repeat: Listen to your users.
Make sure all of your error dialogs are descriptive. A message like "Error #-37" will just frustrate your users and increase your support load.
|
Get your first 14 days free when you subscribe to Safari Tech Books Online, with 600 of the best technical books available from O'Reilly and other top publishers. Select up to ten books to search, bookmark, and annotate. Cut and paste code examples. Find your answers fast. Sign up today! |
How many releases should a shareware author plan on making? There's no formula to determine this, only considerations, such as your ability and your market. Naturally, you can't release updates to your software any faster than you can write and test them. Other limitations include the patience of your users and the public press venues. Although most users and public press venues will gladly accept notifications of updates to shareware products, users and the press do have a limit. General consensus is more than one press release each month can push that limit. If necessary, one emergency update in the middle of the month is considered acceptable. You may consider not sending out notifications of small changes or fixes to not upset customers and the press. Once relationships are broken they can be very difficult to rebuild.
Press releases are discussed in greater detail later in this article.
|
There are a number of approaches to finding good testers. Some shareware authors will release expiring beta versions of their software to the public. Some shareware authors will rely on friends and family.
Whatever you do, try to test every possible execution path through your code on as many system configurations as possible.
|
DO test every facet of your software on as many system configurations as possible. DO be sure your software exits gracefully if the minimum system requirements are not available. DON'T forget to spell check your user interface elements. |
As a shareware author, you're not working in a vacuum. The best testers for any piece of software are the users themselves. A lot of users are really savvy. Some users know how to use low-level debuggers, and some know how to interpret log files. These are the testers who need to be rewarded the most. Offer to add the tester's names to a product's box, or give the testers a free copy of the software.
There are also third party companies that test software and charge by the hour. If you're having quality control issues, the folks at MacTester can help. MacTester has lots of system configurations available, and their rates are very reasonable. The reports they generate are very thorough, too.
This will be on the checklist at the end of this series, but it can't hurt to mention it twice: if your development or beta versions have expiration code in them, remember to remove the expiration code before you ship the final version.
And one other item: please remember to spell check your user interface elements.
|
DO choose a package format that's compatible with users' systems to keep your support expenses to a bare minimum. DO write an installer to keep your users happy. DON'T forget that money is not the only expense. Your time is an expense, too. |
So you came up with an idea, wrote the software, and tested the software as thoroughly as possible. Now you must assemble the package that your users will eventually download.
What format do you want people to use to download your software? There are a number of options, all of which have their pros and cons. There's no perfect distribution mechanism. Three popular formats are discussed below.
Disk Images. These are really cool, especially on MacOS X. But new users to Mac OS don't really know what they are, or how to use them. If you do distribute disk images, be sure your Web server knows how to deliver them correctly. Also keep in mind that not all disk images work on all versions of MacOS. Testing is very important here.
Installers. Delivering an installer is a really great idea. They are easy to use, easy to create, and they make users really happy. Users will be even happier if your installer does not require them to restart their computers after installation and also comes with an uninstaller. The incredible folks at Mindvision, Aladdin, and Zero G all offer free installer licenses to small shareware developers.
Stuffit Archives. Over the last decade, Stuffit archives have become the defacto standard for distributing Macintosh software on the Internet. So much of a standard has Stuffit become that Apple includes Stuffit Expander with MacOS X. Most users have encountered Stuffit archives and are familiar with what they are. Many developers distribute Stuffit archives that contain installers. This combination is probably the most common and the one that creates the fewest headaches for users and, therefore, the fewest headaches for the developer.
|
Related Reading Macintosh Troubleshooting Pocket Guide for Mac OS |
An important note about Stuffit: There was a time when every available Internet-capable program installed Stuffit Expander on the user's computer. Some of these versions are completely incompatible with archives created by the latest release of Stuffit. And here's the worst part: the operating system doesn't always launch the latest version when the user double-clicks the archive. Be sure to keep this in mind when providing support to your users. (But even with this problem, Stuffit is still a very popular and easy to support format.) There are more notes about Stuffit and server MIME types below.
The distribution archive should also include a ReadMe file. (See next section.)
|
A great place to learn about ReadMe files is to read some. No kidding. You'll find all sorts of variety, from one-liners to entire rolls of toilet paper. Some never end. (This article may never end.)
Here are some sections users will like to see in a ReadMe file:
|
DO format your readme file so users can easily find the information they're looking for. |
Keep in mind that MacOS X TextEdit.app can open SimpleText read-only files (type 'ttro') without having to launch Classic.
Another great format for ReadMe files is html. The problem with this on MacOS 9 or before is the user may not have the browser installed for the creator of the html readme. So the user can double-click the file and get an error. On MacOS X, since creators are not necessary, this is not a problem.
You may consider hosting your documentation on your Web site. Making last-minute corrections is impossible when your documentation is already installed on a user's machine. Also, many users like their documentation in printable form. For this, PDF is ideal.
Marketing is always fun. The best part about it is that you can turn for marketing to the same place that you turn to for cheap car insurance, competing mortgage companies, and Foam Bath Fish Time: the Internet.
Don't panic. There's no rule that says your Web site needs to have 50 cross-referenced pages, or animated gifs of cartoon characters using your software (although that would be pretty cool, wouldn't it?). The basic idea of creating a Web site from scratch is the same idea as creating a 1.0 release of a piece of shareware: keep it simple, silly. A Web site, like a piece of software, can evolve as new needs arise, and can change very quickly in response to user feedback. Think of it as a piece of clay that never hardens. If you don't get it right initially, you can always mold it into something better later.
Another good reason to keep the Web site simple at first is that you won't have extraneous information users won't want. Only add sections or information users ask for. Only then will your Web site do what it's supposed to: help your users find things quickly so they can get on with their lives.
Below are four basic sections users will expect to see on a shareware Web site:
Beyond these three sections, what you add is up to you. As a shareware developer, if you receive a lot of emails asking about who you are, add an "about" section. Don't be shy. Your Web site should evolve similarly in response to frequent user feedback on any given issue.
As you design your Web site, be sure links are visible and in obvious places. Users can't read your mind. (No, they really can't.)
There's no one right way to do a Web site just as there's no one way to design a storefront. Drive around your neighborhood and you'll see hundreds of unique storefronts competing for your business. There are no limits to what you can do with your Web site.
|
DO remember that there's no one perfect way to format your Web site. The overall look and feel of your site will depend mostly upon your own tastes. DO shop around. There are some great examples of Web sites out there. DON'T clutter your Web site with extraneous information. |
Use as many tools as possible to help you manage your Web site. Relative links are a pain to get right, but tools like Bare Bone's BBEdit software make it easy. Same goes for importing common elements into your entire site with one click of a button. The tools are available so you might as well use them and save yourself the headache.
If you're not very good with graphics, find a local artist to help you out. A local artist usually costs between $20 and $60 per hour, and if you're completely devoid of any artistic talent (like most people), you might want to give outsourcing a try.
Small screen shots of your software in action will also quickly and easily help potential users understand what the software does. Sometimes a picture is worth a thousand words. (We don't have a whole lot of original sayings here.)
You'll want some pretty serious power from your ISP. There are thousands of ISPs out there, all with many features. Most decent Web hosting ISPs cost anywhere between $15 and $45 per month, and sometimes charge a set-up fee. Here are some features you will want from your ISP:
A good track record. Find one that a friend recommends.
FTP access to your domain's home directory so you can upload your Web site easily.
Perl scripting with sendmail. This is really important if you want to create a Web form and be emailed the results.
Multiple email addresses with forwarding or one email address with lots of aliases. Create separate email addresses for press releases, support, and sales. That way you'll be able to filter incoming messages for better organization.
An ISP that's willing to configure MIME types. When a server sends a Stuffit archive to a user's browser, the server sends along a MIME type. There are specific MIME types for specific types of Macintosh files, and these are not always enabled by default.
Relatively high disk space. A typical shareware company's Web site may fill up to 50 MB of disk space. When calculating necessary size, don't forget to consider the sizes of archives, localized versions of those same archives, and graphics. Also remember that no one person will ever download all of it. So disk space isn't necessarily proportional to the time required for your pages to load.
Backups, Uninterruptable Power Supplies (in case of brown outs), and redundant links to the Internet.
If you're planning on doing a lot of scripting, you might want an ISP that can handle PHP and MySQL.
A good and friendly ISP is Pulver Technologies. Their uptime is excellent, and they repair inevitable problems quickly. Although once you sign up, Pulver Technologies is pretty much self serve.
|
DO create a Web form to collect customer's email addresses so they can learn about new products and updates. DO create a Web form as a way for your users to change their address in your database. DO remember that simple Web form back ends will email you the data field values in a special format. This is typically called a "formmail cgi", and is supported by most ISPs. DON'T violate your user's privacy. |
It's quite surprising how many users want to be kept informed about new products and updates. Provide a simple Web form to collect this information. It's free, easy, and gives you a list of people who actually want to learn about your goods.
A great marketing tool is to find out from users how they heard about you. Then you know where your users are going for information, and you can be sure to send future press releases to those who made the referrals.(But only if they want it, right?)
The idea of Web forms brings us to our next quick topic: privacy. Don't sell your mailing lists or give them away. You'll only upset your users. Plus, you'd be surprised to learn how many users use custom email addresses so they know who they've given their address to. Because of this, if their particular email address is ever used for spam, they'll be able to track it back to you. And that's not a good thing.
So write a privacy statement, and forget about ever giving away any personal information. This policy is better for everybody.
Below are a few notes on actually distributing your software.
Offer two or more mirror locations from which users can download your software. We are, after all, dealing with the Internet here. Servers fail. And so do links.
Remember that users need to download your archives. It's a good idea to make sure your archives aren't larger than an average user can download from a dial-up ISP in 20 minutes. Large archives are often skipped by users entirely.
|
DO keep registration numbers short. DO only use digits. DO only use one bit in your registration code for binary fields. DO be careful of unicode characters on foreign systems. They'll appear in fields whether you know it or not. DO be sure you can write your registration code in languages other than C or C++. DON'T forget to test your code. |
When shareware is actually sold, what's transferred from the company to the user is a registration number. This is usually done by email only. Using a predefined mechanism, the users enter the registration numbers into their software thereby extending the software's lifetime indefinitely. Registration numbers can be generated on-the-fly by the company handling your sales. (See next installment.) But from a programmatic point of view, there are a number of values shareware developers may want to mathematically incorporate into their registration scheme:
There are a number of hidden gotchas here. Don't forget that on foreign language systems, usernames and organizations may be unicode. Also, avoiding letters in the supplied registration code altogether will reduce the number of support emails. Users are easily confused, and rightly so, by lower case "L" characters, upper case "i" characters, and the number one. Same holds true for zero. Using only digits nips this problem at the bud.
Ambrosia Software's 'fprefect' wrote an excellent article detailing an expiring registration number scheme.
We covered a lot of ground today. The general idea behind creation of the software, the Web site, and the entire sales experience is to keep it simple. Lone developers have no choice. Don't feel overwhelmed. Most of the items are completely optional. And many of the items are personal preference.
Next time we'll be wrapping up the series with a discussion of press release format, sales transactions, user support, a checklist for launch, a few notes about localization, and what you need to work from the road.
Sanford Selznick is the owner of Selznick Scientific Software, LLC, a programming, consulting, and shareware company based in Tucson, Arizona.
Read more Developing for Mac OS X columns.
Return to the Mac DevCenter.
Copyright © 2007 O'Reilly Media, Inc.
