Plover: the open source stenotype engine for writing at 200 WPM

What Plover actually solves for a stenographer

A stenotype machine does not type letters. It produces chords, and something has to translate those chords into text that lands in whatever window has focus. Plover is that something. The README describes it as "a desktop application that allows anyone to use stenography to write on their computer, up to speeds of 200WPM and beyond." The audience is narrow and specific: people who own or plan to own steno hardware, people learning machine shorthand on their own, and captioners or programmers who want chorded input in ordinary applications. It is not a note-taking app and it is not a text editor. It is an input layer, and that framing matters for how you evaluate it. The Open Steno Project positions Plover as one piece of a larger stack that includes hardware and learning material, so the software assumes you are bringing a machine and a dictionary.

How the engine sits between your machine and your cursor

Plover is a Python desktop application, and the repository layout reflects that: a plover/ package, a plover_build_utils/ package for the build tooling, and separate linux/, osx/ and windows/ directories holding platform-specific packaging. The build backend is setuptools with PySide6 as a build requirement, so the user interface is Qt-based. Two details in pyproject.toml say something about the design. The towncrier configuration splits release notes into sections for Features and Bugfixes, and within those into Core, Dictionaries, User Interface, Linux, macOS and Windows, plus an API section with Breaking Changes, Deprecations and New. That taxonomy tells you where the project expects churn: dictionaries and platform behaviour are first-class categories, not afterthoughts. The other detail is a deliberate lint exemption. The comment next to BLE001 explains that a broad except Exception is "Plover's deliberate crash-resilience idiom: engine hooks, plugin and dictionary loading must never take down the engine." That is a real architectural stance. A bad dictionary or a misbehaving plugin should degrade, not kill the input layer, because a crash mid-sentence costs the user their text. The trade-off is that failures can be swallowed rather than surfaced, which makes diagnosing a silently ignored plugin harder than it would be in a stricter codebase.

Installing Plover and getting a first chord out

The README does not contain installation commands. It states that Plover runs on Windows, Linux and Mac, and directs readers to the installation guide on the wiki, which covers "downloading, installation, and initial configuration." For a packaged build, that wiki page is the entry point, not the repository. What the repository does document is building from source, with separate instructions per platform. The README links to windows/README.md, linux/README.md and osx/README.md for the development environment. Since the build system requires PySide6 and setuptools, a source build is a Python packaging exercise rather than a single command, and the exact steps differ by platform in those files. The setup.py exposes three custom commands. The build_ui command runs before build_py, and develop depends on build_py, so a development install compiles the Qt user interface first. If you are contributing rather than using Plover, that ordering is the thing to understand before you run anything. The README also points to a Beginner's Guide and a Supported hardware page on the wiki, which is where you confirm that your machine is recognised before you spend time on configuration.

Where Plover is the wrong tool

Plover assumes hardware. If you do not have a stenotype machine or a keyboard the project supports, the wiki's Supported hardware page is the gate, and the README does not claim that arbitrary keyboards work. A second limitation is documentation placement. Everything a new user needs (installation, beginner guidance, hardware compatibility, troubleshooting) lives on plover.wiki or plover.readthedocs.io, not in the repository. That split is normal for a project of this age, but it means the GitHub README alone will not get you running, and it means the quality of your experience depends on wiki pages the README links to rather than on files under version control. Third, the crash-resilience idiom has a cost. When dictionary or plugin loading failures are caught broadly by design, a malformed dictionary entry may not produce a clear error, and you may find yourself debugging by elimination. Finally, if your goal is simply fast typing without learning a chord system, Plover is the wrong category of software entirely. Machine shorthand is a skill, and the engine does not shorten the learning curve, it only makes the output possible.

Plover against a general-purpose key remapper

The nearest alternative in spirit is a keyboard remapping or macro tool, and the difference is in what the software knows. A remapper maps one key event to another key event or a script. Plover maps a set of simultaneous key presses to a dictionary entry, and the dictionary is the data model. That is why the release-note taxonomy has a Dictionaries category alongside Core and User Interface: the dictionary is editable content, not configuration. It is also why the project can offer output "up to speeds of 200WPM and beyond" while a remapper cannot, because the unit of input is a chord rather than a keystroke. The cost of that model is that Plover is useless without a dictionary and a machine that produces chords. A remapper works with the keyboard you already have and requires no new skill. If you want to press one key and get a long string, a remapper is the smaller tool. If you want to write prose at dictation speed, the dictionary model is the reason to pick Plover.

Maintenance, releases and what GPLv2 means for you

The repository is not archived, and the last push was on 2026-09-20. Releases are frequent enough to be worth tracking: v5.3.0 on 2026-04-09, v5.4.0 on 2026-07-10, and v5.4.1 on 2026-08-27. The towncrier setup means each release note is assembled from news.d fragments and split into Features and Bugfixes with per-platform subsections, so upgrade notes are structured rather than a raw commit list. The API section is the one to read before upgrading if you maintain plugins, since it carries Breaking Changes and Deprecations categories. On licensing: the README states Plover is GPLv2+ as of version 3.1.0, and the repository ships LICENSE.txt. For individual users this is unremarkable. For anyone embedding Plover in a product, the copyleft terms are the thing to read in full, and this article is not legal advice. The practical upgrade cost is low if you use packaged builds and stay on the release channel, and higher if you build from source, because the PySide6 and setuptools requirements in pyproject.toml define your build environment.

Editorial conclusion

Adopt Plover if you already own a stenotype machine or a supported keyboard and want a free engine that sits between the hardware and any application. Do not adopt it expecting a self-contained tutorial: the README defers installation, hardware support and troubleshooting to the Plover wiki, and the repository itself only documents building from source per platform. Before committing, verify that your specific hardware appears on the Supported hardware wiki page and that your platform's build README covers the toolchain you have.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. opensteno/plover on GitHub
3. Project website
4. README
5. Releases