Ringers Are Fine, Mislabeling Is Not

Ringers are fine. Mislabeling is not. The ringer team — a funded startup, a hardware-rich team, a group whose project has been in development for months before the event opens, a team whose members include former employees of the sponsor — is a documented and persistent presence in open hackathons. The case literature is well established and the patterns recur. The Book's position on the underlying issue is structural rather than moralistic: the problem is not that funded teams attend hackathons, the problem is that hackathons accept funded teams without saying so, and the participants who walked in expecting a fair fight discover only at the closing ceremony that they were never in the same competition as the team that won.

The 2013 Salesforce $1M Hackathon is the canonical scandal of the underlying dynamic, and the case study salesforce-1m-2013 handles it in depth alongside the related themelessness failure that the-frame already discussed. The structural feature of that case worth naming here is that the event's published rules contained no provision against pre-existing work, which made the team that won — Upshot, two people, one of whom was a former Salesforce employee, with a project in development for over a year — formally eligible. The team followed the rules as written. The rules as written were not the rules participants thought they were entering, and the disconnect between the published rules and the implicit student-fair-fight expectation is what made the case a scandal rather than a routine recruitment-pipeline win. The lesson is not that funded teams should not attend hackathons. The lesson is that hackathons should label themselves clearly enough that participants can decide whether the event is the kind of event they want to enter.

The three-class taxonomy the Book proposes makes that labeling operational. Class A is the student fair-fight event. Eligibility is restricted to students or first-time hackers; pre-event project work is prohibited; the integrity mechanics covered later in this essay apply. The MLH-supported university season hackathons — HackMIT, PennApps, TreeHacks, Calhacks — are paradigmatic Class A events, and the league's standard rules language is the working template for what Class A looks like when implemented well. Class B is the open competition event. Funded teams are welcome; pre-existing work may or may not be allowed depending on the event's specific rules; an optional separate prize pool for first-time hackers (a "majority- novice" sub-prize, as HackDuke runs alongside its main tracks) mitigates the dominance funded teams would otherwise have. ETHGlobal's events sit squarely in Class B — funded teams attend, builders ship production-bound work, and the partner-prize structure assumes participants are bringing pre-existing context to the event rather than starting cold. Class C is the recruitment and pipeline event. Sponsors and recruiters are listed prominently. Funded and pre-existing teams are not just permitted, they are expected — they are the point. TechCrunch Disrupt, Startup Weekend, AngelHack Global Series, and Y Combinator's AI Startup Schools all advertise themselves as Class C events, and the groupme-techcrunch-disrupt case shows how the hackathon-to-acquisition pipeline operates when an event is honestly labeled as such.

The class label belongs on every page of the event where eligibility is mentioned. The registration page, the rules page, the FAQ, the problem statements, and any sponsor outreach should each make the class evident. A reader should never wonder which class the event is. This is the disclosure half of the principle, and it is the half that most events get wrong by omission rather than by malice — organizers who have an implicit picture of their event in mind do not always recognize that participants who do not share their picture will arrive with different expectations. The fix is to write the picture down.

The integrity mechanics are the enforcement half, and they apply primarily to Class A events because those are the events that have committed to a fair-fight format and need structural means to maintain it. The mechanics are well-developed across the field and operate together as a stack. MLH's standard rules require explicit language stating that participants cannot work on their project before the event and that submissions should not be reskins of an existing AI tool, focusing on what was created, changed, or built during the weekend rather than what was merely used. ETHGlobal's submission rules require participants to document where and how AI tools were used, specifying which parts of the code, files, or assets were generated or assisted. Devpost-listed projects like .gitcheck automate timeline audits by analyzing GitHub commit history against the official hackathon window to detect pre-existing or suspicious development activity — the tool is freely available and works for any event whose participants commit publicly. MLH operates a cheating@mlh.io reporting channel and disqualification escalation path for events in the league's network, providing an external accountability structure that any single organizing team would struggle to maintain on its own. Many Class A events further restrict participation to students or first-time hackers, or run majority-novice sub-prizes inside their tracks, which mechanically excludes most well-funded ringer teams without requiring a case-by-case judgment. The mechanics exist. They just have to be applied.

The objection that surfaces against this principle is that ringer- detection is paternalistic — that hackathon participants are adults capable of competing against whoever shows up, and that organizers who police eligibility are infantilizing the participants they claim to serve. The objection misreads what the principle is doing. The Book is not arguing that funded teams should be banned from hackathons. The Book is arguing that participants should know what kind of event they entered. A college student who flies to a Class A event with a four-person team and discovers at the closing ceremony that the winners were a funded startup with two years of pre-existing work has not been infantilized by better disclosure rules; they have been failed by the absence of them. The ringer team is fine. The mislabeling is the failure mode.

The format taxonomy format-taxonomy shows which of the ten working hackathon archetypes lean toward which class by their nature — Single-Problem Competitions and University Season Hackathons toward Class A, Sponsor-Bounty Federations and Platform Ecosystem Challenges toward Class B, Founder-Track events toward Class C. The goal principle the-goal is what the class label operationalizes — events whose stakeholders and outcomes assume student participants need different integrity mechanics from events whose stakeholders and outcomes assume founder participants. The AI-era principle ai-era covers why attribution discipline matters more now than it did five years ago, and why ETHGlobal's and MLH's AI-attribution rules are not peripheral additions to ringer enforcement but central to it. And the case studies salesforce-1m-2013 and groupme-techcrunch-disrupt work the canonical cases of mislabeling and honest labeling respectively, with the contrast between them making visible the structural lesson the principle as a whole rests on.