This weekend we hosted 175 hackers for Music Hack Day San Francisco in our office for the third consecutive year. Music Hack Day is a unique event—it doesn’t use huge prizes or big name judges to draw a crowd. It’s one of the rare Bay Area hackathons where (seemingly) most attendees actually aren’t local—giving it a fresh vibe, with new faces and ideas every year.

Last week I wrote a post that called for more hackathons to be purpose driven—Music Hack Day is not one of those of events. Instead, Music Hack Day is an event driven by a desire to learn and a shared passion for music. These types of events are, without question, very good for the hacker ecosystem, and Music Hack Day is a shining example of how they should be run.

It’s fashionable to be cynical towards hackathons. There’s too many of them. They exploit developers. They rarely have useful products come out of them.

Even if you’re not a cynic, at some point you have to wonder—why do the overwhelming majority of hackathon projects die succinctly and unquestionably following the event? It’s often a foregone conclusion for the hacker—go to the event, try to win the prize, and then go back to your job the next day.

And there’s nothing wrong with that. Most of the time people go for fun. It’s a good learning exercise. As a first timer, the sheer novelty of it all gives you enough energy to power through an entire weekend.

A number of developers have asked for ways to help end users diagnose potential problems that disallow them from being able to successfully video chat using OpenTok. A while ago we introduced a troubleshooter page that test a user’s network, hardware, and software to check things like ports, camera, and Flash version to be sure that they have what they need in order to use OpenTok.

While this tool has been useful for diagnosing problems, one obvious pitfall is that you have to send your users to our website—away from your experience.

There’s irony in being a cloud provider when a major piece of your infrastructure lies below sea-level. Of course, the premise behind the cloud is that you never have to think about the underlying physical location of your servers. If a flood were to happen in a critical network hub, say New York City, it should in theory have no impact on a cloud service (because, you know—clouds are in the sky).

As Hurricane Sandy forecasts came in, our ops team began to consider what impact it might have on our service. We had two options: A) keep our NYC servers as they were and hope that power and connectivity would remain intact, or B) take our NYC servers out of rotation and direct that traffic elsewhere.