The theme for Week 1 of the Hacktoberfest DEV Challenge is out, and it is a little personal for anyone in DevOps: Touch Grass. Build something with open-weight models or open-source AI that gets people off the screen and into the world. Submissions are due by October 11, 2026 at 11:59 PM PDT.
The organisers put it well: the best builds should make the screen the shortest part of the experience. That is a fun constraint for people whose job is mostly screens. This post gives you six project ideas with a DevOps flavour. Each one is small enough for a week of evenings, gets someone outside, and has a clear answer to the question the judges ask in every entry: why does open matter for what you built?
The rules in 30 seconds
From the challenge page and the Week 1 launch post:
- The prompt: build something with open-source AI at its core: an open-weight model, an open-source agent harness or framework, local inference, or all three. The open pieces should be what makes the project work.
- The theme: get people off the screen and into the world. Hiking, gardening, birding, run clubs, fall foliage: if it gets someone outside, it counts. Bonus points if you take it outside, use it, and tell us how it went.
- A new project, built during the challenge. Pull requests to existing projects do not count this year.
- The write-up matters most. Writing quality has the biggest weight in judging. Explain why open innovation matters for what you built: does it run with no internet, keep data off someone else's server, let you swap or fine-tune the model, cost nothing to run?
- One submission per challenge. It is in the running for the overall prize and every partner category it qualifies for, but it can win only once per challenge. To enter a partner category, use that partner's technology and list the category in the Prize Categories section of your post. Missed the weekend challenge? Every week is a fresh start.
1. The pager-safe walk, for your on-call friend
The problem: on-call engineers stay inside because they are afraid of missing a page. A whole week indoors, for alerts that mostly need nothing.
What it does: answers one question before you leave: "How far can I walk and still be back at my laptop within 15 minutes?" It draws that area on a map, so the walk is planned in seconds and the rest is outside. While you walk, a small watcher reads incoming alerts and sends one short verdict to your phone: "stay out" or "head back, this one looks real". Plain rules decide whether a page needs you; the model only explains why in one sentence.
Why open matters: alert payloads are full of hostnames, customer names and internal URLs. With a local model, they never leave your machine. The walking area comes from open map data: OpenStreetMap plus an open-source routing engine such as Valhalla, which has an isochrone API for exactly this "how far in N minutes" question. Use pedestrian costing, and show the area as an estimate: hills and crossings make the real walk back slower.
Week scope: one isochrone request for your home address, one map page, one watcher that reads a webhook or a JSON file of alerts. Skip live paging integrations; a sample alert file is enough for the demo.
Partner fits: Temporal (a watcher that must not lose an alert is a good fit for a durable workflow), Mastra (orchestrate the steps over an open model).
Background: our on-call rotation and escalation guide explains which pages should wake a human, which is exactly the rule set your watcher needs.
2. Field notes from your camera roll, for the friend who hikes
The problem: after a hike, the photos sit unsorted on a phone, and the "what was that plant?" question never gets answered.
What it does: you drop a folder of hike photos on your laptop. A local vision model writes field notes: what each photo shows, with a confidence level, and the place it was taken (from the photo's GPS data). The result is a one-page trail log with a map. The screen time is five minutes after the hike, not during it.
Why open matters: photos with GPS coordinates show where you live and where you walk. With an open-weight vision model running locally (Gemma 4 takes text and image input), the photos never leave your laptop. If you add hosted search, say in the post that only the notes and embeddings go up, and drop the exact coordinates first.
Week scope: one folder in, one Markdown or HTML page out. Read EXIF with an existing library. Ask the model to say "not sure" instead of guessing a species, and show its uncertainty in the page.
Partner fits: Gemma (run it locally), Tiger Data or MongoDB Atlas (store notes and embeddings so you can search "all the mushrooms from September").
Background: none needed, just a recent hike. If you have not been on one, that is the first step of the project.
3. A cron job for going outside, for everyone on your team
The problem: "I'll go for a walk later" never happens, because later is a meeting.
What it does: reads your calendar (an .ics export), the weather forecast, and today's sunset time, and books the best 30 to 45 minutes outside before it gets dark. Then it learns from your history which suggestions you actually took. If you never go out at 13:00 on Mondays, it stops suggesting that.
Why open matters: your calendar shows who you meet and when. It stays on your machine. The weather comes from Open-Meteo, which is free for non-commercial use with no API key.
Week scope: a script that prints today's best remaining window and writes it back to your calendar as an event. The learning part can be a CSV of past suggestions with "taken" or "skipped".
Partner fits: TabPFN (its category is about predicting from a historical CSV, which is exactly your "taken or skipped" log), Gemma (write the suggestion in a friendly sentence).
Background: if cron syntax still surprises you, try the cron expression simulator before you schedule anything.
4. Alerting for tomatoes, for a friend with a garden
The problem: garden apps either nag every day or stay quiet until the plants are dead. It is the same alert fatigue we fight at work.
What it does: an Arduino UNO Q in the garden reads soil moisture and temperature, combines it with the local frost forecast, and pages you only when the garden needs you: "frost tonight, cover the peppers" or "the bed by the fence has been dry for three days". Everything else goes into a weekly summary. Apply the rule we use for production: page on symptoms, not on every reading.
Why open matters: the model runs on the board itself, with no cloud account and no subscription. The network is only needed to fetch the daily frost forecast and to send the message; the readings and the decisions stay on the board.
Week scope: one sensor, one plant bed, two alert rules, one weekly summary. A soil moisture sensor and a frost check are enough for a strong demo video.
Partner fits: Arduino (run a model on the UNO Q, sense and act), DigitalOcean (host the weekly summary page, if you want one outside your home network).
Background: our guide to SLOs, SLIs and error budgets is about services, but the same thinking decides when a tomato deserves a page.
5. A trail buddy that works with no signal, for your homelab friend
The problem: the best trails have no mobile signal, and that is exactly when you want to know how far it is to water, or when you must turn back to beat the sunset.
What it does: before the hike, it downloads what it needs: the route, water sources and shelters from OpenStreetMap (through the Overpass API), and the sunset time. On the trail, a Raspberry Pi or an old phone answers questions by voice: "How far to the next water?" "When do I need to turn back?" The distances and times come from plain code; the model only turns them into a short spoken answer.
Why open matters: it has to work with no internet at all. A small local model, local speech recognition such as whisper.cpp, and local speech output such as Piper make that possible.
Week scope: one trail, three questions, voice in and voice out. Test it in airplane mode before you leave home, then test it on the trail.
Partner fits: Gemma (the local model), SerpApi (a pre-trip check for trail closures and news while you still have signal).
Background: if you build this on a Pi, the Linux terminal simulator is a quick refresher on the commands you will need over SSH.
6. The walking standup, for a remote team
The problem: remote teams spend the whole day in calls. The daily standup could be the one meeting you take outside.
What it does: everyone records a 60-second voice note on their walk: what they did, what they will do, what blocks them. Back at the desk, a local model transcribes the notes and writes the standup summary for the team channel. Nobody has to look at a screen during the meeting itself.
Why open matters: team updates mention customers, incidents and people. With local transcription and a local model on a team server you control, they stay inside the team.
Week scope: a folder of audio files in, one summary out. Use your own notes for a week, then try it with a friend's team.
Partner fits: DigitalOcean (run the team server or an open-weight model on a GPU Droplet), ElevenLabs (transcription, if you are fine with sending audio to a hosted service, or a narrated version of the summary for the demo), Mastra (orchestrate transcription, summary and posting).
Background: keep the summary short and factual. The rule from our on-call guide applies here too: if nobody acts on a message, it should not be sent.
A starter for the weather-aware ideas
Ideas 3, 4 and 5 all start with the same two pieces: some facts from an open data source, and a local model that turns them into one useful sentence. With Ollama, Gemma 4 and Open-Meteo:
ollama pull gemma4:e4b
# today's sunset and today's hourly rain chance (example coordinates: Berlin)
WEATHER=$(curl -fsS "https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&hourly=precipitation_probability&daily=sunset&timezone=auto&forecast_days=1") || exit 1
NOW=$(TZ=Europe/Berlin date +%H:%M)
jq -n --arg w "$WEATHER" --arg now "$NOW" '{
model: "gemma4:e4b",
stream: false,
messages: [
{role: "system", content: "Suggest one 30 to 45 minute window to go outside today. It must start after the current time and end before sunset. Use only the weather data you are given. If no window fits, set possible to false."},
{role: "user", content: ("Current time: " + $now + "\nWeather: " + $w)}
],
format: {
type: "object",
properties: {possible: {type: "boolean"}, start: {type: "string"}, end: {type: "string"}, reason: {type: "string"}},
required: ["possible", "start", "end", "reason"]
}
}' | curl -fsS http://localhost:11434/api/chat -H 'Content-Type: application/json' -d @- | jq -e '.message.content | fromjson'
The format field constrains the model to that JSON shape, and the answer comes back as a JSON string in .message.content, which is why the example parses it with fromjson. In your own code, check the result against the data before you use it: the window must start after now, end before sunset, and fall in hours with a low chance of rain. After sunset there is no valid window, so expect possible: false. Better still, let plain code pick the window and use the model only for the reason.
How to fit it into one week
- Monday or Tuesday: pick the person and the place. Write one sentence: "My on-call friend wants to go for a walk without worrying about pages." That sentence is your scope.
- Midweek: build the ugly version. One input, one output, from the command line.
- Saturday: take it outside. Use it on a real walk, hike or garden. What breaks out there is the best paragraph in your post.
- Sunday: write. Writing has the most weight. Leave yourself at least three hours.
What to put in the write-up
- Who it is for and what got them outside, in their words.
- Why open, concretely. "It works in airplane mode on the trail" is stronger than "open source is important".
- What happened outside. The organisers ask for this as a bonus, and it is also the most interesting part to read.
- What did not work: a model that guessed a species with too much confidence, a route that ignored a river. Judges trust posts that show the hard parts.
- A demo: photos from outside, a short video, or a terminal recording.
- Your agent session, if you used one. The organisers suggest DevRelay. It is optional, but it helps judges see how you built it.
Next week
A new challenge starts every Monday in October, each with a new theme. We post DevOps project ideas for each one on the day it launches.
And if you want to practise classic open source pull requests this month (they do not count for the DEV Challenge, but they are still worth learning), our 7-day Hacktoberfest challenge gives you one small, reviewed PR a day.
What will you build to get outside this week? Tell us in the comments, and then go for a walk.
Top comments (0)