Now that the Power Macs are increasingly common, a few issues need to be addressed in terms of how to best accommodate them when distributing software. I don't know that there are any complete answers here, but there are certainly some issues to consider when shipping a software product, and for those of you who consider yourselves merely users, when receiving a software product.
First, the Mac world now has three basic types of software. 680x0-only, PowerPC-only, and software that works on both the 680x0 family and the Power Macs. The first two are easily handled; developers simply make it clear (on the box, in the ReadMe, and additionally within the program itself by means of an informative dialog box) that the program only works on non-Power Macs or on Power Macs. (Programs that only contain 680x0 code and work normally on all Macs and in emulation on Power Macs aren't particularly interesting either, since they're simply a little slower in emulation than might be desirable.)
But what of the programs that run in native mode on the Power Macs and which also contain 680x0 code for normal Macs? The question raises its ugly head when it comes time to ship the program - do you ship two versions of the program, one containing only 680x0 code and one containing PowerPC-native code? Or perhaps you should ship a single fat binary program that contains the code for both platforms? Or finally, maybe you should use an installer that installs only the appropriate code for the platform on which it's being installed? All are valid choices, but all have trade-offs. Which would users prefer to receive, keeping in mind that adding disks raises costs, and large files mean longer download times?
Option 1: Ship Two Versions -- The first option, shipping two separate versions of the program, seems the least attractive. With shareware or freeware programs it's a minor pain to send the file twice to the <email@example.com> address for posting on the world-wide file sites. Commercial developers will have more of a problem, though, since they must either add disks to a package or create two separate boxes. Either way, it's more work and expense for the developer.
The main advantage for the user that I can see for this scheme is that if disk space is at a premium, 680x0-based Macs need not waste any space on PowerPC-native code and Power Macs need not waste space on unnecessary 680x0 code. In situations where the files are being downloaded from the nets, the user doesn't waste download time on the unnecessary code.
Option 2: Ship One Fat Version -- The second option, shipping a fat binary program, has a lot going for it in terms of getting the software to the user. It's a single product, which eliminates customer confusion, extra packaging expense, and general headaches. It works perfectly on all Macs and Power Macs without any foreknowledge on the part of the user (a major plus for many users, especially if the program lives on a server), and is generally the easiest solution. The only disadvantage of a fat binary is that it may be significantly larger than a 680x0-only or PowerPC-only version of the same program. It's a non-issue for people with large hard disks, but people having smaller drives (such as PowerBook users) won't appreciate the inflated size.
One possible solution to this disadvantage is a pair of freeware programs called Strip68K and StripPPC, written by Bill Woody of In Phase Consulting <firstname.lastname@example.org> (as an aside, In Phase Consulting published the two programs as method of promoting their development and design consulting business - I highly approve of such useful forms of Internet promotion). The programs do precisely what their names imply - strip out 680x0 or PowerPC code from fat binary applications. I haven't tested them personally, and the documentation implies that they weren't tested particularly rigorously, but they come with source code and are worth a try if you're concerned about wasted disk space.
In some quick tests, Jonathan Lundell <email@example.com> reported that StripPPC brought NewsWatcher 2.0b9 down from 616K to 288K, and Fetch 2.1.2 from 483K to 216K, thus saving 595K on only two applications. That's a noticeable amount for users with small hard disks.
Of course, you almost certainly won't be able to use an updater or patcher on applications that you've stripped, so please pay attention to this detail before you complain to a programmer that a patch doesn't work on a stripped application.
Option Three: Let the Installer Solve the Problem -- The third option, using an installer to install the appropriate code for the target machine, would seem to be the ideal solution for programs that would use an installer anyway. Users run the installer (Aladdin's excellent StuffIt InstallerMaker can install either 680x0 or PowerPC code from fat binaries; I assume the Apple Installer can do something similar) and it checks the machine type and installs the proper code. It's conceivable that the installer could even ask if you wanted to install a fat binary or the specific code. No matter what, you don't run into the confusions created by two separate programs, and there's no wasted hard disk space, as in the fat binary option, although downloading would take longer, and in the case of a commercial product, there would be more floppies.
The main disadvantage is that if a user moves from a Mac to a Power Mac, she may have to remember to reinstall a number of applications to be able to use them at full speed. It's likely to be something that people would forget, and being forced to reinstall might prove irritating at an already stressful time.
If a developer did set the installer up to install the correct code, it would make sense for the developer to leave enough 680x0 code in the PowerPC-native version that the program would be able to exit gracefully with an informative dialog when run on a normal Mac, and be able to inform Power Mac users that additional performance could be gained by reinstalling, rather than using the slower emulation mode. It's even been suggested that Apple should release a code stub that all developers could use for this sort of user information, thus making it both standard and far more common.
Final Thoughts -- So in the end, it's pretty clear that there are no set answers, as I said originally. Which you use depends on how you view the trade-offs and on your specific product. If an installer is involved, a single fat binary, with optional stripping on installation, would seem to make the most sense. For shareware/freeware programs that don't need an installer, two separate versions may work fine. And finally, if all else fails, there's always StripPPC and Strip68K.