As I'm typing this I'm involved in a hackathon part of the Google.IO eXtended event in the beautiful town of Zadar on the Adriatic coast, and that's as a assistent organizer, mentor and a member of the jury, so it's been a very hands-on experience. Since this is a very hands-on experience in the details of organisation, I'd like to write down, among others for my own future use, what makes a successful hackathon.
What's a hackathon?
Hackathons originated in very technical, geeky communities (I believe the first one officially called a "hackathon" was at an OpenBSD gathering, and the idea soon spread to FreeBSD, where I was active for quite some time), where they were simply an occasion for people to get together - or get individual, as individual inclinations are - to work on a relatively well-defined project or a part of a project. It was common at BSD conferences to have both "birds of feather" gatherings where people interested in similar things would work on new features, as well as "free-for-all" hackathons, usually during the nights, where people would just sit in peace in a common space and work on something they thought deserved attention, occasionally using their collegues as rubber ducks. The latter was sort-of like an open office experience, with immensely smart people working on parts of the operating system kernel, a subject which is in its own category of difficulty.
From such beginnings, hackathons have spread and the meaning was stretched a bit. Nowadays, some of the popular types of hackathons are:
- Gatherings of geeks developing a specific idea or a project - not necessarily related to IT. People coming together to work on everything from woodworking, mettalurgy, to kite making and drone racing, and even bio-hacking and medicine, can form a completely legit hackathon if they wish to. There's no license for it.
- Common good initiatives where municipalities (or companies, usually larger ones) sponsor people to develop ideas which would improve public transportation, solve an ecological problem, develop solutions for reporting issues like potholes on public roads, or garbage problems, with the goal of adopting the solution, and usually paying the best developers to complete their project(s) at market rates.
- Developer competitions where developers compete in creating ideas, more or less directed (or constrained) by the wishe of the organisers, and can win prizes which range from symbolic to substantial.
- Recruitment hackathons, which may otherwise fall into one of the other categories, but where the main theme is for the organisers (usually companies or NGOs) to scout out the best talent which they may employ or subcontract to.
Hackathons are often a combination of the above types, and in any case - all this depends on what the organisers want. I'll mostly write here about competitive hackathons, which may be combined with other types as needed.
Prerequisites: the venue, the participants and the jury
The usual situation is that there are many teams participating, possibly in different categories. To make life easier for the mentors and the jury, and to aid networking between participants, name tags should be color-coded (or marked in some other way, maybe with different shapes or with different stickers) to distinguish teams with different categories.
An important thing is for the participants to have enough space to get comfortable. This is easy to do if the organisers have specified the maximum team sizes, as they can plan how large the tables are and how many seating places there should be. Judging from experience, there will often be participants with additional equipment - ranging from additional laptops, phone chargers, to monitors and even desktop computers. To cater for these, there should be about two power outlets for each seating place.
The venue should be airy and air conditioned - people will spend a long time here, and possibly even sleep in the chairs - so its very important to have the room(s) ventilated.
Rules of the hackathon should be known well in advance - ideally as soon as the invitations are sent, and this includes the exact start-and-stop times, what the prises are, and what can be expected for organisers and hackathon mentors.
Different organisers have different opinions on whether the hackathon themes should be known in advance. An argument for keeping them secret is to increase fairness: so each team is roughly in the same position when the hackathon starts. On the other hand, this means teams are applying blindly, and don't have a clear picture what will they work on until the event starts. Personally, I argue for announicng the themes in advance so potential participants can prepare.
All these things hold true for the members of the jury: they should know in advance what sill happen and what is expected from them. This may or may not include instructions on how to grade the participant teams. Again, there are different styles which could be applied: some organisers, especially of larger events, might try to hide or obfuscate who the jury are, so they can mingle among the participants and discover what they are doing for themselves, without additional pressure on the teams. Others are more conservative and announce everything in advance, including specifically designing the criteria on which the teams will be graded. I've seen both approaches work very well in practice, so both are fine as far as I'm concerned. Personally, if it's a bigger event with lot of people going around and visiting the teams, I'd argue for not necessarily making a distiction between members of the jury and generic visitors, but I'd not make this a strict requirement.
The pleasant distractions: food, drink, and music
It's often said that engineers are machines for converting coffee into products, and there's a lot of truth in there. It's absolutly necessary that the venue has a constant supply of water, soft drinks, and energy drinks, available to the participants at all times. "Real food" can be delivered in the usual pattern (breakfast / lunch / dinner), with an occasional box of both salty and sweet snacks available in between.
That said, many people who will come to the hackathon don't usually eat healthy, so I'd also prefer there should be a few varieties of fruit always at hand, and to go easy on the pizza.
The choice of food and drink depends on the expected participants. If most of them will come from a region which is famous for its wines, making a beer-only hackaton is a bad idea. Similarly, if most of them are expected to come from a region which practices a "meat and potatoes" diet, serving fancy French food, or seafoods, will probably not be well received.
The same goes for the music: unless you're sure pretty much everyone who will come enjoys Indie Ultra Death Metal from Finland, you should probably take it easy on the growling. Also, while chiptunez may be a stereotipical hacker musical background (at least in certain Hollywood movies), you need to be doubly sure before putting that chiptunized version of Kraftwerk on a loop all night.
Food, drink and music should be stimulative - that's for sure - but it shouldn't be overly surprising.
Preparation: the pen and paper affair
It's usually best for the teams to decide on the team names at registration time. Unless it was announced as a prerequisite, they will probably not have an idea ready so project names will be collected later.
Teams should have enough paper, possibly in the form of notebooks, ready for brainstorming. If youre giving them pencils, be sure to include pencil erasers and sharpeners. If only pens are being handed out, include enough peper so they can star anew.