Future direction of A/UX?

[Michael McClary]

In article <419 at w3vh.uu.net> rolfe at w3vh.UUCP (Rolfe Tessem) writes:
>In article <30843 at apple.Apple.COM> phil at Apple.COM (Phil Ronzone) writes:
>>
>>TELL US WHAT YOU NEED. WE LISTEN. O.K., we don't have infinite manpower and
>>could do it all, but we listen.
>
>OK, a very simple request, and one I made several months ago.  Just post a
>list of MacOS software that runs under A/UX 1.1.  After all, the major
>selling point of A/UX is it's ability to access the Toolbox and therefore run
>MacOS applications.

I have seen this suggestion before, with a reply from an Apple person
giving downside reasons.  As I recall, the main points were liability
exposure for false advertising if the third-party software didn't
perform, and exposure to accusations of playing favorites from those
not included on the list.

Seems to me this approach would work.  (Phil:  Try this on your lawyers
and see what they say.)

Publish a list in two parts, thus:

	The following Apple applications are compatible with A/UX v1.1
	and are supported by Apple:

	 - Foo
	 - Multi-bar
	 - Mac-baz
	
	The vendors of the following products claim A/UX v1.1 compatibility.
	Apple does not warrant their claims.

	 - Blah-windows v1.2 and later.
	 - Blort-paint v2.3 and later.
	 - Etc.

	(Apple does not support third-party software.  Users should contact
	 the third-party vendor for support.  Apple will accept user reports
	 of gross malfunction of third-party software on this list, especially
	 malfunction causing damage to system or user files other than those
	 associated with the third-party product in question.  Apple does not
	 warrant third-party software on this list to be free of such bugs,
	 and does not promise to investigate all such reports.)

	(Third parties are invited to contact Apple for procedures for
	 inclusion on this list.)

Then:
 - Include their product if they send you a copy that launches successfully.
   (Make it clear that Apple gets one usage license as part of the deal.)
 - Pull it if users complain it eats their disk and you can replicate the
   problem, or if you can't test the claim because of product problems (such
   as copy protection).
 - Don't bother with further testing.
 - Don't bother with applications that look hard to test.
 - Don't bother with applications that don't look big sellers, unless they
   might appear to compete with an Apple product.

If an apple programmer expects the program to be useful for his own work,
he is also a "user", and can report bugs.  This is an additional
justification for testing some programs extensively and others not at all.

By the time supporting such a list becomes a resource drain, you're over
the hump, and can drop the ads if the expense isn't justified.  Meanwhile,
it gets you a free copy of most major third-party products, which you can
use as test instruments to separate A/UX bugs from application bugs, or
to be sure a new release doesn't break a major application.

	think it'll fly?
	michael at xanadu.COM