Hypercritical
Game over, man
Apple has a link on their .Mac home page that reads, “Tell us your .Mac story.” It leads to a feedback form with this introduction.
How do you use .Mac?
We want to hear from you. What do you love about .Mac and how has it changed the way you use your Mac? Tell us about the fun things you’ve done with the service, or how it saved the day at your home office.
After reading that, most long-time .Mac users are probably either amused or angry. How has .Mac changed the way I use my Mac? Well, over the years, it’s added an element of fear, frustration, and anger to my Mac OS X experience. How has .Mac has “saved the day” at my home or office? Sorry, I’ve got nothing like that to share. Would you like to hear how .Mac has repeatedly let me down?
.Mac sucks. And (to quote Steve Jobs) I don’t mean that in a small way; I mean that in a big way. Put aside, for a moment, concerns about the cost and feature set as compared to its competitors. That’s another conversation entirely. Instead, let’s pretend .Mac is free, rather than $99/year. Even at zero cost, .Mac is no good. It’s actively harmful to the user experience in Mac OS X.
.Mac possesses a deadly combination of attributes.
- It’s unreliable.
- It’s painfully slow.
Reliability is paramount for a network service. The whole point of iDisk, for example, is to have a place to store data that is “always accessible,” thanks to the wonders of the Internet. The same goes for email, which has become as important as the telephone to many people. If these services cannot be relied upon, they’re nearly worthless.
How has .Mac “saved the day”? Are you kidding me, Apple? I can’t count the number of times I’ve wanted to do something with .Mac—download a file, check email, upload a web page—and have been unable to do so. .Mac has thwarted me regularly, and saved me never.
Then there’s the icing on the crap cake: the agonizing slowness. At this point, even the thought of putting something on my iDisk triggers a fear response. First I have to mount my iDisk, freezing the Finder for God knows how long. If I’m lucky, I don’t have to open any folders on the iDisk, incurring more hot, hot beachball action.
Then I have to copy the file. Tiny text files upload to .Mac in about the time it’d take for me to manually type them across the wire. Transferring large files is like a day-long event, requiring a self-administered pep talk, careful planning, and dedication. And since Mac OS X’s WebDAV file system implementation seems to do all the actual data transfer on close(), the progress bar displayed by the Finder is useless, containing information that has no bearing on the actual time remaining.
But hey, we’re pretending this is all free, right? If it doesn’t work, just ignore it and use something else. What’s the problem? Let me tell you, dear reader. There is an evil that knows no bounds, and its name is .Mac Sync. The idea behind .Mac syncing is attractive: share and coordinate application data among several Macs. This includes email accounts, encrypted passwords, calendar events, bookmarks, contacts, and so on.
All this syncing is subject to the same slowness and unreliability as the rest of .Mac, but that’s not where the aforementioned “boundless evil” comes from. .Mac’s sync services are available to third-party developers as well, and that’s where the real trouble starts.
It’s one thing for .Mac to suck in isolation. It’s another thing entirely for it to infect all your favorite applications. Thanks to the ubiquity of .Mac (every Mac sold has the software to use it pre-installed) and Apple’s efforts to push the Sync Services API, pretty much every Mac OS X application that has to do any sort of network syncing does so through .Mac. And .Mac, as we know, is slow and unreliable. This, in turn, makes the applications that use it slow and unreliable.
These are otherwise excellent applications. I really don’t want to give them up. And even if I did, chances are good that their replacements would also use .Mac for syncing. Network syncing is an important feature, and .Mac has essentially ruined it on the Mac platform.
To some, this all might seem like an overreaction. But this post has been almost five years in the making. This is not about one particular incident. This is not about local network congestion or an important, inaccessible file, or a few syncing errors. “Slow and unreliable” is not a facile damnation. It’s a comprehensive judgement based on my experience during the entire lifetime of the service, across many Macs, many versions of the operating system, and many different locations and ISPs.
Why is .Mac slow? Apple.com always loads quickly for me. I can download 5GB disk images from Apple’s developer connection web site at over 900KB/second, which is about as fast as my cable modem can go. Why is .Mac unreliable? The iTunes store gets a tremendous amount of traffic—surely much more than .Mac—and yet it remains available and responsive nearly all the time.
At this point, I’ve given up hope of discovering the answers to these questions. I no longer care why .Mac doesn’t work like it should. I’m not going to continue to plead with Apple to make .Mac better. .Mac has been around for four and a half years now. It’s enough already. I just want my applications back.
Instead, I have a plea for third-party developers. Please, stop using .Mac. I know, syncing is a giant pain to implement on your own. I realize that using .Mac minimizes the amount of code and configuration UI in your application. But I’m begging you, please, come up with some other solution. This relationship with .Mac just isn’t working. It’s making your users sad and angry. We’ve given it a shot, but it’s time to cut our losses. Please, stop using .Mac.
And when considering .Mac alternatives, please remember that it’s not always possible for common network protocols (FTP, SSH, etc.) to get through corporate firewalls using their default ports. Any .Mac alternative must be able to penetrate firewalls with only a few open ports (e.g., just ports 80 and 443 for HTTP/SSL). Support for proxy servers would be a nice bonus.
There’s a growing list of commercial network storage services to consider. But rather than picking a service, Mac developers should aim to support APIs and protocols (perhaps with plug-ins), always leaving the server location configurable. We want to avoid another .Mac-like situation where the server location is implicit and fixed. Standard protocols, open interfaces, configurable servers, that’s the way to go.
This doesn’t mean that every developer has to start from scratch, however. A community project to replace .Mac is a fine idea, and one that’s been tried before, with varying degrees of success. What’s held back past efforts is the lack of support from third-party developers. Projects like Growl have proven that this kind of thing can really work when enough developers get behind it. Mac users like me can’t abandon .Mac fully until our favorite applications have set themselves free. The movement has to start with you, developers.
I know it’s going to be tough. Apple is going to keep pushing .Mac. The Sync Services APIs will keep expanding and improving. It’ll be tempting to give in. But remember, this stuff always looks good on paper. It’s not so much the plan that’s the problem; it’s the execution. Thus far, .Mac’s execution has failed miserably. After all this time, I see no reason to expect that it will suddenly improve.
My advice for Apple is the same as I gave to developers: cut your losses. Give up on .Mac, as it is currently implemented—and yes (coming back to reality), as it is currently priced. The goals of .Mac have always been admirable, but the implementation is hopelessly broken. It’s time to start anew. Don’t try to tweak it. Don’t drop the price by $10/year and hope for the best. Don’t just add a few new servers to the cluster. It’s over. Nuke it from orbit. It’s the only way to be sure.
This article originally appeared at Ars Technica. It is reproduced here with permission.