
Ask HN: What makes a good hackathon? - ibdthor
We&#x27;re in the early stages of planning a hackathon with Heavybit (http:&#x2F;&#x2F;www.heavybit.com&#x2F;) but haven&#x27;t had much experience running an event like this.<p>What do you think makes a successful and enjoyable hackathon? Is it the prizes? Is it the theme? Would you prefer it on a weekend or a weekday? Anything else, big or little, that makes for a good hackathon?
======
bahador
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.

~~~
hkmurakami
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.

------
jeffbr13
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!

~~~
pshin45
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...](http://www.up.co/communities/usa/san-francisco/startup-weekend/5961)

[2] [https://www.eventbrite.com/e/startup-weekend-immigration-
tic...](https://www.eventbrite.com/e/startup-weekend-immigration-
tickets-16092734803?discount=hn)

------
devanti
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

~~~
delinka
"...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"?

~~~
devanti
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).

------
chipsy
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.

------
raymondgh
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!

~~~
hyoogle
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?

~~~
raymondgh
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!

------
callmeed
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.

------
avidas
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.

------
ElComradio
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)

------
jarofgreen
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.

~~~
Freeboots
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?

~~~
jarofgreen
:-)

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!)

------
mchannon
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.

------
thelonelygod
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.

------
schwentkerr
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

------
cam-
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.

------
yoava
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.

------
alex_g
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".

------
akhilcacharya
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.

------
err4nt
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.

------
flipside
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.

~~~
jarofgreen
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.

------
Raed667
From personal experience: Pay the winners!

------
zem
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.

------
shehaaz
@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

------
kelvinn
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/](http://hackdaymanifesto.com/)

------
natch
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.

------
code_reuse
* 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 ?

------
posnet
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

------
amenghra
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.

------
coherentpony
Learning something.

------
rasengan
Meeting people.

------
31reasons
Good food.

------
MichaelCrawford
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.

------
rtz12
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.

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

