Responsible Hacking
I don’t normally comment too much about non-Cocoa-yet-Apple-related things here, for reasons I’ve outlined before, but a recent post of John Gruber’s pointed me to Jeffrey Zeldman’s story about his disastrous upgrade to Panther, and I find it very difficult not to comment on it. Before I do, though, I have to issue a common sense disclaimer: these opinions are mine and mine alone.
Now, I sympathize with Zeldman. I’m always crushed to hear about someone having a bad experience with OS X, and I more or less agree with his “modest suggestions.” What I want to discuss, though, is what makes his case so exceptional.
To the casual reader, Zeldman’s narrative makes OS X sound like a ticking time bomb, a precarious piece of work ready to come completely unhinged because of a mere software update. His problems—non-launching apps, kernel panics, and other assorted mayhem—would seem to be too obvious for Apple not to catch. As Zeldman says:
A simple OS upgrade should not fail, should not induce panic, and should not waste three days of a user’s life.
So how is it that such anarchy could have been loosed upon the world?
The answer has a lot to do with the actual cause of most of Zeldman’s problems (the more subtle 10.3.3 printer issues that Gruber mentions being an exception), to which he alludes only briefly when he mentions that he was running several third party “system add-ons,” or what are more colloquialy known as “haxies.”
Haxies are fun because they do the seemingly impossible: they magically modify “closed source” software to do things it was never intended to do. Don’t like a standard OS X dialog? Change it! Prefer pink vinyl Finder windows to metal? A little hacking, and your dream can be a reality!
Unfortunately, there’s a reason these nifty OS modifications are called haxies: because they’re hacks. Unlike normal software, which uses the system in publicly documented ways that Apple guarantees to work from release to release, haxies often go rooting around under the hood, rewiring things and generally operating at a level that could best be described as “daring.”
The problem comes when things under the hood change in ways that the haxie author might not have anticipated (say, because of a major OS update), but the haxie goes on trying to rewire things the way it always has. If things go sufficiently wrong, this can result in any application that depends on that “wiring” crashing. Since modern operating systems are built with layers of reusable code, a haxie that causes such problems at a low enough level can make its ill effects felt across the entire system. This is why Zeldman experienced not one, but a plethora of crashing apps.
My point in explaining this is not necessarily to dissuade people from using OS mods, or to dissuade developers from creating them. I appreciate good hacks as much as the next guy, and I have respect for the clever people who pull them off. However, I would argue that becoming the kind of person who “mods” his OS is a lot like becoming the kind of person who “mods” his car: it demands more of an awareness about what you’re doing to the machine, a more active involvement in its maintenance, a certain tolerance for potential downtime, and an understanding that Honda (or Apple, as it were) is not necessarily to be blamed if something goes wrong.
This is not to say that all of the responsibility should be laid at the user’s feet, though. In fact, in my opinion, haxie authors have a much greater obligation to ensure their users’ well-being than developers of conventional software. I think a great example of a developer who understands this and practices “responsible hacking” is Panic, with their CandyBar app. Rather than allowing CandyBar to blindly assume it will function properly in future OS versions, Panic restricts each version of CandyBar such that it will only work on OS versions up to the latest one at the time of release. Meanwhile, Panic tracks upcoming OS X releases through developer seeds, and only releases an update once it has been adequately tested with the new OS update.
So, then, I guess an additional lesson of Zeldman’s Good Friday disaster, from my perspective, might be this: let the user beware, and let the hax0r be responsible!