3 Steps To Creating Shareware
In the development of any shareware product, there are three phases the developer (or developers) must pass through. All are essential to a successful product, and each is skimped on only with great peril:
1. Learning the Skills
To write a good computer program, you need to, of course, be able to program. Well, it needs to be a skill you're very comfortable with. You don't necessarily need to be able to program the machine you intend to write the program for (that can be learned from books), but you need to be fairly familiar with the programming process itself. (If you know how to program already, skip ahead a few paragraphs)
If you know nothing about computer programming, this is not an insurmountable obstacle. It is, however, a very large barrier. You can teach yourself how to program. In other words, you'll have to go out and teach yourself a whole new trade. It will take quite a bit of time and study, plenty of hours practicing and figuring out bugs, and buckets of patience. Fortunately, it's not impossible. I taught myself to program. I know a lot of people who taught themselves to program. It's tough, but it can be a lot of fun too.
To create computer programs, you need to go to a reasonably large computer store and buy a program, such as Borland Turbo C++, or Microsoft Visual C++, or Codewarrior (for Mac or Windows). These are called development environments (or sometimes compilers): computer programs which enable you to make other computer programs.
Once you have the program, you need to learn how to use it. Go to the computing section of a large bookstore (the local Waldenbooks won't be enough) and look for books on the language and environment you've chosen (or buy the books, and then buy the program). Get at least 2 or 3 books on the appropriate topic. I always say that it's impossible to have too many books on programming.
Then go study. Do exercises from the books. Write simple programs. Spend many hours sharpening your skills, becoming familiar with while-do loops, et cetera. Gain the ability to put up simple graphics and play simple sounds. Buy more books on programming and read them too. When you're finally something resembling a competent programmer, it's time to think about actually writing something someone else would want to use and (hopefully) pay for.
Now, once you know how to program, you need to decide what platform you want to write your program for (usually DOS, PC Windows 3.1 or 95, or Macintosh). You then need to buy a reasonably good (though not necessarily great) computer of that type, a programming environment for it, and books on programming it. Gain familiarity with that platform.
Once you can program competently in your chosen platform, you finally need to start thinking about the sort of shareware program you want to write. Of course, by this point, you probably have a good idea of the sort of program you want to do. Most likely, it will either be a game of some sort you're very fond of, or a program dealing with an area you have expertise in (such as astronomy, or bookkeeping). I will write more in another section about the design and preparation process, since the way you get ready to design and write your program will, in the long haul, have a good deal with how successful a program it is.
Once you have a firm knowledge base, it's time to enter the trenches for the long fight ...
2. Writing the Thing
Now that the painful preparation is out of the way, it's time for what most people find to be the fun part: programming. This is what most shareware developers are in this for ... the pure, unadulterated joy of creating something. There are few things as thrilling as, starting from a blank slate, painstakingly building a massive, elaborate, elegant program. It's a fascinating mental exercise, and sometimes even a reward in itself.
Of course, it's also a long, painful, time-consuming, bug-ridden hassle. That's why you should keep yourself from getting so caught up in the thrill of it all that you get careless and sloppy. Writing a program is like building a house. You can do it without checking the ground and building a strong foundation, but you probably won't want to live in it later.
Before writing even a single line of code, it's best to spend quite a bit of time planning things out on paper. I recommend several weeks. Write out the data structures. Draw diagrams indicating how the program is going to flow. Make a plan of attack: determining what code you're going to write first, and then figure out how you're going to flesh out that framework. Research the system calls you will need to make it do what you want to do, and make sure they exist. Figure out what basic routines you'll need to write completely from scratch (the system software will never do everything you want it to do). Fill a notebook with hard details and schematics.
Then write your program. It will always take longer than you think. Make the code as clear and concise as you can manage, because you'll need to go over it again.
Comment your code! A good program will have tens of thousands of lines of code in it, and you won't always remember what it all does! Many has been the time I've gone back to a procedure I wrote a year before and realized that I didn't have the slightest idea what it did or what variables I was supposed to be passing to it. Five seconds of commenting would have helped me avoid five minutes of figuring out what that code did. Your most valuable resource is time. Waste as little of it as possible. Make your code clear, and comment it.
Test early and test often. Get your program to a state where it runs as soon as you can, and test it for bugs. Debug as often as you can. The longer you go without fixing bugs, the harder it will be to isolate them when you do get around to it. If you can, get friends, relatives, boyfriends, girlfriends, and anyone else you can find to test your program. Other people will always come up with problems you missed.
When the program is finally done, it will need to be beta tested. Before you can let other people download your program and put their machines at risk running it, you need to make sure that it is as clean and bug-free as possible. It needs at least a month, probably much more, or regular people running it and using it in everyday circumstances. You will absorb their bug reports and feedback, make newer, better versions, and keep sending them out until your product is safe and reliable.
Then, finally, after hundreds and hundreds of hours, you're ready to upload your product and see what the market thinks of it. Don't think that you're done yet, though. In many ways, your work has just begun.
3. Marketing Your Product
There is a very common mistake among beginning shareware developers. They believe that their product will sell itself. They upload it to a few places, grin, sit back, and wait for the accolades to roll in. Unfortunately, then nothing happens, no feedback or money comes to them, and they give up.
You need to push your product for it to be a success. You need to talk about it on USENET. You need to join every online service you possibly can, upload your product there, and discuss it on the appropriate groups. You absolutely need to get a web site and get it listed on the major search engines.
Tech support and making your first few customers happy is a must. You need to answer your E-mail promptly and helpfully. Tech support should be as generous and helpful as you can make it.
You also need to be able to accept and process orders. This tends to be a fairly painful issue. You need to figure how you are going to get people's money. Your options:
Between marketing, tech support, and handling orders, you may find that the conclusion of your program was only the beginning of your labors. Fortunately, if it turns out to be a lot of work, that means you're getting a lot of attention! Spend enough time handling orders, and you may be able to build a successful full-time business!
Back to Designing Shareware Page