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