GoodFirst : I built my friend a way into open source.

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend What I Built My friend Shivin wanted to get into open source this October. He could code. What stopped him was everything around the code. He'd open a real project, see a long README and a hundred open issues, and the questions piled up before he wrote a single line: Which of these files actually matter? How do I even run this? Which issue is small enough for a first try? Which programs exist for beginners like me, and when do they open? So I built him GoodFirst. Paste a GitHub repo and ask a question in your own words ("I know some JavaScript, how do I run this locally?"). A local Gemma model answers from the project's own docs, maps out the files that matter, and picks three good first issues, each with a reason it fits and a place to start. A second page lists open source programs (GSoC, Outreachy, LFX Mentorship and more) with official dates, and shows which ones are open, live or not announced yet. Two rules shaped all of it: It runs on a laptop like Shivin's. Windows, 8 GB of RAM, no GPU. No API key, no account, no bill. It never pretends. A small model gets things wrong. Anything GoodFirst can't verify against GitHub gets crossed out, right there on the screen. Demo - Paste a repo and an optional question. - A live timeline shows each step as it happens: reading the repo on GitHub, Gemma reading the docs, choosing issues, checking every claim. - You get the answer, a short summary, setup steps, the important files and three issues. - Next to it sits the evidence panel: every claim the model made, where it came from, and whether it was verified, flagged or removed. Code GoodFirst Your first green square starts here. GoodFirst helps beginners make their first open source contribution. Paste a GitHub repo and (optionally) a question. GoodFirst answers the question from the repo's own docs, maps out the files that matter, picks three good first issues, and shows the evidence for every claim it makes. Anything it can't back up with what GitHub returned gets crossed out. When your pull request's checks go red, it reads the failed log and explains what broke. The AI is Gemma, an open-weight model, running on your own computer through Ollama. There are no API keys and no hosted LLM calls, and GitHub is only ever read, never written to. Built for the DEV Hacktoberfest 2026 Weekend Challenge, "Build for a Friend". Why I built this: Shivin My friend Shivin wanted to make his first open source contribution. He had picked a project AOSSIE-Org/DebateAI… How I Built It Stack: Gemma 3 4B on Ollama · LangGraph · FastAPI with streaming · Next.js + Tailwind · GitHub REST API (read-only, never writes) 1. The model doesn't drive I didn't build an agent that decides what to fetch. Code fetches the README, the contributing guide, the file tree and the beginner-labelled issues, cleans them up and trims them to fit an 8K context. Gemma gets one narrow job per step, in a fixed graph: fetch → explain → pick_issues → honesty_check Every answer must match a JSON schema, passed straight to Ollama's structured outputs: msg = self.model.invoke( [SystemMessage(content=system), HumanMessage(content=user)], format=json_schema, # Ollama forces exactly these keys ) Broken JSON gets one retry, then an honest "couldn't get a usable answer." No made-up fallback. It sounds limiting, but with a 4B model on a CPU, this is what made the output trustworthy enough to hand to a friend. 2. The honesty layer After Gemma answers, plain Python checks every claim it can against what GitHub actually returned: | Gemma says | Checked against | If it fails | |---|---|---| | "Look at this file" | The repo's file tree | Removed | | "Run this command" | The README and contributing guide | Flagged | | "Try issue #123" | The fetched issue list | Removed | | "Here's your answer" | Same file and command checks | Docs don't cover it? A question for the maintainers instead | Issue titles, links and labels always come from GitHub, never from the model. Each invented file or issue costs 10% confidence. Below 60%, GoodFirst stops sounding sure and writes a polite question you can paste to the maintainers instead. 3. What a small model taught me - Asking for "JSON" isn't enough. Gemma returned valid JSON with keys missing. A real schema fixed it. - "Pick three" sometimes got one. minItems: 3 in the schema fixed that too. - Hinglish took three tries. I added an English/Hinglish toggle because that's how a lot of us talk. Gemma ignored it, then copied my example word for word. A neutral example plus a reminder at the very end of the prompt finally worked, and GoodFirst warns you when the answer still comes back in English. - Being helpful backfired. When Gemma gave fewer than three valid picks, my code topped up the list from its own ranking, and once that added a bad issue. Now it only tops up with issues that score well. Fewer picks beat a bad suggestion. 4. Is it fast? No. On my 8 GB laptop, with the model already loaded, explaining a repo takes about 75-85 seconds and picking issues about 30-37. That's the trade: two minutes of waiting in exchange for free, private and offline. The live timeline helps, because you can see exactly what it's doing while you wait. The hand-over Shivin used it and opened his first pull request. Then the checks went red. The CI log was about 2,500 lines long, and somewhere in there was the one line that mattered. He had no idea which one. That's a brutal moment for a beginner: the hardest part is done, the PR is finally open, and a wall of red text says you broke something. I'd built GoodFirst to get him to his first PR, and hadn't thought about what comes right after. His very first real use found the gap. So I added CI help: paste the pull request, and GoodFirst pulls the failed checks and their logs, cuts the log down to the part around the error, and explains in plain words what failed, why, and how to fix it. The same rules apply. Every log line it quotes must exist in the real log, or it's removed. Every file it names must exist. And for the question every beginner asks, "was it my change?", GoodFirst doesn't just trust the model. It checks in code whether the error mentions a file the PR changed. Why Does Open Innovation Matter? - It's free. A beginner shouldn't need a credit card or an API key to get help reading a README. - It runs on what he already has. 8 GB of RAM, no GPU, and it works offline once a repo is cached. - It's private. The "dumb" questions beginners are scared to ask in public never leave the laptop. - I control the whole pipeline. I can pin Gemma to a schema, swap 4B for 1B with one setting, and wrap it in checks I can read and change. With a closed API you work around the model. Here I could build around it. A frontier model would write nicer paragraphs. It would also cost money, need an account, send everything to a server, and sound just as confident when it's wrong. For a first-timer, a small model that proves its claims beats a big one that doesn't. Prize Categories Best Use of Gemma. Top comments (0)