Skip to content

Hacktoberfest Ditched Pull Requests for Open-Weight Models

#hacktoberfest #open-source-ai #local-inference #ollama #gemma #open-weights

Hacktoberfest Ditched Pull Requests for Open-Weight Models ​

For twelve years Hacktoberfest ran on one bargain: open four pull requests in October, earn a T-shirt. This year the pull request counter is gone. No repo hunting, no PR target, no swag threshold.

The 2026 rules ask you to build a brand-new project with open-source AI at its core, then write about it on DEV. Five challenges run back to back through October, each with its own theme, each with the same prompt. Build with an open-weight model, an open-source agent framework, local inference, or any mix. Then explain why open innovation matters for what you built. You can enter every challenge, and each submission has to be built during that challenge's window.

That last detail matters more than it reads. A fresh start every week means someone who finds the event in week four competes on the same footing as someone who's been there since day one.

What the numbers looked like by week one ​

Organizers hoped for 300 in-person gatherings. More than 500 Fests are now planned across 60-plus countries, running from university hackathons to a handful of developers meeting at a library. In the first week, participants submitted over 3,000 projects.

Key Numbers

  • 500+ in-person Fests planned, against an original target of 300
  • 60+ countries hosting events
  • 3,000+ projects submitted in week one alone
  • 5 challenges through October, one submission each
  • $250 overall winner prize, plus $100 to $200 per partner category

Quick Take: the format change didn't just reshuffle the calendar, it pointed thousands of developers at local inference for the first time.

The COMSATS University group in Abbottabad, Pakistan, built three things in a single day: a locally hosted hospital-management platform, a multimodal companion for visually impaired users, and a tool that helps newcomers make their first open-source contribution. That's one Hack Day.

Two projects that show the pattern working ​

The submission I keep coming back to is called "Light don go." In Nigerian English, that means "the power is gone." A developer in Port Harcourt built it around a specific window: the grid cuts, the router dies, the laptop drops to battery, and nobody has started the generator yet. That gap is when the screen is already losing. The tool uses it.

psutil reads the power state every five seconds. A drop shorter than 30 seconds is a flicker and gets ignored. A second cut within 15 minutes gets logged but never triggers a nudge, so the grid flashing on and off doesn't spam you. When a real outage hits, a full-screen page opens over whatever you're doing, with a 60-second stretch timer, one simple plan, and a button that says "I don stand up. Close am."

The model part is where it gets sharp. Gemma writes the nudge. Code writes everything else.

The first version let Gemma write the whole message from the facts. In four test runs it dropped every number, and twice it inverted the meaning. One output read "E be like NEPA light don come Port Harcourt," which means the light came back. Another said "Close your laptop now, before the generator dies," but the generator wasn't running. Neither sentence had a number in it, so a numeric check caught nothing.

The fix split the job. Code computes the facts: what happened, when rain or sunset arrives, minutes left, naira saved. Gemma sees three things only, the place, the situation, and an activity picked by rule. It sees no numbers at all. A guard rejects any nudge containing a number, more than 20 words, or any mention of NEPA, light, power, or the generator. One retry, then a fixed sentence. Two model calls maximum, never a loop. After the split, nine of nine test runs passed first time.

The bug only a real outage could find ​

At 12:23 on October 8, the grid went down. The tool caught it and Gemma timed out. The developer measured before changing anything, and ollama ps showed the model had just been loaded, by the request that failed.

Ollama unloads an idle model after five minutes. The warm-up had run at 11:53. By 12:23, the tool hit a cold start on battery and took more than 20 seconds. The fix is one setting: keep_alive: -1, which holds Gemma in RAM at 3.9 GB of 15.7. The next cut, at 12:31, answered first time. A later cut at 13:34 timed out for a different reason. Windows Modern Standby had the laptop asleep. The event log showed it woke briefly at the cut, went back under, and woke again at 13:56 with the model still loaded.

That's the detail to copy. The default configuration broke the one promise the tool makes, which is to work when the power dies. No simulation surfaced it.

The measured performance on an i5-1135G7 with no NVIDIA GPU: 14 seconds cold, 3.6 to 4.0 seconds warm, roughly 15 to 20 tokens per second. The model is a 4.3 GB download. That's slow for a chat app. It's fine when the model writes one sentence of about 25 tokens, and the tool already waits 30 seconds to confirm the cut is real.

The second project, and a different kind of honesty ​

A submission called WildProof takes the same offline-first instinct somewhere else. It's a React and TypeScript progressive web app backed by FastAPI, Ollama, Gemma 2B, and Temporal. You pick a mission, walk outside, collect notes and photo evidence, then come back to a structured report.

The report schema is the design decision I'd steal for anything involving a small model. Every claim carries a confidence tag: observed, inferred, or unknown. Observed means the evidence directly supports it. Inferred means it's a reasoned deduction. Unknown means more evidence is needed. The product rule is blunt: never let a successful-looking report hide an unsuccessful analysis.

The backend asks Gemma for strict JSON and validates it against a Pydantic schema. Malformed JSON gets one repair attempt. If that fails, the app surfaces an explicit failure instead of manufacturing a report. The MVP is honest about its limits, too. Photos are stored as evidence references, not sent to a vision model. The text-only Gemma path sees notes and photo metadata only.

There's a scoring layer that uses TabPFN for evidence quality. When the installed TabPFN and Torch combination isn't available, the production endpoint falls back to a labeled baseline heuristic, and the UI says so. That kind of disclosure is rare in hackathon code.

The argument companies keep making ​

Meta's case for open models is the loudest version of this. The pitch borrows from Linux: closed Unix versions dominated early, then open source caught up on capability and won on ecosystem. Meta argues Llama 3.1 405B is the first frontier-level open model, and that running inference on it costs roughly half of a closed model like GPT-4o for the same tasks.

The self-interested reasoning is worth reading plainly, minus the marketing. Meta says its business isn't selling model access, so releasing Llama doesn't undercut revenue the way it would for a closed provider. It points at platform risk from Apple's rules as a reason to keep the AI stack open and controllable. Whether you buy the framing or not, the incentives line up.

A shorter manifesto, "Open source AI must win," pushes the argument past developer convenience. Its claim: if intelligence becomes something you can only rent, the public loses operational freedom, not just software freedom. The ability to study, repair, deploy, audit, and run intelligence systems without asking permission is treated as civilizational infrastructure. When a handful of labs control the models, the risk is a subscription economy for cognition.

Strip the rhetoric and the practical test is simple. Can you run it, inspect it, modify it, and keep running it if the provider changes direction or disappears?

What the community is saying ​

Reading through the comments on these submissions, the skepticism clustered in one place: volume isn't quality. Scanning 3,000 repos, people said they filtered immediately for commits in the last 30 days, issue response time, and whether the README explains how to run the project locally versus pointing at a hosted demo.

One point came up repeatedly. A lot of "AI projects" are thin wrappers around an API call. Useful for learning, not for production. The repos that hold up tend to have a test suite, a contributing guide, and at least one non-trivial dependency that isn't just an LLM SDK.

My team hit the same wall last year when we tried adopting a few trending repos from a similar list. The lesson was to stop sorting by stars. High stars often track a good demo, not a working pipeline. We started prioritizing repos with a clear contributing guide, a maintainer who answers issues within 48 hours, and sample data you can reproduce without setting up infrastructure. The fastest filter: clone it and run make test or pytest before reading a line of code. If the tests fail locally, the technical debt is usually deep and any PR you send goes stale.

There's a gap in what got built, too. The recurring patterns were vector database integrations, RAG pipelines, and agent frameworks, all pointed at the same few use cases: chat-with-docs, code generation, customer support. Fewer projects tackled domain-specific problems like logistics optimization, medical imaging, or manufacturing quality control. That's where the next round of submissions could stand out.

Common pitfalls ​

These break local-first AI projects in practice, not in theory.

Letting the model write facts. Give a small model numbers to reproduce and it will drop them or invert them. Code computes every number. The model phrases. Any claim you can't source from code or evidence gets a confidence tag.

Using default model unload settings. Ollama unloads an idle model after five minutes. If your app has to respond during an outage, a cold start on battery can blow past 20 seconds. Set keep_alive: -1 and budget the RAM, 3.9 GB in this case.

Gating on a single battery-drop event. A cut shorter than 30 seconds is a flicker. Without a threshold you fire the whole pipeline on every brief dip. Filter the noise before you do any work.

Fetching the network when the network is the thing that died. Cache what you need while power is on, then read only local files after the cut. The Nigerian tool saves the hourly forecast every 30 minutes and computes sunset with the NOAA solar formula on the laptop. A cloud API is unreachable at exactly the moment you need it.

Trusting stars over tests. Sort by maintenance signal, not popularity. Recent commits, active issue responses, a real test suite, and reproducible sample data matter more than a polished demo page.

The open-source AI stack, in one table ​

LayerClosed approachOpen approachWhat you gain
ModelGPT-4o and similar via APILlama 3.1, Gemma 2B / 4-E2B, local or hostedInspect, fine-tune, swap, run offline
InferenceVendor endpointOllama, vLLM, Groq, cloud-hosted open weightsNo per-call cost when local, latency you control
Data pathNotes and images sent to a vendorIndexedDB, local files, on-device computeSensitive data stays on your machine
WorkflowVendor retries, opaqueTemporal, your own retry policyFailures retry without losing collected evidence
OutputFree-form textPydantic-validated JSON, confidence tagsHallucinations become visible instead of hidden
Cost modelSubscription and per-tokenOne-time compute on hardware you ownPredictable cost, no price changes mid-project

Cold start versus warm inference ​

The gap between those two bars is the whole story of the cold-start bug. Warm, the tool responds in under four seconds, fast enough that waiting 30 seconds to confirm a real cut feels instant by comparison. Cold, it can exceed 20 seconds on battery, and the promise breaks. One setting closes the gap.

What this means for builders ​

If you're building anything that has to work when infrastructure fails, run the model locally and split the job. Code writes the facts, the model writes the tone, a guard checks the output. That architecture is why both projects here work at all on CPU-only hardware.

If you're chasing a Hacktoberfest prize, skip the crowded RAG and chat-with-docs angle. The categories with less competition are domain-specific problems, logistics, medical imaging, manufacturing quality control, where the open-weight model gives you a real reason to exist beyond a demo.

One thing to watch: the maintenance signal on these 3,000 projects will separate fast. Within a few months, the repos with active maintainers and reproducible test suites will look completely different from the ones with a great README and no CI. Follow the commits, not the stars.