Hacktoberfest 2026 no longer rewards pull requests, and I think the change forces a useful question on all of us: if a contribution is not a merged diff, what is it?
The organisers' reason is short. Their FAQ says it is "easier than ever to submit low-effort spam PRs to projects," so they listened to maintainers and stopped incentivising them. This year MLH and DEV run the month with DigitalOcean presenting, under the theme "AI Belongs to Everyone." You earn stickers by attending local Fests, joining Global Hack Week (October 9 to 15), entering DEV challenges and similar activities.
The history makes the decision easy to understand. The first Hacktoberfest in 2014 had 676 participants and a simple rule: four pull requests, one t-shirt. By 2020 there were nearly 170,000 sign-ups and more than 621,000 pull requests, enough README spam that maintainers compared it to a denial-of-service attack. The rules tightened to opt-in repositories and maintainer acceptance. Last year the bar went from four accepted PRs to six. Then AI tools made a plausible patch cost seconds to produce, while reviewing one costs what it always did. Counting stopped meaning anything.
I have been involved in open source since 1999, much of it teaching people to use Linux and Git and running infrastructure on them. Very little of the work that keeps a project healthy would ever show up in a PR count: reproducing a bug on a different machine, answering the same question for the fifth time, writing down how something behaved so the next person does not have to find out the hard way, or teaching someone to use the tools in the first place.
A 2024 Harvard Business School study estimated that 96 percent of open source's demand-side value comes from 5 percent of developers. That small group's scarce resource is attention. The most useful contributions spend less of it, or add to it.
So here is my working list of what counts this October, offered as a starting point rather than a rule:
- reproducing a reported bug on the current release, and saying so on the issue
- reducing a failing test to its smallest case
- fixing documentation that misled you, while you still remember how
- reviewing someone else's pull request carefully and leaving specific questions
- disclosing the AI tools you used and which parts of a change they touched, in the spirit of the Linux kernel's rule: "You are expected to understand and to be able to defend everything you submit"
- building something with an open-weight model and writing down the exact model, digest and licence, plus what the release did not tell you
That last one connects to this year's theme. Open weights let you run, test and fine-tune a model on your own hardware. Most releases do not publish training data or full training code, so you cannot reproduce or audit how the model was made. The OSI's Open Source AI Definition asks for both. Knowing where a model's openness ends is part of using it responsibly.
I would like to hear from people here, especially anyone who maintains a project. What kind of contribution helps you most, and what would you want a Hacktoberfest participant to do this month that no counter would ever see?
Sources: Hacktoberfest 2026 (MLH) · Hacktoberfest FAQ · DigitalOcean 2020 recap · DigitalOcean 2025 wrap-up · HBS: The Value of Open Source Software · Linux kernel guidelines for tool-generated content · OSI Open Source AI Definition 1.0