Hacktoberfest 2026 has no pull request quota, and I think that frees you to do the kind of open source work that holds up. This year you earn stickers by learning and building, so you can spend October on something a maintainer would be glad to receive instead of something a counter would accept.
I have been involved in open source since 1999. This is how I would use this particular month if I were starting out.
What changed
DEV and Major League Hacking run Hacktoberfest this year, with DigitalOcean presenting. The theme is "AI Belongs to Everyone," and the focus is building with open-source AI tools and open-weight models.
The FAQ is direct about the rule change: "It's easier than ever to submit low-effort spam PRs to projects, so we're listening to maintainer feedback and no longer actively incentivizing PRs."
That decision has history behind it. In 2020, 169,886 people signed up and more than 621,000 pull requests were opened, many of them README punctuation changes, and maintainers called it a denial-of-service attack on their time. The rules moved to opt-in repositories and maintainer acceptance. In 2025 the bar rose from four accepted pull requests to six. With AI tools able to generate a plausible patch in seconds, counting patches stopped measuring effort. So they stopped counting.
Rewards are now virtual stickers. Three gets a physical sticker pack, ten adds a holographic sticker, and seventeen makes you a Completionist with a raffle entry for a t-shirt or an Arduino Uno Q. You get them by attending a local Fest, checking into livestreams, joining Global Hack Week, entering DEV Challenges, and similar activities.
A month plan
These are suggestions. Pick the parts that fit your time.
October 1 to 5: set up and read
Register, then pick one open-weight model you can run on your own machine. Read its licence in full. Some popular families ship under Apache 2.0, and others use custom terms with acceptable-use clauses that affect whether you can share or sell what you build. The DEV Hacktoberfest Weekend Challenge runs these same days if you want a first prompt to build against.
October 5 to 11: build something small and write down what you ran
Use the week 1 challenge prompt or your own idea. Keep a short record: model name, tag, digest, licence, and anything the release did not tell you, such as what data it was trained on. If you use Ollama, ollama list shows each local model's ID and ollama show --license <model> prints its licence. That record is the difference between "I used an open model" and something another person can check.
October 9 to 15: Global Hack Week
Daily livestreamed workshops and challenges on MLH's Discord. Good for learning in company if you are working alone otherwise.
October 12 to 25: find a maintainer's actual bottleneck
Choose a project you already use. Read its CONTRIBUTING file and the last twenty closed issues before you open anything. The most useful work on many projects is unglamorous: reproducing a reported bug, reducing a failing test to its smallest case, confirming that an old issue still happens on the current release, or fixing documentation that misled you. None of it counts for stickers this year, which is a good reason to do it.
October 26 to 31: write it up
Week 4 of the DEV Challenges closes the month. A post about what you built, which model you used, and where its openness stopped is worth more to the next beginner than a list of merged changes.
If you open a pull request, disclose your tools
The Linux kernel's guidance on tool-generated contributions is the clearest standard I know: "You are expected to understand and to be able to defend everything you submit. If you are unable to do so, then do not submit the resulting changes." It also asks contributors to say which tools they used and which parts of the change those tools affected.
You can adopt that on any project. Here is a pull request description shape that works; adjust it to the project's own template:
## What this changes
One or two sentences.
## How I tested it
Commands run, environment, and results.
## Tools used
- Model or assistant: <name and version>, used for <drafting the test / suggesting the fix / none>
- Parts of this change written with that tool: <files or functions>
- I have read and can explain every line in this diff.
Maintainers are the scarce resource in open source. Disclosure helps them decide how closely to review, and it tells them you respect their time.
Why this still matters
A 2024 Harvard Business School study estimated that firms would spend 3.5 times more on software without open source, and that 96 percent of its demand-side value comes from 5 percent of developers. That small group carries a great deal of weight, and their scarce resource is attention.
That is the core of my case for open source in an AI-heavy year. Code is getting cheaper to produce. The ability to read it, build it yourself, and check that what you installed matches what was published is what keeps it trustworthy. The xz Utils backdoor in 2024 was caught because an engineer noticed SSH logins running about half a second slow and had every right to dig into the source and the release tarballs. Open source did not guarantee that someone would look. It guaranteed that someone could.
I try to hold my own small projects to that. Metron, an Apache 2.0 terminal coding agent that talks to a local model through Ollama, ships checksums, SBOMs and build-provenance attestations with each release, so you can verify the archive came from the repository's own build. It is not production certified, and the README says so. If you want something to read during the month, the Metron repository is open, and so is Stopline.
What are you building with this October? I would like to know which model you picked and what its licence let you do.
Sources: Hacktoberfest 2026 overview (MLH) · Hacktoberfest FAQ · DigitalOcean 2020 recap · DigitalOcean 2025 wrap-up · Linux kernel guidelines for tool-generated content · HBS: The Value of Open Source Software · Freund's xz disclosure
Top comments (0)