\nuovoarticolo{Andy Finkel}{The \amiga{}: how to survive in a PC world}{%
Andy Finkel \\
Flying Cat, Inc. \\
59 Pond's Edge Drive \\
Downingtown, PA 19335 \\
USA
}
{%
Internet:~afinkel@bix.com \\
~~~~~~~~~~afinkel@ccantares.wcupa.edu \\
~~~~~~~~~~andy@shell.portal.com}{english}{%
{\em Epitaph}, n.: An inscription on a tomb, showing that virtues
acquired by death have a retroactive effect.}{Ambrose Bierce}

The world of the \amiga{} is at a critical crossroads.  As members of the \amiga{}
software community our actions during this period are key to the eventual
fate of the \amiga{}.  I'm pleased to have a convenient soap box available to
try out some ideas I've been thinking about on a group of interested
developers, because I think we can make a difference.

My point of view is probably different than that of most of you;  for years,
I worked at Commodore, managing the \amiga{} OS department.  After I left
Commodore a couple years ago, I did \amiga{} consulting (both for Commodore and
for 3rd parties), did OS consulting (for 3DO among others), got involved
bringing out the commercial version of the DICE C compiler, and I'm currently
doing a game for MicroProse.  So I've gotten involved in a lot of areas
of the software market.  But I'm over here in the US.  And you're over there
in Europe.  My perceptions are probably affected by that;  for the last
couple of years, Europe has been {\em the\/} \amiga{} market;  the US, except for
things like Video Toaster sales, has not been what I'd call an expanding
Amiga market.

I've got a reason to write this particular article;  while I do start out by
making some negative observations, really, I'm not all that down on the
Amiga market$\ldots$ because I believe the \amiga{} computer line is going to
be purchased and restarted.  I believe the negative part is needed to get
you in the right mood for my suggestions.  So please, bear with me$\ldots$

\sez{Part I:  The negative part\,---\,the problems}

        What's an \amiga{} software developer to do these days?  Look around.
The big PC war is over.  The IBM PC clones have won.  They're everywhere,
doing everything, including those niche tasks formerly `owned' by alternate
computers like the \amiga{} (and the Mac) like desktop publishing, desktop
video, and so on.  To the end user, whose main interest is in running an
application, there's relatively little reason to choose any computer
{\em except\/} the latest PC clone, because of small factors like price and
general availability of software, support, and information.

        There's a {\em critical mass\/} function at work here.  There are just
{\em so\/} many PC clones in comparison to other systems that it seems
to make sense to develop for it, both for applications that the PC does well
on (whatever those may be) as well as for applications that take enormous
effort to make run on the PC. The huge market size makes those extra efforts
pay off. Gaining even a small fraction of market share of that huge market
turns into a respectable number of users (and so a respectable amount of
money). The huge market size ensures that every application niche will be
filled with a number of application possibilities for the end user to choose
from. (On the other hand, the PC is a pain to develop for, and the PC
application market is crowded by large companies, including Microsoft, who
seems determined to own every possible category of software on the PC.)

        Further complicating this rather grim situation is the bankruptcy of
Commodore Business Machines.  Commodore was managed (I hesitate to use the
word {\em led\/}, as that implies leadership) into the ground over a period of
several years.  Sure, we all saw it coming.  But most of us didn't really
prepare for the prospect.  (Except for those who switched entirely to the PC
clone market, and if you're reading this, you're probably not one of those
individuals).

It seems that many developers feel that they can get along without
Commodore.  After all, what has Commodore done for them except release new
machines and operating systems which causes them to do additional work when
their applications break on the new machines and new OS releases.  Well,
it's true, up to a point.  Many developers can get along without Commodore
for a while.  Not forever, though.  It all comes down to the basic business
model that most software companies follow, whether they realize it or not
(forgive me if I'm stating the obvious, but until John Toebes, Matt Dillon,
Bryce Nesbitt, myself, and a few others started OIC, Inc. to develop and
sell the DICE C compiler system, I'd not studied software company business
models deeply, and I suspect there's at least a few developers out there
who haven't studied them either).

Basically, the profit model for most software companies depends on an
expanding user base.  Upgrades, though a good source of profit, do not
bring in enough income to support a strong software effort.  While you do
save considerably on marketing costs per sale, the number of upgrade sales
is a fraction of the initial sales.  Further upgrade sales will usually be
sold only to a fraction of those who bought the first upgrade. It's a case
of diminishing returns.  Sales to new users, who have never purchased the
produce before is required;  this not only gives the immediate income
stream from the sale, but also increases the pool of people who can be sold
upgrades, thus making upgrade sales more popular.

Without a source of new machines, not only will there be no new users, but
eventually, there will be fewer old users, as their machines break, or they
find other reasons to switch computer platforms.  This further reduces the
size of the \amiga{} software market.

New users also tend to make a burst of software purchases soon after they
buy their systems;  those new users are very attractive to software
developers, because, generally, they are not committed to a particular
software package yet.  Even when the new user had been using other packages
on other platforms, it is possible (and often easy) to convince the user to
switch software packages (to yours) at the time of buying a new system
(good data conversion utilities play a large part in this user decision,
naturally).

But let's say you've calculated your costs carefully, and feel you can still
make money just on upgrades.  You are still going to be affected by the
lack of a Commodore (or other company making \amiga{}s).  Users are going to
look around and see the progress PC clones are making, in increased power
at a lower cost.  And they are going to see the large amount of software
out there.  And they are going to think about switching platforms.  If your
application is the only reason they are still using their \amiga{}, it's going
to be a lot easier for them to switch; while they might not be able to
find an application on the PC that works as well as yours does on the
Amiga, they {\em will\/} be able to find something, because the PC software
market is so large.  If there were eight or nine applications that the user
depended on that were available only on the \amiga{}, he or she would have a
much tougher time making the decision to switch platforms.

Even if the idea of platform switching is only a vague idea at the back of
the user's mind, it's going to cause a reduction of software sales.  Users
who are thinking of switching computers won't be buying a lot of software
for the platform they are leaving behind;  this seems obvious.  The users
will buy only the bare minimum of {\em required\/} software.  In a mature market
like the \amiga{}'s, this translates to very low software sales, as most users
already own at least the minimum required software.

What we're dealing with here is a self fulfilling prophecy$\ldots$ fewer \amiga{}s
gives less software which means fewer users, which means fewer \amiga{}s, and
so on.

But this is only the case without a company making new \amiga{}s.  Once new
Amigas start rolling off a production line, and getting into stores, the \amiga{}
market starts getting new users again, and things begin to look considerably
brighter.

Why should we care?  Well, let me ask you;  have you ever developed under
\msdos{} or under the Mac OS?  I have, and I can tell you it was not a
pleasant experience.  For purely selfish reasons alone, we have to keep the
Amiga alive so we can write software on (and for) a computer that's fun.

\sez{Part II:  The future (it's what we choose to make of it)}

Now, let's talk about what we can do about the situation.

Looking to the immediate future, we have two possible scenarios$\ldots$ one in
which no one buys the \amiga{} product line, the other where someone does.
Fortunately, I think we can afford ignore that first one at this time, as
things look good for resumed \amiga{} production.  Which is a {\em very\/} good
thing, because while it's possible to survive in the {\em no new production of
Amigas/no new users\/} situation, I think we can all agree that the prospect
would not be a pleasant one;  all we could do in that case is continue to
support current users via upgrades and direct support, and competing for the
customers of similar products to your own as competitors leave the market.
All in all, not a good situation. You can keep going for quite a while, but
your customer base won't expand much, as your only real source of new users
are people who are already \amiga{} owners who either have not yet had a need
for a product of the type which you are selling, or who are switching from
another \amiga{} based product.

Fortunately, it looks like some company is going to pick up the \amiga{}
product line.  The situation is a lot more hopeful in this case.  No matter
which of the three (as of this writing) bidders gets the technology, new
consumer \amiga{}s should result.  In fact,  there is a fair amount of new
opportunities that arise from this situation.  (It might even turn out to be
a kind of a reward for developers for sticking it out for so long). There's
also some things that software developers are going to have to do to make
the \amiga{} more successful this time around.

Just relaunching the \amiga{} platform alone will bring in new users and
current users who are still locked into the platform because of a key
application as well as people who still enjoy using their \amiga{} will
probably take the opportunity to upgrade. This translates into new software
sales, both to new users and to current customers.  (New computer buyers
tend to buy a lot of software along with their computer purchase).  As long
as your products are known, available, and work on the current \amiga{}s, you
should do a reasonable amount of sales without any additional effort.  To
make the \amiga{} (and your \amiga{} software company) flourish, though, it's
going to take more.

By staying in the \amiga{} market for the rebirth of the platform, you are
basically saying that you trust the new \amiga{} company (at least a little) to
do more of the right things (or at least, more reasonable things) this time
around. As software developers for the \amiga{}, we have three
responsibilities if this new effort is going to fly:

\begin{enumerate}
\item We have to do reasonable things ourselves.
\item We have to let the new \amiga{} company know of the reasonable
things that we think they should be doing.
\item We have to cooperate with the new \amiga{} company.
\end{enumerate}

We have to do all three if the reborn \amiga{} is going to have a chance.
Let's look at what each of the points mean to the average software
developer.  The first is simple.  We have to make sure the \amiga{} has both
at least some coverage of major software categories, and some unique
software abilities.  That means you've got to look at the \amiga{} software
market as a whole, and fill in missing pieces, rather than do another ``me
too'' software package.

Traditionally, the \amiga{} software developer decides what product he or she wants
to do, can do well, and can do quickly,  then goes out and creates that
product.  That's one reason the \amiga{} product line has so many holes in it.
There's usually no real analysis of the software market before the product
goes into beta test.

Lets take a concrete example:  {\em terminal programs.}  The \amiga{} probably doesn't
need yet another terminal package.  There are already lots of them available.
A developer may have ideas for the greatest terminal package since the invention
of the Model 33 Teletype, but it's just not what the market needs.  And yet I bet
there are actually people planning to do a brand new terminal program to be
released when the \amiga{} software market revives.

Now look at the Spreadsheet or SQL database categories on the \amiga{}$\ldots$ a
bit thin, perhaps? It would be a reasonable and sensible move on the part
of the software  developer to do products that fill the holes in the \amiga{}'s
software line. It helps both the developer and the \amiga{} because the \amiga{}
needs its software holes filled, and there's a greater chance of profits
in a less crowded category.

Another example of a sensible thing for a software developer to do to make
the \amiga{} a success is to give the \amiga{} unique capabilities$\ldots$ things that
you just can't get on other platforms.  This used to be a lot easier when
the \amiga{} was really the only game in town when it came to multitasking and
fast graphics.  These days, though, unique capabilities on current \amiga{}
models come almost entirely from the creativity of software developers. (OK,
from hardware developers too).  True creativity is hard.  One thing that
helps in coming up with creative, unique software is to look deeply and
carefully at vertical markets.  Look for a niche that plays to the strengths
of the \amiga{}.  For instance, the \amiga{} is very well matched to running
museum exhibits, from a cost and a capability standpoint.  Or applications
involving video.  Look for those kinds of markets, where you can stake out a
unique position with your software.

Doing sensible things ourselves will help a lot when we come to the second
point$\ldots$ I think the new \amiga{} company is going to pay a whole lot more
attention to the company {\em X}, which is marketing professional accounting
software or a good solid spreadsheet for the \amiga{}, than to company {\em Y},
which decided that the software package the \amiga{} needed was the one hundred
and first VT100 terminal program.  (Sorry to pick on you people who write
terminal emulators so much, but, let's face it, a terminal program is a good
example of what the market doesn't need right now.)

The new \amiga{} company is going to need developer input.  Badly.  Let's hope
that whoever makes up the new company has the sense to listen.  While it
would be nice if the new \amiga{} company solicited the input, we don't have to
wait for that.  What we have to do is identify the right people within the
organization for the information, and get it to them.  Head of marketing is
one of those people, as is head of sales, head of software engineering, and
head of hardware engineering.  Present the information in a well organized
manner, polite manner  (forget petitions; and letters that start out {\em You
fools.  If you weren't so dumb you'd know$\ldots$} because they just don't have
the desired effect. It's perhaps less satisfying to phrase your letter in a
polite professional fashion than to rip into the mistakes and mismanagement
that you so clearly see$\ldots$ but the idea is go get your ideas across, so
polite works a whole lot better.

At this point, I bet you're asking {\em what kind of information can I
provide?\/}
Good question; this is an important point to clarify. While some
software developers do actually  have better market connections, this is
actually rare (believe it or not).  It's almost automatic when you're the
marketing department at the platform manufacturer to have the sources to
know what is actually going on in the market.  While it might note have
seemed to be the case, even the Commodore marketing department knew what was
happening in their marketplace.  (What they did with the information is an
entirely different story).

The advantage and information that 3rd party software developers have over
the manufacturer's own marketing department  is that the developers
information is based on much more {\em focused\/} market  perceptions, with a
useful bias towards their own products.  In this case,  the bias isn't a bad
thing, as long as you recognize that it exists. (You've got to keep in mind
the old saying, {\em If all you've got is a hammer, every problem looks like a
nail\/}.)  It's this information that you need to communicate to the new \amiga{}
company.

For instance, if you're selling an SQL database (please, someone do one {\tt
:-)}) you might look at your user base, see that every user is adding an
Ethernet card and TCP/IP,  and realize that what would increase your sales
(and sell additional \amiga{}s) would be to have network capable out of the box
Amigas available.  You could create the bundle yourself, but for long term
cost effectiveness, having an official \amiga{} company network hardware/software
pre-configured machine bundle or (even better) networking build into the
machine and a standard part of the OS would be preferred. This is the kind
of information that the new \amiga{} company needs to know$\ldots$ information that
will allow them to choose reasonable directions that meet the needs of their
(and your) current markets.  (such a suggestion may still not make sense in
the context of the wider \amiga{} market, i.e. if 95\% of \amiga{}s are sold as
game machines, built in networking may still not get added.  But by drawing
on your own experience, your suggestions will always be on solid ground.)

As software developers, you're more in tune with where your own markets are;
this knowledge can be key to the new \amiga{} company. As intelligent people,
sure, you have ideas and opinions on things like the kind of marketing the
new \amiga{} should be doing, or what the next generation machine should
consist of, but unless you relate it directly to your own market and
experience, it's just unsupported opinion.  You could be completely correct,
but it won't really matter, unless you back your ideas with your own first
hand business experience, which magically changes a random opinion into an
informed opinion.  (I don't know about you, but I tend to take informed
opinions seriously.)

The third thing we have to do as developers is cooperate with the new \amiga{}
company.  No matter who gets the bid, we have to close ranks behind that
entity, ask them (force them to tell us ¶{:-)}) their marketing plans and
engineering plans, and follow their lead.  The plans of the majority of
software developers has to dovetail with the plans of the new \amiga{} company
if things are going to work out well.  For instance, if the new \amiga{}
company ways they are going to go heavily into education and video (and
their marketing and engineering plans reflect that) for efficiency our plans
as software developers should match that.  If the new \amiga{} expends effort
in certain areas, we can maximize the effects if we as software developers
put an effort into supporting those same areas most strongly.

The whole idea is to make the \amiga{} succeed.  We as developers have a lot to
do with this effort.  I also hope the new \amiga{} company will be an ally in
this effort$\ldots$ as I believe it's going to take everyone, pulling in the
same direction for a change, to make it work.

\finearticolo{}