Written by David Tebbutt, Soft 07/83 - scanned
You don't need to be very bright these days to realise how vital software is to every microcomputer system. Gone are the days when you bought a lump of hardware and hacked out the code for every last little thing you needed to do. That might have been fun for the dedicated hobbyist but it was hardly likely to bring about the rapid expansion in microcomputing that we are witnessing now. Fortunes have been made by individuals who realised early on what sort of software was needed and dedicated themselves to producing it, in the mid-seventies, before the boom started. Everyone has cause to be grateful to the likes of Gary Kildall and Bill Gates for showing the way ahead.
Kildall wrote CP/M to give a common interface to programs regardless of what actual machine lay behind it. Software developers immediately latched on to this first microcomputer operating system and started churning out packages because they were no longer dependent on the success of a particular hardware manufacturer. At this time, underfinanced microcomputer firms were dropping like flies and a software writer committed to the architecture of a particular machine was extremely exposed. How many of you today remember Imsai or Pro-cessor Technology? Gates laid another industry foundation stone by writing a microcomputer version of Basic called Microsoft Basic or MBasic. Manufacturers quickly took to the idea of supplying this with their equipment, thus giving system developers a portable, high level language which could be used on a wide range of machines.
Neither of these products is perfect but each has one massive advantage which made every competitor an also-ran: it was the first in the field. Being better than a market leader doesn't mean a thing in system software or in application software. It is far more important to be first with something satisfactory rather than be technically superb but second.
The next success story is a little different but it bears out the general principles. Dan Fylstra was offered a package for the Apple by one Dan Bricklin. At the time Fylstra was running a small software publishing company called Personal Software and Apple was probably the most successful personal computer in America. The product offered was VisiCalc; the rest is history. VisiCalc became the biggest selling application package and it made a fortune for Fylstra and its authors. The parallels are that it was the first product of its kind and that it did a satisfactory job. The difference is that the authors pitched it at the best selling computer rather than at the CP/M market.
So the principles for success in software are clear: develop an original product that people want; pitch it at a mass market machine/operating system combination; and make sure that it is noticed. It's no good being first if no-one knows about it. Alternatively you could find a package that looks good then write something similar but for a different range of machines. (Do not, under any circumstances, consider ripping off bits of code: you will almost certainly get caught and the courts are taking a much harsher view of this behaviour nowadays.) Of course, you may have the rug pulled from under you if the authors of the original product beat you to the new machine implementation. Or you could write something massively better than the present system and sell it at a significantly different price. Not surprisingly, the first approach gives you the best chance of success.
In future, we will see many software products developed by large corporations who will brag about the hundreds of man years invested in each package. I can't help feeling that there will always be an opportunity for individual software developers to make a living. Apart from anything else, they are much lighter on their feet than the big corporations can ever be, which means that they can respond much more quickly to changes in the market place.
THE GAME
There are two aspects of the software package game: the first is all the things that need to be done to get a software concept out of the head of the conceiver and into the user's computer, the second is all the people and companies who play an active part in this process. We are only concerned here with mass market software, the kind that, with a bit of luck, could make you rich. Bespoke software development is different in a number of significant respects and we shall leave that for another time. Here is a list of functional requirements:
Conceive the application
Design the program(s)
Write the program(s)
Write documentation
Test the system
Design packaging, documentation, advertisements, brochures
Publicise the product
Produce the goods
Distribute them
Sell them
There are no hard and fast rules about who does what. The person who conceives the product is not always the same person as the designer or the program author, although there is almost certain to be an overlap of responsibilities. Some people will conceive, design, write, document and test a product before anyone else gets to hear abut it This may help safeguard your idea, but it can leave you high and dry if you've left out one vital feature without which the product can't be marketed. I have conceived and designed software products and then, because of lack of time, joined forces with an author to get the job done. Depending on the amount of effort involved, you may find that, as an author, you could pick up part or all of the royalties associated with such a venture. Mostly, though, the conceiver/ designer/author is the same person.
Documentation can be a bit of a pain for authors. Two things need to be prepared - a) an explanation of how to use the system; b) a description of how the system is constructed so that other people can support it later. Both sets of documentation can only really be done by the programmer. We shall see later that the published version is usually different from that which the programmer produces.
Testing the system requires the help of outsiders who are prepared to give the product a thorough going-over and to be honest about their opinions. The more user testing of this nature that takes place, the better the end product is likely to be.
The next stage is all about marketing and it is the point at which even the cleverest programmers usually look for outside help if they're serious about hitting the world markets.
Packaging needs to be designed which is both functionally appropriate and appealing to the chosen marketplace. Documentation has to be written with the target user in mind and in such a way that it provides a natural, enjoyable and non-threatening approach to the subject. Explanatory brochures have to be prepared which anticipate the users most likely questions. If thousands of brochures are to be sent out then it is a rare company which can afford the time to answer all the queries which arise from a poorly thought out brochure. Advertising needs to be designed and produced. Once again this has to be done in a way which will lead the prospective purchaser to make contact with the product supplier.
In the middle of all this marketing activity it is necessary to produce some product for stock. The quantity will depend on how many will be needed at the launch and how many sales are expected in the first few weeks. All the unique parts of the total package will need to be ordered in bulk in order to minimise the unit cost. Things like boxes and manuals will represent the major part of this expenditure. Disks and tapes can be ordered more or less as needed although appropriate labels will need to be purchased in bulk.
SELLING THE IMAGE
Once the product is ready for market it needs to be publicised and this often involves a press launch and a wave of advertising. A press release on its own has little chance of being used unless the product is really something special. And if it is so special, what's the point of such a low key launch? This is one of the most financially painful stages of a product's development cycle. You may have spent years developing the package. Design and production costs have already had to be met. And, before the product has earned a penny, expensive promotional activities must be undertaken. And there are absolutely no guarantees that they will bring results. Still, it has to be done and, with a bit of luck and a fair following wind, you will be on your way.
Now, it's all very well to have an advertising campaign and hundreds of mentions in the press but you will need to get the product to the user. There are many routes. The simplest is direct mail order, but if you're going for big markets, you could quickly be submerged by the workload. Distributors can help, although in a small country like Britain these can often be more trouble than they're worth. In America, a good distributor can be worth his weight in gold. In your blacker moments, you may feel that this is what it's costing you. In the UK, computer dealers and chain stores are the most common outlets except for those products which are actually pushed out by the machine suppliers. With the growing awareness that software availability drives hardware sales, many manufacturers are on the lookout for good programs to offer with their equipment.
Manufacturers will do one of four things: they will 'bundle' the package which means that it becomes an automatic part of every hardware sale and the royalty per unit is very small; they may 'badge' the product which means that they will publish it in their own colours and offer it as their own; they may recommend it in an approved software catalogue; or they may simply list it as not being appropriate to any of the preceding categories. Frankly, having your product listed like this is more of an indictment than a recommendation and it's probably worth refusing to go in such a catalogue. Many manufacturers will want you to do extra work on a product to differentiate it from the 'regular' version and to make it more suitable for their systems. We'll look more closely at this when we examine opportunities in the next article.
PLAYING NURSE
Following the sale of each product, you assume a new role: that of nurse maid to every Tom, Dick and Harry who cares to pester you with daft questions. The role you're playing is called 'support' but, if you've done a good job on the product and its documentation, a more accurate description would be 'talking manual'. Of course, if there are serious bugs in the programs you will spend forever on the phone unless you fix them damned quick and make sure that your current users have replacement products immediately. This would be very expensive and will almost certainly wipe out your profits, if any, to date; a fact which should be borne in mind when testing the product. It's much cheaper to spend weeks in pre-production testing than in post-production product replacements.
Other requirements include keeping an eye on market directions and being prepared to develop new versions of the product to match new machines or operating systems. Keep an ear open for criticisms of your product. If they start to repeat then you may either find an opportunity to improve the product or to put out a complementary package. Once again, I'll return to this theme later on. Finally, your product will need continual marketing and selling effort to exploit its potential to the full.
From the foregoing you will see that a wide range of talents needs to be brought to bear on the business of getting your product out of your head and into the users hands. Of course you can go it alone and perform all the necessary functions yourself or with your own team. Many people have done this very successfully. If you do decide to follow this path, you must ask yourself some searching questions. Have you got the energy and the commitment to see the project through? Do you have a clear idea of the worth of the product? Can you raise the finance necessary to launch the package in the most effective way?
If you are happy with your own replies, fine. If not, then you have the option of taking your product to a software publisher.
THE ROLE OF THE PUBLISHER
In the same way that an author writes a book and gets it published, so a software author can go to a software publisher. The parallel isn't quite identical because book writers quite often use literary agents who know the best publishers around for the type of book in question. Software publishers tend to act both as agents and publishers of program products. Some of them cover just the UK but many have a more international perspective. It rather depends on the target machine and the application involved. A British payroll system or a BBC game wouldn't go down too well abroad; more general purpose products would be fine.
Look in the computer magazines for publishers whose range of products is in tune with your own offering. If you decide to consider using a software publisher, it is best to approach them early on in the development cycle, perhaps at the design or writing stage. A phone call or a letter is all that's needed in the first instance.
If your product looks interesting enough then you will probably be asked to prepare a short synopsis of the program so that the publisher can consider it more seriously. If you get through that stage then you will probably be invited to discuss it face to face and, if appropriate, to give a demonstration. At this point, if the publisher is serious you will start to talk about markets, price, royalty payments, timescales and possible improvements to the product.
At this stage you can still back out if you want to. If you do decide to go ahead, then the publisher will want as much information as possible in order to come up with a list of things to be done prior to product acceptance. This would normally be as a result of using the current version of the product but it could be based on a fairly full product description. In either case, the product would be taken to completion in close consultation with the publisher. This is not a perfect world so both parties should expect unplanned requirements and small changes to the design to happen as work progresses. Remember that the publisher wants the product on the market just as quickly as you do, quicker probably, but there is no merit in putting out a product which won't sell because of an oversight in the original statement of requirements.
By now, you will probably be in possession of a draft contract which is essential to protect your interests once the product is on the road. You may find it advisable to take legal advice on the content of the contract although you could end up spending money just to have odd words changed simply because the lawyer feels obliged to show a visible sign that he has done his work.
It is important that you have an open relationship with the publisher. If you don't like the contract or the way something is being done then raise your objections in as pleasant a way as possible. It may be that there are good reasons for things being the way they are. On the other hand, since this is a very new game, the publisher may not have realised that a problem has arisen. The one thing to remember is that the publisher is anxious to do the best for you and your product because the more succesful you are, the better it is for him.
You should have all the contractual details settled by the time the product is ready for testing. This is the point at which the publisher starts to increase his commitment to the product and you can start to reduce yours.
Initial 'in-house' Alpha testing is done to ensure that the product meets the earlier statement of requirements. With your help, the publisher will get the user documentation written, first drafts of advertisements and brochures prepared and the packaging designed. Then, when any fixes have been made, the product moves into Beta testing with some trusted evaluators who will test the product and the draft user documentation. Once the documentation has been passed then manuals, packaging, labels etc. can be printed. By now the publisher is so committed that he's praying that nothing awful will come out of the Beta testing woodwork.
Next, the brochures and advertisements are prepared and plans for the launch finalised. Invites are sent out to an appropriate selection of journalists, some of whom will be interested in the product, most of whom will be going for a free lunch and drinkies. It's up to the publisher to find ways of hooking their interest enough to get something in print. All remaining activities, including support, are the publishers responsibility and you are free to get on with your next million-seller, though you will be needed under a number of circumstances.
In the unlikely event (ho, ho) of a bug being found, you will be expected to trace and fix it very quickly. If the publisher snares a manufacturer, you will probably need serious talks about the types of deal which are acceptable and what timescales you'd be on to implement the inevitable changes. The same sort of thing applies the high volume deals but this would only involve price. It's unlikely that such a buyer would require product changes.
THE REWARDS
The rewards of all this can come in a number of forms. The most common approaches are outright purchase and straight royalties. The outright purchase approach is probably more common with games software because the amounts of money involved are reasonably small. If you desperately need the cash then I guess this is an attractive choice. It does mean though, that if you end up writing a million seller, you won't make a bean beyond that original agreement. On the other hand, if it bombs, then you have probably done all right.
A royalty arrangement suits most people because they share the up-front risks, and they also share the rewards of success. Some companies are prepared to offer an advance against royalties but this may be offset by a correspondingly lower royalty rate. Other companies may fund the final stages of product development and push the royalty even lower. One thing to watch out for when negotiating royalties is making certain what the royalty is a percentage of. The only sensible arrangement is for it to be based on the recommended retail price. Because dealer and distributor discounts vary, it would be nightmare for you to check out the publishers calculations if it were based on actual receipts.
IN CONCLUSION
You can see that a bright idea and a lot of applied effort can make you a winner. You can go it alone or take advantage of the software publishers around, depending on the sort of product and marketplace you have in mind. The road ahead is not easy and it can cost you a lot of money. If your product is truly original, relevant, and aimed at a sensible machine/operating system combination then you stand a good chance of success in this exciting and rapidly expanding field.