Contents | < Browse | Browse >

                    Amiga '97 Developer Meeting Summary

March 17,  1997 - Hosted by Kermit Woodall of Nova Design, Inc.
Summarized by Paul Sadlik

Kermit Woodall, of Nova Design, hosted an informal meeting of developers at
the AMIGA 97 show in St.  Louis to discuss the possibilities of setting up
an informal developers support group.  During the meeting a number of
topics were discussed where developers could be working together to help
each other, the Amiga platform and community.  The idea is that this group
could begin to fill the void left by the demise of Commodore's CATS
developer office and coordinate developer efforts to move the Amiga forward

General Discussion - what do people want to see:
A source for getting current RKM manuals?
Nothing was concluded on this.  There was some discussion that someone
could work on getting something put together.

[I had the following record of a German company that was selling 3.x 
developer documentation:]
Hirsch & Wolf OHG
MittelStr 33
56564 Neuweid, Germany
fax 02631-839931

A recommended development environment?
Kermit suggested that this development effort should not get bogged down in
such religious decisions over what compilers to use, etc.  This should be a
loose organization the focused on moving the platform ahead, not imposing
rules and limitations on developers.

Developer communications:
Developer mailing list
Kermit set up an InterNet mailing list for folks interested in exchanging
genera development information.  This list is intended to act as a central
communications medium to coordinate members of this developers community
(not necessarily a programming help line).  To subscribe, send mail to:

in the message body put this line:


to send messages for distribution to the list, address messages to:

Web site:
Wayne Hunt has set up a general Amiga web site at the following address.
He has offered to host an area for Amiga developers on this site to keep
files and exchange information.  The existing site is located at:

Parts of this site could have to be password protected and accessible to
fellow developers only.  This would allow areas of the site to contain more
private information - not for general, public consumption.

The site could contain a public list of people to send press releases to
and their preferences regarding formatting, type, etc.

The site could contain announcements of future, multi-developer, direct
mail efforts.  Don Hicks suggested a "bounty" system of qualified or
contingent bidding system that would indicate to participants how much
they'd have to pay for a specific part of the mailing.

The site will be maintained by Wayne Hunt.  His E-Mail address is:

File areas:
The idea is to maintain a collection of development tools, utilities,
source codes, etc.  for all developers.

The current contents of the AmiNet "dev" tree can be copied to the site,
(with their permission) but organized into more development specific
categories for easier navigation.

Just do it:
Organized Chaos: 
This isn't a formal organization.  No controllers.  Just suggestions and
aids for development.  Just do it.  No dues.  "You do not have to pay to be

Following through:
If you propose to do something for this effort, you should be responsible
for doing it or at least finding someone to take over your role.

This effort should include some way to bring people into the 
development process.  Experienced developers as well as newer/smaller 
participants.  To bring in new blood and ideas.

Kermit suggested that this developer body should become a central vehicle
for moving the platform forwards with new standards and community- wide
development efforts.  He presented the following points as examples of
things to be done:

AmigaGuide Replacement:
Kermit proposed that we need to replace the existing AmigaGuide-based help
system with a HTML-based one.  His proposal was to use a
communications-stripped version of one of the Amiga web browsers as
publicly distributable help program.

This raised many questions about whether such a system should require all
users to then have to have MUI or ClassAct.  Also that deviating from the
single Multiview/datatypes system would deprive Amiga users of that
unified, easy to use system of handling many different file types.

It was suggested (again) that we could an HTML datatype to handle such help
files.  It was also suggested that only a new API standard for help program
interfacing be defined (a superset of the current AmigaGuide API) to which
any web browser (communications enabled or not) could be modified for and
used.  This would leave the choice of MUI (or not), datatypes, public or
commercial version, etc up to the user.

After touching on the many questions and issues, it was decided that James
Melin of Digital Lightyear would act as a coordinator of this effort to
revise or replace the existing Amiga help system.

Twain scanner support:
Kermit said that some people were working on a freeware/shareware TWAIN
scanner driver.  He suggested that such a widely distributable scanner
interface would be valuable so many applications could incorporate scanner
support with little effort and little expense (required by a commercial
solution).  To take full advantage of this effort, developers should
support it by agreeing on an interface to it and supporting it.  Without
the specific scanner TWAIN drivers being freeware, and freely
redistributable, the effort to support TWAIN could be fruitless, according
to Woodall.

IFF ILBM & ANIM Standards:
Kermit suggested that the existing IFF standards had suffered stagnation
without any CATS-like body to coordinate and push standard evolution, like
they did with ANIM-7, etc.

As examples, Kermit suggested that the IFF ILBM standard was in need of
much work to support CMYK information, new compression methods, and more. 
That the ANIM standard needed support for timing and frames rates, full
color display and playback, as well as interleaved sound.

Finally, Kermit reinforced that these needed to be open, non-proprietary
solutions that should avoid pandering to serving just the needs of single
or small groups of developers.

Eric Schwartz added that the Amiga needed a new Object Based animation
standard reminiscent of the old "movie", Fantavision and Movie Setter

Developer Codependency:
In a small development community such as ours, Kermit suggested that Amiga
developers should cultivate, coordinate and use contacts and efforts with
other developers for everyone's benefit.  He offered the following as
examples of possible initiatives:

Developer Directory:
The entire community would benefit from having a directory of developers to
facilitate communications that could be kept online (on the web site).

Sharing announcements:
To increase contact between developers and with users, developers should
make sure to share their product announcements with each other and their
users.  Include all news/flyers/inserts in mailings to users.

Product Swapping, Developer Pricing:
It is helpful to developers to swap products, yet one never knows what kind
of policy a developer has regarding this.  Kermit suggested that developers
need to publicize what their policy is regarding swapping or selling (at
cost?) a product to other developers is.  This could be publicized in the
developers-only area on the web site.

Licensing - site licensing?
Another question (usually from distributors and dealers) is what a
developer's policy is regarding site licensing.  This could be determined
in a dealers-only area on the web site.

User Groups: 
Developers should publicize their user group buying and training programs
and policies.  It benefits dealers in the long run to support user groups,
at least with demos.  For example, Nova Design offers to demos and training
for user groups for travel costs.

Q: How are beta testers found and handled:
Companies have varying policies.  Sometimes they are not asked to pay,
since they are being asked to test software and their information can be
very valuable.  Good beta-testers are hard to find.

Traditional Media - by DON HICKS, Amazing Computing:
Product Announcements:
Send product announcements to magazines to let them know what's going on. 
Amazing Computing (and all Amiga magazines) want to see something on paper
for authenticity (fax may do), but appreciates an electronic (EMail)
version for editing/inclusion. 

Product Reviews
Provide them with two copies of your product.  One goes to the writer, one
they keep in the office to check the review against.

Suggest review angles
Suggest review angles of your software while providing demo copies.  It is
helpful to mention different or unusual ways users may have put your
product to use.

Programmer's CD-ROM proposal:
Don suggested that people could submit documents and programming tools to
Amazing Computing for placement in a developer CD-ROM ...   As people buy
the CD-ROM, contributors could get royalty checks.

Marketing 101:
Learn how to write announcements as if they were edited articles.  Send the
press announcements to everyone (Amazing, AmiReport, etc), as well as other
developers, user groups, etc.  Also send releases out on new ways your
program is being used to keep it in the public's eye.

Cooperative advertising:
Share advertising space with complimentary developers of a single solution
(for example, solutions for video companies).  This could be used with a
wide variety of advertising methods.

Direct Mail
Do a big, multi-developer group mailing with a flyer to all Amiga users.  
The idea is to keep the costs down to individual developers but get the
word out to many Amiga users.  Don Hicks offered that PiM Publications
could do the printing and mailing with their existing equipment.

Lead Sharing:
Provide Amiga show participant lists to developers.  Developers could share
or trade lists of users that allow their names to be distributed for Amiga

Video Tapes:
Do multimedia promotion on video tape.  To be sold or sent directly to
users or used in video magazines, like the "Amiga Legacy" magazine being
started by Jason Compton.

In Closing:
As we ran out of time, Kermit Woodall closed with a short statement of
encouragement and direction for the assembled group.  While we have a lot
to do with the Amiga, we should all focus on doing what we can and don't
worry so much about trying to do everything at once.  As long as we are
able to accomplish consistent, constructive things around us, the big
picture can take care of itself.