As a self proclaimed Software Addict, I have a real problem. Well, many real problems, actually. Downloading software not only consumes hard disk space, but it also bloats my Preferences folder over time as I launch each software package to try it out. If that weren’t bad enough, many applications leave pieces of themselves in the “Application Support” folder, the “PreferencePanes” folder, the “Contextual Menu Items” folder, the “Services” folder, and sometimes in the “Plugins” and “Input Managers” folders. Then, of course, there are the Cocoa framework that most new Mac developers are using to build software. The Cocoa framework derives directly from the innovative NeXTSTEP development environment that Steve Jobs oversaw before returning to Apple. If you haven’t done so, get a load of the film clips from a 1992 demo Jobs gave for NeXTSTEP 3.0, and you’ll get a glimpse of why the Cocoa framework is fueling such excitement in the Mac market today.

One of the things I did to help organize my software was this website—particularly the part that catalogs the software I’ve downloaded, and how I’ve disposed of it (either by adopting it, or by rejecting it). This has really helped me keep track of my software “collection,” since before starting it I would quite often download a given software package 2 or 3 times… not realizing I had already rejected it, or that it was already waiting in my “Downloads” folder to be evaluated. I also had a hard time remembering the names of all the software, and why I liked or didn’t like a certain app. As my list of software “to be evaluated” grew from 20 to 50 to 100 and more, and as my decisions to chuck this or that app never got translated into actually deleting it from my system, the law of entropy began to prove itself on my file system.

To give you an idea of just how bad it’s become, here are some statistics. In each case, the number is compared with the equivalent on my “fresh” Leopard installation—it’s no longer pristine, since I’ve already installed a couple dozen software items in the course of this project, but as you’ll see it’s a whole lot cleaner than my Tiger setup.

So when the preview build of Leopard (Mac OS X 10.5) came along recently, I decided to do a completely fresh installation and start over. At first, I assumed Leopard would be too unstable to form a base for this new start—after all, it’s still in an Alpha stage. However, so far I’ve been quite impressed with its degree of stability. With only a few exceptions—mostly in some of the newer functionality—Leopard has proven very reliable indeed. Some of the new features are so compelling for me—particularly the enhancements to Safari, Preview, Mail, and Automator, and the wonderful new DashCode tool—that I decided to try to move as much of my current production environment to the Leopard “fresh slate” as I could.

Having decided this, it seemed logical to turn my housecleaning project into a baseline configuration project. In other words, I would start with nothing but Mac OS X and the Apple apps, and I would move to Leopard all of the software I need for the various projects I’m engaged in, as the need arises. I would document each change to the baseline configuration and note what kind of software or configuration change I was making. This way, I’d end up with a complete software inventory, including all of the various bits that make up my rich Mac OS X environment. In the process, I’d clean out software I don’t really need, which can only be a good thing.

Going forward, I plan to use a different user account for software demos, so that my main account doesn’t get all clogged up with software I never wanted to install permanently in the first place.

This article therefore announces the start of a new segment of Musings from Mars, currently called “Building Leopard.” This site will document my progress in configuring a clean install of Mac OS X 10.5 (”Leopard”) with the multitude of software that I currently use on 10.4 (”Tiger”). Besides the previously stated goals of developing a software inventory and pruning old software, I also plan to document items that do not work under Leopard, so I can pass the information on to the Leopard test team (whenever actual beta testing begins). I’m also going to keep a running list of Leopard features that I really miss when going back to Tiger.

Where possible, I’ll link items from my Leopard software inventory to product home pages or to reviews I’ve written in my Software Addicts library. For each software item, I’ll document

• Where in the user interface the software is used (Desktop, menubar, preference pane, contextual menu, keyboard shortcut, services menu, Dashboard, etc.), and
• What main functions I use the software for. (The functional categories correspond to ones I currently use to organize applications on my Tiger system.)

Also included in the project will be notes about configurations that needed to be made to enable hardware and to establish general user-interface and system preferences.

Finally, the new site will display a Timeline showing the order in which software is installed. This may be useful as a way of gauging the priority—and therefore, the importance—I’ve placed on setting up particular software packages.

As of today (updated 10/4/06), Building Tiger has all six sections open, and they’re being updated continuously as the project unfolds.

1. Introduction (a summary of this article)
2. Timeline
3. Software Inventory
4. Configuring Leopard
5. Testing Leopard
6. Discovering Leopard

Now I only hope that Apple can stick to its own stated Timeline of releasing Leopard next spring, because I really want to start using it full-time now!