shareware

Shareware was initially devised in the early 1980's*, and for much of that decade had a growing, dedicated following who distributed programs through mail order and BBSs. It was a strictly defined means of distributing and supporting software, that required an element of trust. Shareware was specifically not crippleware, freeware, demoware or limited in any way, bar the mediocrity of the author. Which wasn't to say that all shareware was bad - some of it easily outshone commercial products.

I remember for several years there was a catalogue called The Shareware Book (distributed by a company called Shareware Marketing) that sold many shareware programs, all with meticulously detailed payment methods, on floppy disks. There were shareware programs covering every possible aspect of PC usage: office software, databases, drawing packages, utilities, clip art and fonts, and of course games.

The games section began to grow in the early 1990's as companies such as Softdisk, Apogee, and Epic Megagames began to slowly but surely work towards challenging the commercial PC games sector (notably the many Commander Keen and Duke Nukem episodes, and eventually culminating in Quake, Id Software's last shareware release).

Shareware is still the preferred means of distribution for a lot of popular utility programs, notably those with elements that require a license of some kind, such as WinZip. However, most publishers have abandoned the term - games are back in the hands of big publishers, who release comparatively stingy demos, and much of the other stuff that would once have been shareware is now freeware (sometimes backed by big investors, such as AOL's patronage of Winamp), open source, or adware (such as Napster).

Most of the garage software developers now use the internet as their means of publicity, and there are some large repositories such as tucows and download.com that serve the same purpose that the Shareware Book once did. There were many notable shareware programs from the 'golden age' of about 1985-1992, more than I can easily list here, but I will make an endeavour to node some of those that I still remember (or indeed use) today.

As an aside, my dad was very keen on shareware, and my family still owns vast quantities of shareware programs on floppy and CD. He once made a rather unsuccessful effort to start a shareware distribution company. I like shareware, as although "Open Source all the way" is more ideologically sound, there's something cool about getting small cash donations from satisfied users.

*The Shareware Book claims that the shareware idea was first used in 1982 by Jim Button's ButtonWare (PC-FILE) and Andrew Fluegelman (PC-TALK).

Share and enjoy! = S = sharing violation

shareware /sheir'weir/ n.

A kind of freeware (sense 1) for which the author requests some payment, usually in the accompanying documentation files or in an announcement made by the software itself. Such payment may or may not buy additional support or functionality. See also careware, charityware, crippleware, FRS, guiltware, postcardware, and -ware; compare payware.

--The Jargon File version 4.3.1, ed. ESR, autonoded by rescdsk.

Scott Miller of Apogee invented the concept of only releasing 1 episode of a game as shareware, which thus advertises the full version of the game. The first game released using this concept, which also became known as the Apogee model, was Kingdom of Kroz from 1987. Scott Miller also helped found Shareware Trade Association and Resources (STAR) in 1992.

So, you want to write shareware eh? Tempted by the prospect of easy money? The opportunities are there, but you might want to consider some of the following tips.

Why shareware?

I'm assuming that you are deciding between shareware and some sort of commercial distribution, and that you would like to make some money. Shareware definitely has a lot going for it:

• All the money (minus the fees charged by whoever processes your payments) goes to you. If you sell your program to another company, you may only get 10-15%.
• Flexibility: you get to set your own deadlines, work the hours you want, the way you want.
• Total control: only you decide what features go into your software.
• Low setup costs: it costs you next to nothing to publish your software, your only initial costs will be your hardware/software and maybe some hosting space.

All is of course not rosy. A bigger company may have more resources, such as teams of testers, experienced staff, dedicated technical support staff and a respected brand name. Of course you need to get this hypothetical company to listen to you.

Yet another option is to release your software for free or under some sort of GPL-type license, but to charge users for support. Obviously this won't work if your program is a very simple one. Many companies make money from Linux this way. You can also charge users for extra conveniences, such as a printed manual.

It is possible to make money from shareware, I've done it. I've also released shareware that has made very little money. It isn't a MAKE $10000 A WEEK WORKING ONLY HALF AN HOUR IT REALLY WORKS!!!!

I'm going to make a very big assumption: You have the programming skills and the ideas to write a good product, which users will be willing to pay for. I assume that you know about things like writing maintainable code, that you the market you are targeting. Without all this you can still get lucky, but it certainly helps.

Design phase tips

Test widely

It isn't enough to test your software on one machine only. Mistakes are cheap to fix at this stage, so take advantage of it. If you have several machines you may get away without using any external testing, but you may still not have the variety of hardware and software configurations. Even the buggiest of software may run fine on your computer. If people already know about your program it is often not too difficult to get users to test newer versions. You may want to consider free "public beta" versions.

Think of your users

You may think your application is incredibly intuitive, but it's easy to forget that this may be because you have designed it from the ground up and spent hour after hour debugging it.

Listen to your users

Users often have valuable ideas and input. After all they use your program. It often helps to have the opinion of someone who isn't involved so closely in the project

It's not over yet

Maybe one of the easiest mistakes to make is to think that your work ends here, that once you have written and debugged the last line of code (if there is indeed such a thing) it's time to sit back and wait for the money to roll in. It's not.

Document your program

If people can't use your program, or don't think it doesn't have feature X, they may give up on it. It's really quite maddening to have users ask for features that are already there or to see something you spent days on unused. If the platform you are using has some sort of standard help system, use it: help is easier to find if it's where people are expecting to find it.

Tell people about your program

If nobody knows about your program, nobody will use it, even less pay for it. There are many websites out there that list software, submit your program to them. Tell news sites relevant to your platform about your program. All this you can do for free, if you start making money there are other options. Many websites will give your program more exposure if you can pay, and of course there is regular advertising.

Listen to your users

You've already heard this one before, but it's worth saying again. When a user has a problem, respond quickly. If they haven't paid that doesn't mean their question or suggestion is less important (of course you must keep users that have paid happy too). Don't forget that some of them don't have the technical expertise you have. Handle them gently. Be patient. I once spent several hours trying to solve a user's problem only to eventually realise that they had confused the application's icon and the folder icon, which is why my application "wasn't launching".

Crippling your software

This is a bit of a thorny issue, with many people feeling quite strongly about this, arguing that crippleware isn't shareware. Cripple your software too badly and users won't get to appreciate your product. On the other hand gently reminding users that your software isn't free can be a good idea. It's a delicate balance to find.
A common system is a free trial period, after which only a limited feature set is available. While this can work well, you need to bear in mind that what you want to avoid is users not being able to try your program.

I like to think that there are users that are basically honest, who will pay for your software if they like it and that you should try not to overly inconvenience these people because of those who will never pay. At the end of the day, it's up to you to decide.

Protecting your software

There is no such thing as uncrackable software. With a bit of effort people will be able to extend your trial period indefinitely, unlock features that only paying users are supposed to access etc. You can make things difficult for them but time dealing with these issues is time not spent on improving your product. As always it's a question of compromise. For example if you decide you want a serial number mechanism you could use a fairly simple checksumming type method or you might use public key cryptography. This is fairly safe, you can for example encrypt the user's name with your private key to create a code, to validate the code, you decrypt it with your public key. This makes it quite difficult for someone to generate fake codes (they will have to break your encryption), but can make it more inconvenient for users. If you use 768 bit RSA, then the code your users will have to enter will be 768 bits long.

In the end, the best tip I can give for writing shareware is to think carefully about everything you do. Sometimes of course you just have to be in the right place at the right time, and that's mainly luck!

Sources:
Personal experience