Hacktoberfest 2026: Four Years In, Five Projects Built, and a Different Kind of October
Every October, Hacktoberfest gives me another reason to show up for open source. But this October felt different. For the past three years, my Hacktoberfest experience had largely revolved around learning how to contri
Every October, Hacktoberfest gives me another reason to show up for open source.
But this October felt different.
For the past three years, my Hacktoberfest experience had largely revolved around learning how to contribute, understanding open-source communities, and finding ways to make meaningful contributions.
This year, I found myself doing something different.
I started with a weekend challenge, then spent the following four weeks building through Hacktoberfest's weekly DEV Challenges. I experimented with open-weight AI models, built five projects, joined MLH Global Hack Week activities, followed community livestreams, and participated in an online programme that kept giving me something new to explore throughout October.
By the end of the month, I had completed all six DEV Challenges, earned the Completionist and Completionist++ milestones, and unlocked 25 out of 28 virtual stickers.
I had also registered for an in-person Hacktoberfest event in Lagos. Unfortunately, I wasn't in Lagos during October, so I couldn't attend.
It was a month of building, learning, showing up, and occasionally discovering that the thing I thought was working wasn't quite working.
Looking back, I realise that Hacktoberfest 2026 wasn't just another edition of an event I had participated in for four years. It represented another shift in how I approach software development and open source.
Four Years of Showing Up
My Hacktoberfest journey started in 2023.
Back then, I was still figuring out how open source worked. Git, pull requests, repositories, contribution guidelines, and communicating with maintainers were all part of the learning curve.
In 2024, I became more conscious of the context behind contributions. It wasn't enough to find an issue and submit a change. I was beginning to understand the importance of the project, its maintainers, and the people who would eventually use the contribution.
By 2025, my reflection had shifted towards impact. I wrote about three years of participation, the lessons I had learned, and the evolution in how I approached open source.
Hacktoberfest 2025: Three Years, Three Lessons, One Evolution
One thing I took away from that year was the desire to move beyond identifying and documenting problems to building solutions myself.
Then came 2026.
This time, I wasn't just looking for repositories to contribute to. I was creating projects of my own, testing ideas, working with local models, and thinking more deliberately about the systems behind the tools I was building.
Four years in, Hacktoberfest had become more than a contribution challenge. It had become a marker of how I was growing as a developer.
Hacktoberfest 2026: A Different Kind of Challenge
This year's Hacktoberfest came with a significant change.
Instead of focusing on counting pull requests, the programme put the spotlight on building with open-weight models and open-source AI.
The theme was:
AI belongs to everyone.
Powered by MLH and DEV, Hacktoberfest 2026 brought together online activities, Global Hack Week, weekly DEV Challenges, community livestreams, and more than 500 in-person Fests across over 70 countries and territories.
The official recap reported 115,385 participants.
I liked that the programme encouraged people to experiment and build rather than making the number of pull requests the central measure of participation.
That change also shaped my October. I had several opportunities to explore AI through practical challenges, and I ended up building projects that I probably wouldn't have attempted in quite the same way otherwise.
But the projects were only one part of the experience.
A Month of Learning Beyond the Projects
MLH Global Hack Week
Global Hack Week was one of the biggest parts of my Hacktoberfest experience.
It brought the familiar MLH Global Hack Week format into the month: online mini-events, activities, community participation, and livestreams covering different topics.
Some sessions involved building projects live, while others offered opportunities to learn about tools, technologies, and ideas from different speakers and participants.
There were days when four to six livestream sessions were happening. There was always something different to explore, and I enjoyed being able to follow along, learn, and participate in the wider community.
My Hacktoberfest dashboard showed all seven labelled livestream activities completed and five out of six Global Hack Week activities completed.
The seven livestream activities on the dashboard shouldn't be mistaken for seven individual livestream sessions. There were multiple sessions throughout the programme, sometimes several in a single day.
I wouldn't describe the experience as simply watching videos. It was about being part of a learning environment where people were building, sharing knowledge, and exploring ideas together.
The Weekly DEV Challenges
The DEV Challenges gave the month another structure.
There was a weekend challenge before the four weekly challenges, and I completed all six challenges in total.
Each prompt offered an opportunity to explore a different idea and turn it into something tangible.
Rather than spending the entire month on one large project, I got to experiment with different use cases, technologies, and approaches to building with local AI.
This is where the five projects came from.
Participating Online, Missing the In-Person Experience
One thing I appreciated about this year's format was the combination of different ways to participate.
I could work on my projects independently, join online activities, follow livestreams, and still feel connected to a larger event happening across different parts of the world.
The online programme made it possible to participate even when attending a physical Fest wasn't an option.
I had actually registered for an in-person Hacktoberfest event in Lagos. Unfortunately, I wasn't in Lagos during October, so I couldn't attend.
I would have loved to meet other builders in person, connect with the local community, and experience one of the Fests firsthand.
It didn't happen this year, but I was glad that the online programme still gave me so many opportunities to participate.
My dashboard recorded no in-person Fest attendance, but it certainly wasn't an inactive October.
Five Projects, One Weekend Challenge, Four Weeks of Building
The most visible part of my Hacktoberfest 2026 was the five projects I built through the weekend and weekly DEV Challenges.
They were different in purpose, but a common question gradually connected them:
How do we build useful AI systems without blindly trusting what they generate?
That question became particularly important as I worked with local models and started thinking about validation, evidence, and the limits of generated output.
Weekend Challenge: Rayor's Treat Assistant — Local AI for a Real Business Problem
I started with a practical problem: helping my neighbour's food business answer questions about its products and prices.
Rayor's Treat Assistant became a local AI price-list helper. Rather than building another general-purpose chatbot, I wanted something focused on a specific task: answering questions using the available price-list information.
I tested it against a list of 17 questions, and it answered all 17 correctly. My neighbour also tried it herself.
That was encouraging, although I wouldn't confuse a successful test list with proof that a system is ready for every customer interaction.
The project reminded me that AI doesn't always need a complicated use case. Sometimes a small, well-defined problem is a better place to start.
Week 1: Ground Truth Walks — Can AI Predict What I'll See Outside?
This project was an experiment in comparing AI predictions with real-world observations.
I built a Rust CLI that asked a local model to predict what I might encounter on a walk. Then I went outside, observed what was actually there, and compared the predictions with reality.
Across three scored walks, my average error was 2.76. Gemma's error ranged from 9.12 to 11.41, depending on the context.
One example made the problem particularly obvious: a prompt variant predicted eight motorcycles on all three walks. The actual counts were 46, 46, and 44.
The model could produce plausible-sounding predictions, but plausibility wasn't the same as accuracy.
This project made me think more carefully about the difference between generating an answer and having evidence to support it.
Week 2: PawPitch — A Pitch Writer That Has to Earn Its Claims
PawPitch was a local AI pitch writer for beginner pet creators.
The idea was to help someone prepare a brand pitch without pretending to have experience, audience numbers, or previous collaborations they didn't actually have.
I built it as a Rust CLI using Gemma 3 4B locally. It included a private creator profile, a sample pet profile, a seven-day tracker, and validation rules designed to reject unsupported claims.
One boundary mattered more than the others: the model shouldn't invent achievements just to make a pitch sound impressive.
I wasn't able to test PawPitch with the person I originally had in mind. So, while I could test the implementation and its validation rules, I couldn't claim that it improved anyone's pitching process.
That distinction matters.
Building something for a real use case is not the same as validating it with a real user. Getting that feedback remains unfinished work for this project.
Week 3: JobKit — The Model Proposes, Rust Verifies
JobKit was my attempt to make job-posting triage more structured.
I used a local Gemma model to interpret job postings, while Rust handled verification of important structured claims.
I didn't want a model's interpretation to become a fact just because it returned valid-looking output.
My evaluation produced two results worth separating:
- Postings used during tuning, after fixes: 9/9 remote-status classifications.
- Postings not seen during tuning: 5/8.
The first result was encouraging, but it wasn't a general accuracy score. The second set was small, and its result was considerably less reassuring.
There was another uncomfortable discovery: the evaluation harness caught eight skills that I had labelled as present even though they weren't actually in the job postings.
Those were my mistakes, not the model's.
It forced me to look beyond whether the model was wrong and ask whether the evaluation data itself was trustworthy.
A verification system is only as useful as the evidence and labels you give it.
Week 4: Ofrenda — An Ofrenda for the Rust Crates That Went Quiet
Ofrenda was my final project for the month.
It's a Rust CLI that scans Cargo.lock files for dependencies that have gone quiet. It gathers information about crates, including release history, repository activity, and RustSec unmaintained advisories. A local Gemma 3 4B model then generates a short epitaph for each crate.
The important design decision was separating factual work from creative work.
Rust gathers the evidence. The model writes the epitaph. Rust validates the generated text against the available facts. If the model fails validation after three attempts, Ofrenda falls back to a facts-only card.
I tested it against three lockfiles: Statix, ripgrep, and bat.
The release-age heuristic flagged 52 packages and matched six of the seven entries in my RustSec reference set. That doesn't mean it found every abandoned crate. Release age alone is a weak signal, and RustSec's unmaintained advisories are a reference dataset, not complete ground truth.
The creative part was difficult too. In one run, only seven of ten epitaphs were accepted. Eight first attempts were rejected, mostly because they introduced unsupported technical terms or repeated words. Three still failed after the retry limit and received facts-only output.
One card made the limits of automated checks especially clear: bincode.
My release-age rule didn't flag it as old because its last release was on 2025-12-16. But RustSec's advisory, dated the same day, explains that the team ended development after a doxxing and harassment incident and considers version 1.3.3 complete.
That isn't ordinary neglect. It isn't a simple case of a project being forgotten. It's a decision made by people who had been treated badly for giving their work away.
My code could count releases and read dates. It couldn't understand that story.
The model-generated poem on the card hadn't seen that context either.
That is both the point of the checks and their limitation: they can stop a model from inventing certain facts, but they cannot give it understanding.
A card with no poem is better than a card with a lie.
The Numbers, and What They Don't Tell You
Looking back, the projects produced some interesting results:
| Project | One result worth remembering |
|---|---|
| Rayor's Treat Assistant | 17/17 questions answered correctly on my test list |
| Ground Truth Walks | My average error was 2.76, compared with Gemma's 9.12–11.41 |
| PawPitch | Validation rules built and tested; no intended-user test |
| JobKit | 9/9 on tuned postings; 5/8 on unseen postings |
| Ofrenda | Release-age heuristic matched 6/7 RustSec reference entries |
These numbers aren't directly comparable. They measure different things, and each has limitations.
I include them because I want to be honest about what I tested, what worked, and what still needs improvement. A good retrospective shouldn't turn every experiment into a success story.
What I Took Away From Hacktoberfest 2026
1. Building is only part of the work
Getting a project to run is satisfying, but it doesn't establish that the project solves the problem it was built for.
PawPitch reminded me that I still need real-user feedback. JobKit reminded me that test labels need scrutiny. Ofrenda reminded me that a technically valid output can still miss the human context.
2. AI needs boundaries
Across the five projects, I kept returning to the same idea: models can interpret, suggest, and generate, but important claims need evidence and important decisions need rules.
I became increasingly interested in the parts of AI systems that sit around the model: validation, data handling, deterministic checks, and the infrastructure that makes a system more dependable.
3. My own assumptions need testing too
I initially approached some evaluation results as if the test data were automatically reliable.
They weren't.
The JobKit experience was a reminder that building a verification layer doesn't make me immune to mistakes. I have to question my own labels, assumptions, and measurements as much as I question the model.
4. Community participation can take different forms
I didn't make it to an in-person Fest this year, but I still participated through Global Hack Week, livestreams, DEV Challenges, and other online activities.
I learned from sessions, followed people building projects live, and had a reason to keep showing up throughout October.
The online and offline experiences aren't identical, but both can create opportunities to learn and connect.
5. Open source is still about people
Ofrenda brought this lesson home in an unexpected way.
A quiet repository isn't automatically an abandoned project. A last release date doesn't tell the whole story. Behind every dependency is someone who spent time building and maintaining something that other people rely on.
Sometimes a project stops because its work is complete. Sometimes circumstances make continuing impossible.
We should be careful about the stories we tell with the data we collect.
Thank You for Four Years
To the Hacktoberfest organisers, MLH, DEV, the Global Hack Week community, the speakers, livestream participants, challenge creators, mentors, judges, maintainers, and everyone who shared knowledge or built something this October: thank you.
I appreciate the people who make these experiences possible, especially the maintainers who continue to give their time and work to open source.
I also used AI assistants throughout these projects. Their contributions varied. For Ofrenda in particular, Claude helped generate much of the Rust implementation. I directed the design, ran and tested the code, examined the results, investigated failures, and made decisions about the validation rules.
I don't want to present AI-assisted development as if every line came entirely from me. Equally, I don't want to understate the work involved in deciding what to build, checking what was produced, and taking responsibility for the result.
What's Next?
Hacktoberfest 2026 strengthened my interest in Rust, backend systems, local AI, and the infrastructure needed to build reliable AI applications.
I want to keep exploring systems where models can interpret and propose, but deterministic components enforce the rules that matter.
I also want to keep contributing to open source, learn from maintainers, and become more deliberate about testing my work with the people it is intended to serve.
In 2023, I was learning how to contribute.
In 2024, I was learning how to contribute with context.
In 2025, I was thinking more deeply about impact.
In 2026, I spent the month building, experimenting, and questioning my own assumptions.
Four Hacktoberfests. Different versions of me. And still more to learn.
Thank you, Hacktoberfest 2026. See you next October.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.