I've written about my desires for calendaring that works well on OS X in the past. For the last several months I've been making do with Google Calendar. The phrase making do doesn't do Google Calendar justice as it's actually an awesome web-application. The biggest drawback is that it doesn't completely integrate with OS X and therefore doesn't sync well with my palm.

Enter the public beta of Spanning Sync. Life looks good. things are progressing nicely and much of the redundancy of read-only calendar workarounds is gone. All was going as well as could be expected until last week. Spanning Sync moved from beta to "final" release and quit working. The final release had an error that duplicated all the calendar entries in Google Calendar. Really annoying. More annoying because although the developer suggested a solution it wouldn't work because there is another more insidious error. So by Friday afternoon a new version of the application "1.0.1" is released.

This morning I installed that application and it caused Spanning Sync to stop working entirely. All that it would do is contact Google and say it "encountered an error". Not only could one not sync but you can't even reach the "Reset" button to perform the reset suggested in the original fix. After a restart did nothing to help I uninstalled Spanning Sync and did a clean install of version 1.0.1. Now it is possible to ask it to Sync and to perform the reset. The only problem now is that instead of having the error reporting dialogs pop up it comes up and says "Syncing...." and does nothing.

So off to the "reset" function once again and this time attempt to send an error report. The Error report gathers several files together and places an archive on the desktop (no chance to tell it where to place it). The archive contains six files on my system. Spanning Sync's preferences file, installed_files.txt, ps.txt, sync.log, System Preferences.crash.log, system_profiler.spx are the files included. Some are understandable. However there is apparently no checking on any of them to determine if they are relevant. System Preferences.crash.log on my system for example is over two years old. It was transferred from a previous system when I upgraded to a Mac Book Pro. Potential value in troubleshooting this problem: None. It is a good idea not to start command line services with passwords on the command line. My system doesn't do this. However, it happens. In ps.txt Spanning Sync captures all the running processes and their command lines. Useful information for troubleshooting no doubt. The big problem is the application doesn't tell you what it's capturing or let you review it.

At the end of the day a third of my "trial" time is gone and there are doubts that the company will fix the software or become usable in the next 10 days. Add to that the crazy pricing scheme where this conduit wants $65 for their software that at the end of the day ties together two API's (Google's Calendar API and the Mac Sync API) and I'll be joining the legions that are uninstalling. When will vendors understand that users are not willing to pay for software only to spend hours debugging why it doesn't work? Especially when that software is very expensive for the class of software. One wonders if this is a SOHO product because it is the same methodology.

It looks like until Leopard comes out I'll be using Google Calendar and hoping for great solutions for collaboration and a system that will do a good job of syncing calendars, to-dos, and addresses in a way that makes them accessible to system applications.