A template for successful 'Hack Days.' What are your tips?

“Always be releasing.”

I’m going to be helping with some ‘Hack Days’ later this year for the Knight-Mozilla partnership. One in Berlin in September or October, and another with the Boston Hacks/Hackers chapter during the Online News Association conference.

I’d also like to organize some here in Toronto with our local Hacks/Hackers chapter, and support from the local start-up community, and the media organizations that come out to our event, i.e.: CBC, The Globe & Mail, Postmedia National Post, Global News, OpenFile.ca, and so on.

(Hey, while I’m thinking of it, the Toronto chapter of Hacks/Hackers is pushing toward 300 members – if you haven’t joined yet, why don’t you? It only takes a minute.)

I’ve attended more than a few hack days in my life (or hackathons, code jams, or whatever the kids are calling them now). Let me tell you, in case you don’t already know from experience, that building useful software in 1-2 days with people you don’t know is fucking hard.

That’s why I admire events that have the infrastructure figured out (and I’m not talking about pizza and Jolt cola). Specifically, I’m impressed when they’ve answered the question “how are we going to host these apps, show them off publicly, and make the code available for others to build on?”

It sounds like the recent Buttercamp in NYC did a great job, but they didn’t get 100% of the demos online at the end of the event, and that’s a missed opportunity.

That should be the target that teams strive for, and the eligibility criteria to ‘win’ at the event. Code and demos should be online and visible to the other teams and to the public. Always be releasing.

This must be a solved problem? I’m hoping that there’s a write-up somewhere out there that will be posted in the comments. But, if that’s not the case, here’s what I’m proposing:

• The event organizers do a fair bit of prep-work in advance to make the above possible. Specifically, by setting up an event-specific Github’organization’ that participants will be added to.

• There should be a straightforward [LAMP-stack](http://en.wikipedia.org/wiki/LAMP_(software_bundle) Amazon EC2 instance made available for each team, or a bare bones instance that they can set-up with their preferred stack.

• Each of the public URLs for the instances should be listed, so that teams and organizers can check on progress. Always be releasing. (One could even have fun with a leader board type set-up, e.g., a simple HTML page with a bunch of iframes – one for each teams instance – that reloads their app every minute or so. Same goes for a tally of Github commits by team.)

• With a bit more planning, organizers could even look into using something like DotCloud – or one of the PaaS providers – or a fancy set-up like this one for Node.js that auto-deploys to the EC2 instance with the ‘git push’ command.

For the finale at the hack day, each team should have to present their work live, via the EC2 instance URL. It should also be required that what’s running on the EC2 is a straightforward ‘git pull’ of the code in their Github repository.

Maybe that’s the suspense-building moment, where the teams – live, in front of an audience – have to run a ‘git pull’ and deploy their app, and then load it in a browser. Oh, the suspense!

That’s how I would add some exponential gnerativity to a hack day. Mark my words, it would work.

UPDATE: While I’m thinking of it, it would also be great if each team had a person willing to live blog, or status update, during the event, to expose the whole process – the challenges, the breakthroughs, and opportunities for others to check out their app.

UPDATE 2: Rather humorously, Amazon EC2 had an outage on the day I wrote this. I guess the lesson is: have a back-up plan prepared.