This section discusses a couple of issues related to presenting your Company on the Internet.
Here is a truth of the net:
Once something is distributed to the net it will never truly disappear.When you release version 0.9 beta 7 of Snack Maker you can guarantee that it will still be around in ten years time. So will the Read Me file which told people to send a postcard to your home address. Which is unfortunate, because when Snack Maker 12.2 comes out and everyone is using Snack Maker you can guarantee that at least half of the people using it will manage to get hold of that old address you moved away from ten years ago and send you a postcard...
So, if you are serious about distributing shareware, make sure you abstract and date any information you distribute. For instance, all contact details:
...should be written in such a way that you can move house, change your service provider and lose your job and still remain valid. Get a Post Office Box, register a domain name for your company, put your web site as www.your.domain.name and have all your mail go to mail.your.domain.name. Later when you have a your web site with a professional service provider and your mail server in your office you will be glad you abstracted.
Actually the easiest way to abstract your business from fixed E-Mail and Postal addresses is to register with Kagi. Kagi handle all your financial transactions and also give you a permanent fixed E-Mail address. Kagi will also give you 5 Mb of FTP and Web space at an additional charge of 2% of the sales of your products. (And when you are starting up that is an excellent deal, later you can swap to a different service provider.)
Plus they take the lowest percentage of any of the registration services that I have seen. Handling your own financial transactions is a bad idea: it is expensive to handle small numbers of registrations, and difficult to handle lots of registrations. And when you are handling moderate amounts of registrations you will rapidly regret the amount of time it takes you.
Go to Kagi and let them handle it. Really, it is worth it.
Some of your sales and some of your support will be covered by your Web site. I think a good web site pays off. However one incidental benefit of the web site is that it is also an excellent personal reference. We use our web site to answer support questions. Our web site has extensive Frequently Asked Questions lists and all the documentation neatly hyperlinked which makes it a little quicker and easier to find the right answer.
It takes a lot of work to ship software successfully. Much of it seems irrelevant to the core business of writing software, but should not be ignored: from the users perspective it is the difference between a useful piece of software they understand and use and a an interesting but obscure piece of software that they will pass over. This section covers some of the boring details of shipping software. It is very Mac centred.
You need to register the creator code for your applications. You can do this at Apple's Devworld web site:
http://devworld.apple.com/dev/cftype/main.html
You can check whether that creator code is used, and the web site will give you some quick feed back telling you whether it should be OK or not. Note that you have not truly registered the creator code until you receive confirmation via E-Mail (although it is unlikely you won't get the creator code if the web site feedback says it is OK). Keep the confirmation E-Mail- that way you won't lose track of what you have registered. Apple's Creator code database (deliberately) doesn't tell who 'owns' which creator codes, so if you forget you've registered the code already there is no way you can confirm whether it is you or not...
You do not need to register File Types or Resource types.
Don't dismiss overseas markets. The majority of your market may be English speaking but the non-English market can be more profitable because many programmers don't provide foreign language versions of their software.
You don't have to translate your software yourself, but make sure that someone else can. Put all displayed text in the resource fork where foreign language translators can get access to it without your help. STR# resources are your friend.
Shareware is a commercial software. Users will expect any software they receive to come with Software and Documentation. Also, if appropriate, example files, explanatory notes, release notes, Quick Start and Registration information.
Even if your program is totally self explanatory it should come with a Read Me file which explains what the program does, who wrote it, how much it costs, when this version was written and where users can go for more information. Tonya Engst wrote a couple of articles in TidBits on how to write excellent ReadMe's: they are extremely sensible and informative. Read them now. Write wonderful ReadMe's and they will earn you money.
Documentation is a time saver. The better the documentation you write, the fewer questions you will have to answer. The more professional the documentation the more software you will sell. Don't skimp. If you don't write good English find someone who does. This isn't always practical or possible, but later, when you are beginning to make some money consider getting someone to edit the documentation. As the author of the software you need to reread the documentation to make sure it is still technically correct, but let others point out where you are being unclear or confusing.
The master documentation for our software is on our Web site. As people read the web site they point out spelling mistakes, query points which are not clear and generally critique the documentation. By constantly updating the documentation using these suggestions we end up with much more polished and complete manuals.
We have also found a good Frequently Asked Questions list to be useful. People often don't read the manual, but they seem less reluctant to read Frequently Asked Questions. That intercepts a few more questions before they ever get to you and also gives you a check list for improving your software and your documentation. If you can fix the software and make one of the questions go away that is best, but if not you can always roll the question into your documentation (or possibly just make the answer more prominent in your documentation).
The worst mistake you can make is releasing buggy software. Big companies may get away with it because they have their technical support and programmers separated, but you won't. If you software has problems you will spend disproportionately long periods of time answering the (difficult) question: what is wrong? We made that mistake and it plagued us for the better part of a year.
The best way to not release buggy software is to not write buggy software. Read Writing Solid Code by Steve Maguire, get the attitude, and you will write more code, with fewer bugs.
Even with a good attitude you need to test your software on a variety of platforms, with a variety of users: beta testers. Getting beta testers doesn't seem to be difficult, although I have no idea why people would want to check out software which could potentially damage their machine, takes up their time and is probably quite broken. But they do, and often in droves.
We maintain a Beta testers mailing list to which we mail beta copies of our software. The E-Mail goes out with an explanatory note of changes to the current version (so the testers know where to look for problems) and an attachment which is the compressed archive of the software. Make it clear what doesn't work and what you want tested.
Don't send the program out until you are reasonably happy that its working well. You don't want to spend your time answering obvious questions. Test it with a small set of known good beta testers before starting the full beta cycle. A small group of competent beta testers can weed out 80% of the bugs you haven't picked up, and they'll be able to give you specific descriptions of the problem which makes it much easier for you to replicate and fix the bug.
We don't normally mail out a full distribution until we have what might be considered a final candidate. At that point we try to include documentation, so that the manuals can also be beta tested. (Documentation is inevitably written later in the software development cycle.)
All Beta versions of our software have an expiry period. The expiry period ranges from (roughly) two to five months. If the software is early in the beta test cycle the expiry period is long. As the software gets closer to a final release the expiry period shortens. Software expiry is a two stage process involving about a month's worth of warnings before the software simply alerts you that it has expired and refuses to work.
Beta versions are released via E-Mail rather than FTP to discourage casual usage of non-final products. If the software were put on a FTP site it would be distributed globally and irrevocably. You don't want that. You don't want your reputation smeared by incomplete work. Also, mailing out large archives tends to discourage people from just loitering on the test list. You really only want people who are going to test the software.
Finally, beta software doesn't escape beta testing until all outstanding issues have been dealt with. Often that involves a lot of technical support, teaching people how to use your software, fixing their badly set up machines and fruitless discussion. In the end though you may actually pick up some bugs before the software is released, which will more than make up for the time and hassle you spent during beta testing.
Remember once you've entered Beta testing you should be in a feature freeze. You are not adding new features through out beta testing, you are trying to make sure the current features function correctly. That will inevitably involve some changes and additions to the program, but try and stay focused on stability and correctness.
We use a three digit version system. The change in the first digit indicates a major functional enhancement, a change in the second digit indicates significant feature changes or major bug fixes and a change in the third digit indicates minor bug fixes and corrections. This is also followed by dN where N is a number during beta testing to indicate the development version of the software.
So 4.0.1d4 indicates the development version 4 of version 4.0.1 of the software, which is a minor fix to version 4.0 of the software. (If the final digit of the version number is a zero, we drop it from the version number. So PulpBeater v17.6.0 is called PulpBeater v17.6.)
On our FTP site the version number is included in the name so you get NetPresenz-41.sit.bin and ObiWan-502.sit.bin. Thus the user can rapidly check whether they have the latest version by visiting your FTP site.
These version numbers apply to the whole archive- if there is flaw in the documentation bad enough that you think it needs to be corrected the version number should be incremented, even if the application hasn't changed. Much as I find it frustrating not to be able to just fix up that little mistake this does prevent the inevitable confusion of 'I've got NetPresenz-41.sit, but which version have I got?'.
There are a number of excellent FTP site for Macintosh software which you should distribute your Shareware through: in particular the Info-Mac and UMich FTP sites are mirrored around the world, well maintained and well documented. (When you mail MacGifts your archive is automatically submitted to the Info-Mac and UMich moderators.)
However, your software expires from these sites and you don't have much control over the software once it is there. You really need a site where you can put the latest version of your software. This usually means getting an Internet Service Provider to host FTP services for you.
Be careful that your ISP doesn't charge you on the number of downloads of your software. Given the low registration rate for most shareware you can rapidly lose money if you aren't very successful and lose money even faster if you are. If you product gets exposure from places like MacInTouch you can expect tens of thousands of hits, which can add up to hundreds or thousands of dollars.
Luckily your FTP site can be anywhere on the Internet, it doesn't need to be geographically local. Look around. We use Seagull and they seem to provide good service. We pay about US$150 a month for 120M of FTP and Web space, unlimited hits, mail, domain name hosting services and more.
That may be too much when you are starting out, so look around. Beg and borrow space on FTP servers, pay for domain hosting and redirect to the server. Make friends with people at well connected University sites.
(Remember Kagi's deal, discussed earlier in the section entitled 'Kagi is your Friend', which 5Mb of FTP and Web Space for an additional 2% of received moneys. An excellent deal when you are starting up.)
If you are in the US you may already have a network connection to home at ISDN speeds. That should be enough to host your own FTP site if your machines stay up and connected around the clock.
Here is a brief checklist which you should go over before distributing your software. You'll expand this list as you go- this is a shortened version of our posting checklist. Our list is about three times this length and covers details specific to our setup.
All our archives are distributed in Stuffit (.sit) format. We have a master FTP site on our local machines which is mirrored to a couple of different machines in the US. The Stuffit archive are automatically MacBinary encoded as they are uploaded to our mirror sites, so typically our software is distributed as software.sit.bin.