3 ms·

This is a general problem for hackathons, the idea of limiting something like development is impossible. Even if you don't code, you could plan the whole conce

by sek 13y ago

This is a general problem for hackathons, the idea of limiting something like development is impossible. Even if you don't code, you could plan the whole concept, user your super familiar framework and there is a huge difference to the "spirit" of just developing the concept on the spot. I don't want to say I dislike hackathons in general, but not for huge prices. Just meeting interesting people and trying to build something together is the really valuable part.

resu_nimda 13y ago
There are a number of ways to combat this. - Have a theme, a dataset, or some other component that is not announced until the day it starts (and to be eligible an entry must demonstrate meaningful incorporation of that component). - Have a manageable organizer-to-participant ratio so they can do a decent job of verifying that teams aren't using a developed concept. - Don't allow premade teams, have individuals pitch concepts and form teams. Each of those can be gamed to some degree, but they can go a long way, and to game them requires serious intent to deceive. They didn't even try, at all. The winner was openly a fully formed startup that demoed their app at a Salesforce meetup weeks before the hackathon. That's just, mind-blowing.
- saryant 13y ago
  There's another good way to eliminate these concerns: don't have big prizes. When I hosted a hackathon last summer, I put no limits on projects but the max value of the prizes was $25. With prizes so small, there's no incentive to game the system nor is it grossly unfair to let people work on something they'd already started on. The goal was purely to work on something cool for a day with like-minded people. One guy brought on a voice-controlled Nest lamp he'd been working on, another built an Arduino step-counter, a third took a crack at writing a basic chess AI. We provided pizza and beer and just let everyone loose. It went great and there were no hard feelings.

by sek 13y ago

resu_nimda 13y ago

There are a number of ways to combat this. - Have a theme, a dataset, or some other component that is not announced until the day it starts (and to be eligible an entry must demonstrate meaningful incorporation of that component). - Have a manageable organizer-to-participant ratio so they can do a decent job of verifying that teams aren't using a developed concept. - Don't allow premade teams, have individuals pitch concepts and form teams. Each of those can be gamed to some degree, but they can go a long way, and to game them requires serious intent to deceive. They didn't even try, at all. The winner was openly a fully formed startup that demoed their app at a Salesforce meetup weeks before the hackathon. That's just, mind-blowing.

saryant 13y ago
There's another good way to eliminate these concerns: don't have big prizes. When I hosted a hackathon last summer, I put no limits on projects but the max value of the prizes was $25. With prizes so small, there's no incentive to game the system nor is it grossly unfair to let people work on something they'd already started on. The goal was purely to work on something cool for a day with like-minded people. One guy brought on a voice-controlled Nest lamp he'd been working on, another built an Arduino step-counter, a third took a crack at writing a basic chess AI. We provided pizza and beer and just let everyone loose. It went great and there were no hard feelings.