Becoming A Shareware
Author Part II
Contents
A Few Notes on Business
This section discusses a couple of issues related to presenting your Company on the
Internet.
Abstract Early
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:
- Snail Mail address
- Domain Name
- E-Mail address
- Web site
...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.
Kagi is your Friend
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.
The Web is Also your Friend
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.
Shipping Software Successfully
It takes a lot of work to ship software succesfully. 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.
Registering Creator Codes
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.
Think Globally, Act Umm...
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.
Documentation
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).
Managing Beta Releases
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.
Version Notes
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?'.
Distributing Your Software
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 moenys. 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.
A Shipping Checklist
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.
- Check you've registered the Creator Code
- Check version numbers of the application in the vers resource and in the documentation
- Compress the archive (DropStuff)
- FTP the release to any 'private' FTP sites
- Write release notes
- Mail to MacGifts & foreign language translators. Check attachment! Check it is .sit
- Mail to your Announcement mailing list
- Mail to your Press Contacts list
- Post to appropriate news groups
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.
|
