Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!unisoft!hoptoad!xanth!kent
From: kent@xanth.UUCP (Kent Paul Dolan)
Newsgroups: comp.sys.amiga
Subject: A Modest Proposal (was Re: Intuition's "don't mess with these" fields...)
Message-ID: <3258@xanth.UUCP>
Date: Sat, 7-Nov-87 04:15:47 EST
Article-I.D.: xanth.3258
Posted: Sat Nov  7 04:15:47 1987
Date-Received: Mon, 9-Nov-87 06:24:03 EST
References: <1961@amiga.amiga.UUCP> <1825@cadovax.UUCP> <2631@cbmvax.UUCP> <1831@cadovax.UUCP> <663@mitsumi.UUCP> <1846@cadovax.UUCP>
Reply-To: kent@xanth.UUCP (Kent Paul Dolan)
Organization: Old Dominion University, Norfolk Va.
Lines: 74
Keywords: This situation is making enemies of those who should be friends.
Summary: Fair play suggestion.


Having seen two groups of well intentioned people, trying to do the
best job that they can, get furious with each other, and ignoring any
justice in the other's cause, I'd like to extend my sympathies to both
Keith Doyle and the CATS crew.  The sad part is, both sides are right.

CATS is completely correct.  If access to "unsupported" hooks is
sanctioned by CBM, then the operating system gets frozen in whatever
the state (possibly buggy) in which it was last released, or
development of upgrades is made multiple times more expensive for
trying to step around the non-standard accesses without breaking them.
This is undesirable from everyone's viewpoint, including Keith's and
mine (just a customer).

Keith is ALSO completely correct.  When you work in a marketplace,
your potential customers won't even LOOK at your product until it is
at least as good as the competition.  When the sales of a package make
it a "defacto standard", as is the case here, the competition is even
more intense.  Customers are rarely, if ever, technically
sophisticated enough to understand your reasons for not doing
something non-standard, when they can see it being done and being
useful in your competition's package.  Your management is not
interested in hearing excuses, however "motherhood", from you, the
developer, when the success of the product is on the line.

So, rather than having the good guys fight the good guys, I suggest
ganging up on the villains of the piece, the folks whose use of
unsupported AmigaDOS hooks has made the whole mess what it is.  All of
this has to be done from CBM's side, unfortunately, but it might make
all the well intentioned members of the situation happy.  It does take
(work = ) money, which perhaps Keith's side could supply in part.

I suggest a two pronged approach.  First, CBM should make an effort,
with malice aforethought, in each release, to break software whose
disregard of standards causes problems like this.  The third or so
complete rewrite of a major package should convince the bad guys to
pay more attention to the rules.  This does require that releases of
AmigaDOS be responsive to performance problems identified by
developers, and that CBM be willing to consider and, where reasonable,
include, third party developed improvements to AmigaDOS, and provide a
standard path for requesting those inclusions.

Second, for a fee, Commodore should be willing to certify that a
package meets all known CBM software standards.  A sticker with this
certification on the cover of a software package would (in print)
inform the potential software buyer that Commodore will use this
software in testing new operating system releases, and will strongly
endeavor _not_ to break it with new operating system releases.
(I think "guarantee not to break" might be a bit too strong, but
consider it.)

By requiring and rewarding truly _professional_ software development
for the Amiga, Commodore immediately benefits by improving its stature
as a vendor of professional quality hardware for which professional
quality software is available and easily recognized as such.  Folks
such as Keith can now make a reasoned choice between releasing a
package that will probably die in the next release, but that attracts
the customers by nonstandard bells and whistles, or releasing a
package with a very high probability of being useful through many
AmigaDOS releases, and which uses _that_ as a feature with which to
attract customers.

I have no illusions that this will be easy to implement, or even easy
to agree upon, but I do think it offers a workable path out of an ugly
situation in which persons of good will are reduced to name calling.

Good luck to all concerned.  Even if you don't like these suggestions,
take them as an indication that, when tempers cool, a path out of the
current troubles may well exist that will be acceptable to all
parties, and that it would be more fruitful to spend the present time
looking for it, than continuing the current exchanges.

Love to the lot of you.  You _all_ make my machine the joy it is.

Kent, the (occasionally rather rational) man from xanth.