The open-source project that outgrew the cloud
Franck Nijhof—Frenck to the community—didn't set out to lead one of GitHub's fastest-growing projects. As a lead of Home Assistant and a GitHub Star, he now helps steer a platform that runs in more than 2 million households, controlling thermostats, locks, sensors, and lighting entirely on users' own hardware. This year's Octoverse report placed Home Assistant among the fastest-growing open source projects by contributors, alongside AI infrastructure names like vLLM and Ollama, and among the top projects for attracting first-time contributors, next to platforms like VS Code.
The numbers are striking: 21,000 contributors in a single year feeding into an ecosystem for the physical world, not for AI agents or developer tooling. As Frenck puts it in a podcast interview, Home Assistant is "a free and open source home automation platform. It allows you to connect all your devices together, regardless of the brands they're from… And it runs locally." The onboarding pitch is deceptively simple: "Flash Home Assistant to an SD card, put it in, and it will start scanning your home."
The combinatorial problem at the core
Under the surface, Home Assistant faces a problem of explosive complexity. The platform supports "hundreds, thousands of devices… over 3,000 brands," each with its own API, quirks, and firmware behavior. The solution is a general-purpose abstraction layer: every device is represented locally as an entity with states and events, not as a vendor-specific cloud endpoint. A garage door exposes capabilities to the automation engine; a thermostat is a sensor/actuator pair with metadata that can be reasoned about.
That consistency enables elaborate automations. Frenck describes one community example: weight sensors in couches that detect when someone stands up during a movie, pausing playback and brightening lights for a drink run, then dimming and resuming when they sit back down. The system orchestrating these interactions is, in effect, a distributed event-driven runtime for physical spaces—more a real-time OS for the home than a dashboard.
Local-first as a hard constraint, not a feature
Home Assistant's commitment to running everything locally reverses the industry's cloud-centric paradigm. "It's crazy that we need the internet nowadays to change your thermostat," Frenck notes. The platform must run on hardware as modest as a Raspberry Pi while handling workloads that commercial systems offload to the cloud: device discovery, event dispatch, state persistence, automation scheduling, local voice inference, real-time sensor reads, integration updates, and security constraints.
This forces optimizations that consumer systems rarely attempt. SSD wear leveling on a Pi, MQTT throughput, and Zigbee network topologies all become software problems. Because the system must keep working offline, there is no fallback. It's engineering with no safety net.
Governance as a technical safeguard
For a system running in millions of homes, the biggest long-term risk isn't bugs—it's ownership. Home Assistant's move to the Open Home Foundation is a deliberate defense. "It can never be bought, it can never be sold," Frenck says. "We want to protect Home Assistant from the big guys in the end." If the project were acquired, APIs would break, integrations would be deprecated, and years of user automations would collapse.
The Foundation's charter encodes three constraints that shape every design decision:
- Privacy: "Local control and privacy first." All processing must occur on-device.
- Choice: "You should be able to choose your own devices" and expect them to interoperate.
- Sustainability: If a vendor kills its cloud service, the device must still work.
Frenck points to Nest as a cautionary example: "If some manufacturer turns off the cloud service… that turns into e-waste." This governance model dictates API longevity, integration strategy, and reverse engineering priorities, forcing the project to outlive any individual device maker.
Quality through dogfooding at scale
Home Assistant's engineering velocity comes from an unusual source: every contributor runs the software they build. "We don't build Home Assistant, the community does," Frenck says. "We cannot build hundreds, thousands of device integrations. I don't have tens of thousands of devices in my home." Instead, developers write integrations for devices they personally own, and reviewers test contributions against devices in their own homes. Break something and you break your own house; improve something and you improve your daily life.
"That's where the quality comes from," Frenck explains. "People run this in their own homes… and they take care that it needs to be good." No staging environment could replicate millions of real homes, each with its own edge cases. The production hardware is the test suite.
Assist: voice control that predates the AI wave
Assist, Home Assistant's built-in voice assistant, took shape before the current AI boom. "We were building a voice assistant before the AI hype… we want to build something privacy-aware and local," Frenck says. Unlike commercial assistants, Assist uses a two-layer approach prioritizing determinism and user choice.
Structured phrases first, AI as fallback
The first layer is a deterministic intent engine using hand-authored phrases contributed by the community. Commands like "Turn on the kitchen light" match directly to known actions without any machine learning. No network calls, no cloud, no hallucinations—just a direct mapping from phrase to automation. The system only invokes AI when a command requires flexible interpretation. "Home Assistant would be like, well, I don't have to ask AI," Frenck says. "I know what this is. Let me turn off the lights."
Bring your own model
When AI is needed, users choose the inference path. "You can even say you want to connect your own OpenAI account. Or your own Google Gemini account. Or get a Llama running locally in your own home," Frenck explains. AI is a fallback, not the foundation.
Open hardware as a development scaffold
To bootstrap voice development, the team built the Voice Assistant Preview Edition—a fully open source smart speaker. "It's fully open source. The hardware is open source; the software running on it is ESPHome," Frenck says. A predictable hardware target lets developers build and test voice features without guessing how microphone arrays, DSP pipelines, and wake word configurations vary across vendors.
Hardware as a software accelerant
Most open source projects avoid hardware. Home Assistant embraced it out of necessity. "In order to get the software people building the software for hardware, you need to build hardware," Frenck says. Home Assistant Green, the prebuilt plug-and-play hub, exists because onboarding requires reliable hardware. The Voice Assistant Preview Edition exists because the voice pipeline needs a known configuration. This pattern—hardware as scaffolding for software evolution—results in a more stable and testable ecosystem, akin to building a compiler and then designing a reference CPU.
Toward a programmable home
With local AI models, deterministic automations, and a stateful view of the entire home, the next step is agentic behavior running entirely offline. If a couch can trigger a movie automation, and a brewery can run a fermentation pipeline, the home becomes programmable: every sensor is an input, every device is an actuator, every automation is a function. The entire house becomes a runtime—one that belongs to the homeowner, not the service provider. As Frenck sums it up: "We give that control to our community."
