I've noticed two things that have ruined hackathons for me:

- People that say they have skill in XYZ, when in fact they have little to no experience in XYZ. It would be nice if I could have some reasonable confidence in a stranger's ability to be experienced in a skill they claim to have.

- "Entrepreneurs" interested in getting free dev labor for their unicorn app idea. I sign up for a hackathon to have some fun and write some code with hopefully cool people, usually for some cool or good cause. I don't come there to make a beta for some greedy MBA student.

Along the same lines, participants who spend all their time running around and "networking". Socializing and meeting people is obviously one of the draws of these events, but a few bad apples do tend to ruin the atmosphere for everyone.

>"Entrepreneurs" interested in getting free dev labor for their unicorn app idea. I sign up for a hackathon to have some fun and write some code with hopefully cool people, usually for some cool or good cause. I don't come there to make a beta for some greedy MBA student.

This is the only type of hackathon I've ever seen. It's put me right off them.

Plus, the amount of work you can realistically get done in a weekend is limited.

These are two great points. It's important to note that Hackathons should be open to people with a wide range of skills, but there's definitely a ceratinly baseline when it comes to saying "I know XYZ".

Honest and hard working > skills but not actually.

What makes a good hackathon? As a frequent attendee, these patterns have stuck out as successful to me:

1. Set over the course of a weekend. Allows greater breadth of attendees. Not 24 hours (which is somewhat manic) but rather a more leisurely schedule of Friday: beers/pitching/team-forming; Saturday: hacking; Sunday: polish, pitching-practice, pitches, award ceremony.

2. Strong focus/process/timetable. Ensure everyone knows the schedule and judging criteria they're hacking towards. Set out the support infrastructure and resources at the top of the weekend so people can get up to speed in the methodology of the weekend. Startup Weekend tells attendees to create a plausible startup, then links them to Lean Startup resources and hands out lots of post-its for their business-model canvases. Major League Hacking tell people to make something "cool", then feed them boxes of Red Bull and loaner-hardware. Horses for courses.

3. Experienced organisers and mentors. Have at least one person for whom this isn't their first time running a hackathon, and knows how to sort out and prepare for all the little things that can (and will) go wrong. Mentors are invaluable for setting the tone of the hackathon and guiding everyone through the event and criteria (see point 2).

4. Pizzas/generic junk food are fine (and expected!) once in a weekend. ONCE. Similarly, lots of caffeine and beer (at the beginning and end) is great for getting a buzz on, but put out plenty of water and maybe some juice/herbal teas as well. There'll be plenty of natural highs by wrap-up time, and reasonable adults won't attend if they think they're gonna feel terrible the day after (see point 1).

Other thoughts:

- Thematic hackathons provide an opportunity for hackers to learn about a new domain, and for domain specialists and otherwise interested-persons to get involved where they might not at an event specifically organised for them, but OTOH it can dissuade some hackers from attending who don't think they'd be interested. In order to resist any gimmickiness, there should already be a dialogue or narrative - either an existing community which has already expressed interest in the domain (e.g. an open data community regarding city-infrastructure), or more general hype and interest (think Startup Weekends).

And remember, it's people in a room to have fun together in a slightly unconventional way. Make sure that you build up the community and teamwork of it all the way through, look after everyone, go have beers after, and start planning the next one if people are asking for it!

Thanks for sharing, this is both informative and reassuring as I'm currently organizing my own hackathon coming up in 2 weeks.

It's a thematic hackathon ("Startup Weekend Immigration") happening on May 29-31 in SF.[1] We'll be hacking on ways to make it less difficult for immigrants to achieve a better life in a new country, and we have some great speakers including the CTO of Zenefits, who struggled with visa issues himself while co-founding Zenefits.

If you know anyone who would be interested, they can use the promo code "hn" on Eventbrite[2] to sign up for $25, which includes all meals during the weekend. (Early Bird pricing ends tonight at 11:59pm PST.)

[1] http://www.up.co/communities/usa/san-francisco/startup-weeke...

[2] https://www.eventbrite.com/e/startup-weekend-immigration-tic...

I avoid signing up for multi-day hackathons. Almost none of the venues guarantee quiet, secure places for naps. It'll be great if attendees can sleep at home without penalizing their teams.

I've done a lot of hackathons, and even the most high profile ones usually suffer from one of the following:

1. Internet and Working space

If you're expecting a high turn-out. Make sure the facility has a comfortable work environment and enough tables and chairs for everyone to work in. Ensure that the internet will not overload due to too many connections. This is a very common problem

2. Judging

Different hackathons have different purposes, and make sure the judging aligns with it. Some hackathons focus on business-viable projects, while others aim to build something "cool". Make it clear what the criteria is. If you're looking for cool projects, make sure the judges don't elect a winner because their project made the most business sense, especially if it's just a front-end hack, where the back-end doesn't even work (very common).

Have a way to check that projects weren't built ahead of time. Fraud is a major problem in hackathons.

Good luck

Concerning judging, I advise everyone to… just drop it! We started dropping it when we launched Museomix[1] as it made no sense for the mood and culture we wanted to create: inclusive, cross-disciplinary, community building oriented.

Back in 2010 and 2011 with the first ArtGame Weekends we had a jury and a small money prize. Most people didn't in fact care for both of them: it was just not an integral part of what motivated them.

On the other hand, jury and competition induce several issues. One is explicitly stating from the get go that only some teams and projects will have merits. Another one is falsely relying on the prizes as the solution to what happen next (we gave you 5000€, now go build v1).

Jury and winners in hackathons are event a PR trap! With a winner, you now have to focus your post-event PR solely on the winner, loosing the possibilities of picking and talking about the right project to the right person.

So, I now advise my community friends and my corporate clients to not have a jury in their hackathons, but to instead have, for example, a Mentor panel. They are not there to elect a winner, but to close the event, create a demo goal, and most importantly use their knowledge of the ecosystem(s) to trace a path for the teams to pursue their project (by for example referring them to the right persons or organizations).

One of my very clever client decided she would instead of having a single prize just give away all the tech she bought for the participants to hack with during the event -- using what would have been prize money! Estimotes, micro video projectors, WeIO and Arduino boards… to all participants. ("Come back home with your project"). It makes sense, and can cost the same. [3]

In a Museomix edition the reward is intrinsic: you live, build and show your prototype directly in a museum for 3 days. And everyone get to share this reward, organizers included!

As collective / co-creative events organizers, ask yourself if you really need to add more selective competition in a world where there is already so much of it, and ask yourself if having a jury really align with the culture you want to create. Do you want to create/mimic an academic/school culture? If not then maybe you just don't need jury.

[1] http://museomix.org/en [2] http://we-make-money-not-art.com/archives/2011/05/art-game-w... [3] http:/cultureexperiencedays.adami.fr

I wanted to say something very similar about the judging. At hackathons with prizes the criteria really needs to be very clear upfront and strictly adhered to. Everyone works really hard during the event, and if the attendees feel the judging is poor, people will leave upset. For example, if people think a working prototype is important, and the judges instead go with a polished presentation with nothing behind it, that can be very frustrating.

"...weren't built ahead of time." Where's the line for this? Surely I'd be permitted to reuse libraries (that I've written; that I got from github; whatever) and perhaps the "project" is a smattering of glue. Am I disqualified because 99% was written "ahead of time"?

libraries are fine of course. in higher profile and more competitive hackathons, i've seen quite a few teams who complete the whole project (or re-use the same project from another hackathon).

I think of hackathons (and game jams, which I'm more experienced with) as extended parties. You do sit down and get work done, but the atmosphere and presentation are important and make it special. Everyone wants to start near their comfort zone, but also leave happy and with some new perspective.

That means getting all the details right, starting with clear statements about what the event is and what kind of people are expected, the time and schedule, achieving physical access to the venue, who to contact for questions, and what kind of refreshments(if any) will be on tap. Every one of these things will change who actually decides to come: For example, if the venue is in a seedy part of town, people who feel most vulnerable will stay home without assurance of a ride or escort. Photos of an appealing venue can often swing people who were on the fence. Prizes are a question mark as they can massively shift the participation incentives from "do something I like" to "beat the competition", putting a sour note on the whole thing. Unless you have a specific agenda that naturally leads to a competitive context, I would keep it light and try to achieve an "everyone wins" model.

Once on site, the role of the host is one of making sure quality conversations are being had. Team size and makeup is important; teams that are too large and too full of strangers tend to get bogged down in establishing a process and buying in on a project idea. Teams that are too unbalanced in their skillsets get bottlenecked. Teams entirely consisting of friends can usually be very productive, but sometimes the event just becomes a vehicle for whatever they planned to do(which is not always bad). The host can help in all of these by using their position to reach out and make connections that the teams aren't inclined to make on their own.

After the event is over, it's time for followups. A little push can help everyone finish and clean up their project - if you offer to put their project in the spotlight, they'll do a little more than they would if they feel like it's a throwaway, and they'll develop more of a lasting connection with you, the organizer.

I've been to around a dozen in the past year, here's my take:

Stable Wi-Fi. Don't charge for admission. Adhere to a strict fresh code rule. Limit teams to 4 or 5. Stick to your judging criteria (fun, business, innovation -- whatever it is, be consistent from start to finish) and find non-sponsor judges to choose the overall winners of an interestingly themed challenge. Provide enough water and food for everyone. If you're hosting it in San Francisco, there are plenty of hungry people who will eat the leftovers. Have 2 rounds of presentations if there are more than 30 submissions. Have someone go around and tell hackers to simplify their ideas and explain the meaning of a weekend MVP.

Follow these and you should have an acceptably successful hackathon. If you want to be memorable though, try something new!

Hey! I'd love to learn more about your favorites of the ones you've been to- would you mind sharing which ones they were?

Sure! They've actually varied a lot and I've liked them for different reasons, but across all categories I can say I don't like science fair style, really appreciate non-pizza food, and won't wear low-quality t-shirts more than once.

Competitive: Salesforce, Capital One, and AngelHack events are fun because there's a clearly defined goal and some concrete metrics. I really enjoy seeing the pitches at the end and thinking about how we all interpreted the challenge and responded.

Creative: YC Hacks, GitHub Music Hack Day, Yo Hackathon, and Brainihack all elicited some pretty fun stuff. I missed the Brainihack this year though, too bad! Techendo was pretty cool too, albeit small.

Cooperative: Some hackathons had lots of small prizes or none at all. Paypal Battlehack was really fun, a Change.org hackathon was stress-free and friendly, and I learned a lot at a Swift "hackathon" where even the smallest accomplishments were celebrated.

I haven't been to any college hackathons yet, but I'm looking forward to Hacking EDU in October!

I've done quite a few hackathons and can speak to this a bit. Feel free to email me if you have more detailed questions. Here are some of the things that have stood out to me over the years (good and bad):

- Be clear on what you want people to build. Some hackathons want a cool hack or feature while others want a prototype/MVP that could be an actual startup.

- Have real prizes (cash and/or useful things). I was at a healthcare hackathon recently and the prices were ... engraved plaques.

- Have some real, experienced VCs help with the judging. They are generally good at knowing what's actually useful and spotting BS. Plus they're a good draw because people love to network with them and hear them speak.

- Get other companies and services involved by offering sponsor or API prizes. A big, "winner-take-all" hackathon isn't fun. If you don't win the grand prize, it's nice to know you might still win a gift card or iPad from a sponsoring company. It should be easy to get such companies involved (cheap exposure for them).

- I don't like "science fair judging" (i.e. judges walk around to each group/table and do a private demo). Make everyone present with a time limit and a projector. Part of hackathons IMO is being able to present your product and do a live demo under pressure. If it's a big hackathon, you might need 2 rounds of judging ... but it's the best way.

- Require entries to be new, working software or hardware. Unless you're explicit, people will try and enter anything from mockups, powerpoint slides, to a "feature" bolted on to an already existing product/service.

- I think 36-48 hours is the sweet spot for time. But I personally don't work through the night.

- I've seen some hackathons require teams (i.e. no solo people). I don't see the point. A max size of 5 or 6 is a good idea but there's no good reason to not let people enter alone. You can even have a category "solo" winners.

- Despite the above, people will still cheat. Don't sweat it.

- Good wifi

- T-shirts ... lots of t-shirts

Hope that helps. The best hackathons I've been to were AngelHack, Twilio, and On Deck Cup.

From my experience of going to 20+ hackathons, few things come to mind

1. Have a well defined target audience and reach out early. People make weekend plans.

2. Be very clear about judging criteria.

3. Heavy presence of organizers throughout the event. It's not always easy for newbies at hackathon's, and organizers/mentors being around during the whole thing is great motivation.

4. A good venue where people can find quiet space/at the same time space to socialize.

5. Find a good balance between cheerleading during the hackathon and people working. Sponsor events are important, but continuous interruptions do not help flow work.

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.

This would be pretty interesting. Personally, Im super competitive, and I've found most others are too.

About 4 hours from presentations at my first Startup Weekend, we drastically needed to downscale what we were trying to do. I asked my team "Do we want to build this product, or do we want to win?". All of them said "Win."

And so we did. But that app that won Startup Weekend never saw the light of day, so what was the point?

:-)

It all goes back to what the point of the hackathon is really.

For hackathons that are about people actually starting a project and continuing it afterwards (and certainly the Startup Weekend organisers I've talked to locally say this) I think this is the massive blind spot of hackathons - in reality very few projects will continue afterwards. I've seen many things tried to help improve this, and I don't know what the answer is - but I haven't seen anything about the judging helping.

(Edit: congrats on winning tho ... um, after what I've just said!)

How about peer to peer judging? At the end everyone gives a score on different aspects on say 10 other projects, like in Ludum Dare.

I've never done Ludum Dare, so I'd be curious to see how that worked and what kind of vibes it set up between teams. After all, it's still judging.

It feels less arbitrary when you have a lot of different people looking at what you made, all of whom also just spent 2-3 days tirelessly toiling on their own projects.

Fair enough, but the fact it can be arbitrary is not my fundamental issue. Why does it need to be judged at all? Why can't they just say "Cool, we all made a game!" and then leave it that? What is achieved by having scores, and bearing mind a lot of ppl are going to be disappointed by bad scores, is it worth it?

I'll answer the opposite question; follow none of this advice and you'll probably have a winner.

How to make an awful hackathon:

1. Familiarize yourself with the "hacker league" but don't affiliate with them; better yet, check their schedule so you can pick a date that conflicts with a better hackathon in the area.

2. Require that all submissions be new work, but limit the winners to people who have demonstrably worked on their entry for weeks.

3. This one I picked up from TechCrunch Disrupt SF- determine how much square footage your hackathon used in previous years, then try to cram the next year's into a space half that size.

4. Also from TechCrunch- get some A-list VC's to speak, then put no effort into soundchecks to ensure people can actually hear them.

5. Put no one in charge of making sure the event is lively and safe. If participants get the laptop stolen out of the backpack they're using for a pillow, or get drenched by a super soaker, that's their own dumb fault for bringing a computer to a hackathon.

6. Make all of your prizes in-kind donations of services that hackers either already have in spades or would never use, like discounted Rackspace hosting, entry-level coding classes, or unpaid internships with your own firm. Never offer cash, as the best hackers treat cash offerings as an insult to their professionalism. If you have to offer cash, make the cash a nominal amount, like $10. Better yet, make it a starbucks gift card for $15 - whatever your favorite drink was when you bought it. During the awards ceremony, announce the recipient of the card but never see they get it.

7. Start advertising for your event three months out, then stop the advertising two and a half months out when you run out of time or money. Make sure no one carries any updates about your event so it can happen quickly and quietly. Only the best hackers will show up because they hate competition, have long memories and mark their calendars. Advertising really is a waste of money and most people spend way too much on it.

8. Make the presentation process as frustrating as possible for presenter and participant alike. Give people less than 5 minutes to present their idea, and ensure that everyone spends at least 3 of that trying to figure out how to make your AV system work. Ensure you're violating the fire code by making the space small, and make the speakers and projector (not projectors) undersized. Make sure your projector connection is Thunderbolt (for windows-themed hackathons) or HD15 VGA (for Mac-themed hackathons).

9. Charge for admission to make clear how you're underwriting the event. If you offer $5000 in prizes and expect 100 hackers to show up, charge $100 per entry. Better yet, offer a dual-tier charging structure so prospective investors and members of the public pay nothing. Don't bother checking if the free tier submits entries. Also encourage the free tier to mingle with the hackers while they work. Hackers need suggestions.

10. Cater the event by the lowest bidder. Costco pizza and Coca Cola products are looked upon fondly by hackers because they don't care about their health. Offer lunch leftovers for dinner, dinner leftovers for breakfast, and so on. You should only really need to place one order of food. Offer an unappetizing vegetarian option and don't label it. Leverage your frugal use of space by doubling hacker workspace as the line for the food.

11. Ensure your event has too few bathrooms and too few garbage cans. People can crap and throw their trash away at home.

12. When winners are announced, do it on the down low. Don't put that information on your blog, so when 2019 rolls around and someone wants to find out who won or attended, they can't.

13. If your projections show you'll be able to sell 1000 tickets to hackers at $50 each, use an easily-gamed system that makes 2 batches of 250 available for $25 each at random unannounced times. Selling out your event ensures the highest quality of hacker.

14. Buy (6) 3' power strips from Costco and leave them unopened in a corner of the space. For Wifi, use whatever the building already has available. Make the wifi password more trouble to ask for than it's worth.

Check out guide.mlh.io for a really detailed walkthrough of everything you need to run an awesome hackathon.

The MLH guide is student focused but you should still be able to get a ton of great advice out of it!

If you're planning on being more business oriented startup weekend has a similar guide.

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

We did a hackathon today. Several things made it a successful hackathon. First; a Product Owner ran the early brainstorming and problem setting. This made a big difference. The engineers were coming up with new products but with the discipline of what works in defining a real product.

Next they broke up into teams of two or three and worked on a specific product idea or feature/improvement. There was a break in the middle of the day when everyone had lunch together, and then back into coding afterwards. The hackathon started at 9am and ended at 4pm with every team having working features to demo.

At least one of the features demo'd will go straight into the existing product, the others will be demo'd to other stake holders and will most likely end up in the existing product but as a more polished feature.

So in summary having a Product Owner over see the brain storming, having everyone work in the one branch together in small teams, and making the new features or products demo'able by the end of the day.

There is a lot of good advice here, but let me add my 2 cents

1. good wifi - a lot of hackathons are not prepared for the number of devices connected when 100 people arrive...

2. set a clear schedule. My favorite is Fri night - intro session, people present ideas, team building Sat morning - starting to work 10am workshops at 11am end of coding Sun at 12pm presentations Sun 1-3pm Judgement - 4pm

3. team building is a critical part in the event. I normally have a few people from the organizing team helping people find who to work with. We have tried using colored stickers for different expertise - developers, designers, ideas, FEDs, etc. Most hackathons do not have sufficient designers.

4. Food - keep in mind that Pizza is great for males. But women may like lighter food. Given you have an over-night event, you need to take care of that. Same goes for beer - have a wine option

5. As many organizers as possible in the event. People have questions and need help all the time. The more people you have to help the better.

Sandwiches from a local deli make awesome lunch. One hackathon I went to had these ginormous bean bag chairs, so that was cool. Don't make people attend certain sessions/presentations. You can offer them for those interested, but don't require attendance. Having a very open prompt/challenge is appreciated. If you want to make it more specific, that's fine, but keep it open ended within that specific theme. i.e. "do something creative related to xyz and abc", not "design a solution that will do xyz and also does abc and of course meets the criteria of jfk".

I haven't been to many, but I'll throw in my 2c regardless.

- Venue. The space available can make a _massive_ difference in how people collaborate and get creative.

- Prizes. Most people need external motivation as well as internal motivation.

- Time/Convenience - I'd put it on a weekend. Most people (students, working adults alike) can't afford to use credit hours on a hackathon, regardless of what the prize is.

- Sponsors. The greater and more "prestigious" the sponsors are, the more likely teams are to network and get assistance in valuable ways. Mentorship is the most valuable part of the MLH hackathons I have attended.

We need more 'hack' and less 'thon'

Too many hackathons try to motivate people with incentives, but that creates winners and disappointed people.

I think a 1-day, or 2-day hackathon with a no pressure show-and-tell keeps people excited, motivated, and happy. It should be about the joy of hacking, but in community and in a great setting where people with different strengths are able to share and try out new ideas. It shouldn't be a race against the clock where everybody does what they do best to compete - it should be a safe setting where people can experiment and dabble and mingle.

I do a lot of hackathons. My record is 4/26 for winning 1st, 16/26 for winning 1 or more prizes, mentored 3 times and judged once.

Do it on a weekend, have interesting sponsors with prizes, and make the judging/presentation criteria very clear from the start. Also attendance can be hard to estimate, not everyone will show up and not everyone will come back, plan accordingly.

Also, three pieces of advice I always give at hackathons:

  1. work backwards from the presentation
  2. only build what you show
  3. only show the interesting parts

Happy to mentor/judge, mat@tinj.com.

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.

From personal experience: Pay the winners!

hackathons seem to divide into two main types - one where people get together to build stuff and advance the state of a (usually popular) open source project via a concentrated sprint, and the other where people or teams compete for prizes.

personally, the latter strikes me as betwixt and between - if i wanted the competition, i'd rather enter a pure programming contest with explicitly artificial problems and well-defined judging criteria, and if i wanted to build something i'd rather be doing it cooperatively than competitively.

@idbthor I run a wearable/iOT hackathon called WearHacks.com and I tried reason from first principles.

What is essential for a hackathon? 0- Branding: Sponsorship Decks and "About us" documentation. 1- A Venue 2- A Food provider 3- Sponsors 4- Judges 5- Mentors

Make Three teams:

Operations: In Charge of the schedule/logistics and 1,2

Sponsorship: In charge of 3,4,5

Community/Marketing: In charge of getting the hackers and can help get community mentors.

Hope I helped! If you have any other questions email me at shehaaz @ WearHacks.com

It really depends on how big of a hackathon you are running. In the previous year I have organised one ~50 person hackathon, and one ~200 person (part of a larger 1500 person event). Vastly different logistics.

Have a read of the Hack Day Manifesto, as it will probably trigger at least one 'aha!' moment of something you forgot: http://hackdaymanifesto.com/

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.

* all participants retain 100% ownership of all digital assets produced during the hackathon

^ if that's included then it some kind of a scam IMHO. Why would an team want to program in a legally onerous environment as opposed to say, a mall food court ?

Rigid flexibility. Have a well defined end goal, with judging criteria available from the start, but don't restrict contestants in what resources they can use, tech, people, etc

Assign people a random team. Try to make sure each team has people with different skills, so that everyone can bring something to the table.

Good internet connectivity.

Learning something.

Meeting people.

Good food.

If the participants are teaming up to produce a product, there needs to be some agreement on how any resulting equity will be divided. You can't just assume they'll split it equally.

Just make sure that there is enough Apple equipment in the room and that the hackathon itself produces a lot of useless stuff that no one will ever need. Perfect hackathon.

idk that doesn't sound like it's focused enough on the benefits of proprietary apis or flashy UIs