Ask HN: What makes a good hackathon?

Adding on to what others have said already:

Success: A successful hackathon is where interests are aligned and everyone gets value from the event: the producers, sponsors, api providers, organizers, hackers, volunteers, event scribes, mentors, emcees, judges, audience, bloggers et al. Generally many things generally need to come together to make this magic.

Objective: What is the hackathon's objective? to test an api or tech (sf chatter 2010)? popularize it? build things on it (google wave hack '09)? cross pollinate apis? supercharge a conference (launch '15)? introduce a new tech paradigm (uc berkeley btc hack '14) start a developer program? build a dev program? find great devs or a great team (lady gaga backplane sxsw '12)? to find out whether to release tech (twitter annotations '10)? to pre-accel teams (angelhacks)? to have fun [go hack w/ rbodo @ singularityU:]? create solutions to problems (amex creative-currency '11)?

Prizes: can inspire (pp's 100k prizes), be complicated (sfdc $1m prize(s) '13 hack), be too little (as some have commented) or be just right - which depends on the objectives & aligning interests.

Setup: a page with links to all tech offered / available for the event. If setup is complex & lengthy consider creating virtual machines for devs (transparency & blockchain hack '14). Consider having an harassment policy (tcd sf '13).

Rehearse: if it's your first and you've many people coming, rehearse when doors open & devs pile in. Rehearse the hacks, make sure presenters can easily connect to the projector, have screen settings correct, sound on or off, have right sound level, know how to use a mic. If you've lots of demos - ideally have two podiums. If someone's preso can't start or gets stuck, you can quickly switch over to other podium.

Scribe: Have a hackathon scribe. Blog before/after the event. Create a tweet handle. During rehearsals create tweet for each pitch describing what it does & handles or name of at least the team leader. During each pitch, send out their tweet. Tweet each and every winning team. Tweet thanks to your sponsors.

Guides: hackathon.guide hackdaymanifesto.com socrata.com/open-data-field-guide/how-to-run-a-hackathon

Adding some ideas I've seen work:

* Raffle tickets given out to people who are "caught" helping others or generally helping out.

* Dedicated person who knows all the movers and shakers and is familiar with the attendees and skill sets, who can be reliably found in a fixed physical location on site, and who can summon helpers to track down people, solve problems, make introductions. Basically a concierge on steroids.

* Random access session at the start where people line up and have 60 seconds to say either: what idea they would like to work on, what skill set they have, what skills they lack and would like to pair up with. At the end of this people can talk to each other and form project teams if they like.

* Kid friendly - no ridiculous age rules for kids (but sure, kids need to be supervised by their guardians, that's perfectly reasonable). And kids categories for some of the contests if any. But no sequestering kids off in "kid" activities. Encourage them to participate in the same projects as everybody else.

* Generous food choices, including copious amounts of ice cream, sweets, and caffeine, and maybe a healthy thing or two for those who want that. Popcorn is not a generous food item. You burn a lot of calories. Food doesn't have to be gourmet... pizza is great.

* Lots of comfortable spaces and seating including nooks, tables, offices, open areas... a variety but most importantly plenty of spots for everyone with plenty of extra left over, so people can get a tiny bit isolated to focus with their team, if they want to.

* Open hours at the end where family or friends can come in without tickets (if tickets were even required) to watch the final demos / contest.

* A good platform or topic that engenders enthusiasm.

* If there's a contest for projects, have some funny prize categories. Leave room to make some up to fit the entrants. Encourage humor.

* Don't fixate on rules. Safety, sure. But lighten up.

What doesn't seem to add a lot:

* Huge money prizes... sure I have nothing against them but the fun seems to be more important.

* Group photo... this is always a drag, interrupting the flow and disrupting work as people run off to join it and you invariably get dragged along. And the photo is too few megapixels to really be worthwhile.

It helps to have fairly young people who are desperate to prove themselves in the arena of strict meritocracy.

It helps if they don't have anything else to do for a weekend except cobble together a prototype or even a design document, though the latter is more acceptable if progressive women are involved.

Other than that- hiring booth babes as masseuses for the marathon coding sessions usually involved would absolutely increase success of your Next Hackathon (tm)

Judging - consider not having any. None at all. You can talk all you want about "collaborative atmosphere" but if your introducing judging then there is going to be friction, and the better prizes there are the more friction there will be. What's most likely to happen is you'll get ppl coming in preset teams who will studiously avoid talking to anyone else all weekend, which can really kill the atmosphere for anyone who actually wants to work with others.

This doesn't mean you can't have prizes. I saw a hackathon where the presentation at the end was just everyone showing off the cool things they made and then they handed out prizes totally at random. It was great.

What this really comes down to is a much wider issue - what do you want your hackathon to achieve? Just tech ppl who hacked round on a new technology and learnt a cool now thing? Actually a new idea for a thing, but with no plan behind it? Should ideas have a business plan behind them? Do you actually want new start ups to form at your hackathon? Whether you have judging, and if so who judges and the criteria you set will be a very large part of this.

You seem to be being downvoted a bit, not sure if it's your ridiculously boasty first paragraph or your 3 bits of advice.

But if it is your 3 bits of advice, I'm actually going to say that for a certain type of hackathon, those bits of advice actually make perfect sense. So many hackathons are obsessed with judging and prizes, usually based off judges seeing very little in a brief presentation. If you really want to win, your strategy makes sense. While I haven't adapted it wholesale, I've certainly been in situations where I have prioritised technical work by what will play best in the presentation.

Personally tho, I find this a little sad and the atmosphere at these hackathons can be a little rubbish.