The Do's and Don'ts of Shareware, Part 2
by Sanford Selznick10/08/2002
Last 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.
Kicking Off the Shareware Life Cycle
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.
Writing the Software
|
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! |
Release Schedule
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.
