# Naomi: a Python platform for always-on voice applications on Raspberry Pi and Linux

> Naomi is an MIT-licensed, technology-agnostic framework for building always-listening voice assistants, derived from Jasper. It gives you the wake-word loop, plugin modules and installer scripts; the README does not document an uninstall path, and the last release tag predates the current branch by years.

**NaomiProject/Naomi** — The Naomi Project is an open source, technology agnostic platform for developing always-on, voice-controlled applications!

- Repository: https://github.com/NaomiProject/Naomi
- Website: https://projectnaomi.com/
- Stars: 303 · Forks: 62
- Language: Python
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/naomiproject-naomi

## What Naomi actually solves, and for whom

Building an always-on voice assistant means stitching together a microphone capture loop, a wake-word detector, a speech-to-text engine, an intent router and a text-to-speech engine. Each of those is a separate project with its own configuration format. Naomi's answer is to own the loop and leave the engines pluggable. The README frames it as "an open source platform for developing always-on, voice-controlled applications", based on the earlier Jasper project, and the repository credits both JasperProject and the Jasper2Fork as code sources.

The target user is not someone who wants a finished consumer speaker. It is someone with a Raspberry Pi or a Linux machine who wants to write their own modules and control what runs on the device. The README states Raspberry Pi and Linux are supported today and that cross-platform support is coming soon, which tells you the intended deployment surface is a small always-on box rather than a laptop. The topics list on the repository adds home-automation, IoT, speech-recognition and speech-synthesis, which matches the plugin-oriented design you see in the top-level plugins/ directory.

## The mechanism: a Python entry point plus a plugin directory

The repository layout is the clearest description of the architecture. Naomi.py sits at the top level as the runnable entry point, with NaomiSTTTrainer.py alongside it for speech-to-text training and Populate.py for populating data. The naomi/ package holds the core, and plugins/ holds the modules that add behaviour. There is no separate daemon package and no container definition at the top level.

Dependencies split into two files rather than one. python_requirements.txt covers the Python side, while apt_requirements.txt and naomi_apt_requirements.sh cover system packages, which is the normal shape for a project that needs PortAudio, audio codecs or speech libraries from the distribution. The presence of compile_translations.sh, update_translations.py and msgfmt.py shows the project carries gettext translations through its build. Internationalisation is compiled at build time: setup.py defines a naomi_build_i18n command that walks the tree for .po files and writes .mo files next to them, and it is wired into the build as a sub-command.

One detail worth flagging: setup.py still opens with a Python 2 shebang and declares version '2.0a1.dev1', while the README badge advertises Python v3.5 and the default branch is naomi-dev. The packaging metadata has not kept pace with the branch. Treat setup.py as a build script for translations, not as the authority on what version you are running.

## Installing Naomi and getting a first command through it

The README points at the project website for downloads: it says you can download the latest version of Naomi from https://projectnaomi.com/download, and that all documentation lives at https://projectnaomi.com/dev/docs. The repository also ships installer material at the top level, including naomi-setup.sh and an installers/ directory, plus the two requirements files.

If you are working from a checkout of the naomi-dev branch, the system packages come first because the Python audio stack needs them:

```bash
bash naomi_apt_requirements.sh
```

After that, install the Python dependencies from the pinned file in the repository root:

```bash
pip install -r python_requirements.txt
```

The entry point is a script in the repository root, so you start Naomi by running it directly rather than by invoking an installed console command:

```bash
python3 Naomi.py
```

The README does not document the flags Naomi.py accepts, the default wake word, or a sample configuration file, so the first real use is to start it and watch the console for which speech engines it selects. If you need the speech-to-text trainer, the repository provides NaomiSTTTrainer.py as a separate script in the same directory. Because the README gives no configuration reference, expect to read the naomi/ package to find where engine settings are read. That is the honest first-run experience: the installer gets you running, the source tells you how to configure it.

## Where Naomi gets in your way

The release history is the loudest limitation. The most recent tags are v3.0.M9 from 2019-10-01, v3.0.M8 from 2019-09-03 and v3.0.M7 from 2019-08-01. They are milestone tags, not stable releases, and they are years behind the naomi-dev branch that receives the pushes. Anyone who pins to a tagged release is pinning to a snapshot the project has long since moved past, and the README does not describe an upgrade path between those tags.

Packaging is the second rough edge. The version declared in setup.py does not match the branch or the README badge, and the file still carries a Python 2 shebang. A packaging file that disagrees with itself is a signal that installation is expected to happen through the website download and the shell installers rather than through pip. The README also does not document rollback, an uninstall procedure, or how to run Naomi as a system service, which matters for an always-on assistant that is supposed to survive a reboot.

Finally, the platform claim is narrow. Raspberry Pi and Linux are what the README lists; Windows and macOS are described as coming soon. If your target device is a Mac mini or a Windows machine, this is the wrong tool today, and no amount of plugin writing changes that.

## How Naomi differs from Rhasspy and Home Assistant's voice stack

The obvious alternative in the same space is Rhasspy, which also targets offline voice control on a Raspberry Pi. The difference in approach is where the intelligence lives. Rhasspy centres on an intent grammar and a training step: you write sentences that map to intents, and the system recognises against that closed set. Naomi inverts this by making the plugin the unit of extension. A plugin receives text and decides what to do, so behaviour is added by writing Python rather than by declaring sentences. That is more flexible for open-ended commands and worse if you want predictable recognition from a fixed vocabulary.

Home Assistant's own voice pipeline is the other reference point, and the split is architectural: Home Assistant already owns your devices and entities, so its voice layer is a front end onto that state machine. Naomi owns no devices. It is a voice loop that you point at whatever you like, which is why the repository tags include home-automation and IoT without shipping any device integrations itself. If your house already runs on Home Assistant, adding Naomi means running two systems and bridging them yourself. If you want a self-contained assistant you can shape in Python, Naomi's plugin boundary is the more direct route.

## Licence and the cost of keeping a fork alive

Naomi is MIT-licensed, and the repository ships LICENSE.md at the top level. MIT is permissive: you can modify it, ship it inside a product, and keep your changes closed, provided you carry the licence text and copyright notice. The README also credits Jasper and Jasper2Fork as code sources, and those upstream projects carry their own notices, so if you redistribute Naomi you should read AUTHORS.md and the upstream licences rather than assuming a single MIT file covers every line. That is a factual observation about provenance, not legal advice; if you are shipping a product, have counsel review the file headers.

The upgrade cost is the real recurring expense. With the newest tag at v3.0.M9 from 2019-10-01 and active work happening on naomi-dev, following the project means tracking a branch, not a release. There is a CHANGELOG.md in the repository, so the project does record changes, but the README does not describe a supported migration path from one milestone to the next. Budget for reading diffs. The project is funded through Open Collective and one-time donations, which the README states plainly, so the maintenance you get tracks the backers rather than a commercial support contract.

## Conclusion

Naomi suits engineers who want a hackable, self-hosted voice loop in Python on a Raspberry Pi or Linux box and are willing to read the source when the documentation stops. It is the wrong choice if you need a supported release cadence, a documented upgrade path, or Windows and macOS support, since the README marks cross-platform work as coming soon. Before committing, check the version string in setup.py, read the installer scripts under installers/ and naomi-setup.sh, and confirm which plugins under plugins/ still match your Python version.

## FAQ

### What is Naomi?

Naomi is an MIT-licensed, open source platform for developing always-on, voice-controlled applications, written in Python and based on the earlier Jasper project. The README describes it as always listening for commands and says you can build it yourself with off-the-shelf hardware.

### When did Naomi come out?

The repository's release tags begin with v3.0.M7 on 2019-08-01, followed by v3.0.M8 on 2019-09-03 and v3.0.M9 on 2019-10-01. The README does not state an original project start date; it only credits Jasper and Jasper2Fork as sources of the code.

### How do I use Naomi?

Download it from the project website at projectnaomi.com/download, install the system and Python requirements, then run the Naomi.py script in the repository root. The README points to projectnaomi.com/dev/docs for the full documentation and says you can write your own modules.

## Sources

- [License: MIT](https://github.com/NaomiProject/Naomi/blob/naomi-dev/LICENSE)
- [NaomiProject/Naomi on GitHub](https://github.com/NaomiProject/Naomi)
- [Project website](https://projectnaomi.com/)
- [README](https://github.com/NaomiProject/Naomi/blob/naomi-dev/README.md)
- [Releases](https://github.com/NaomiProject/Naomi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/naomiproject-naomi