Mnemosyne is a spaced repetition program that treats itself as research

Two projects wearing one name

The README opens by defining Mnemosyne twice, and both definitions are load bearing.

The first is a free, open-source, spaced-repetition flashcard program that helps you learn as efficiently as possible. The second is a research project into the nature of long-term memory. The second one explains the first: the scheduling behaviour is not a black box borrowed from a general purpose spaced repetition algorithm, it is the output of an ongoing research programme run by the project author.

The research angle also shows up as a product decision. The README says that if you like, you can help out and upload anonymous data about your learning process, and that this feature is off by default. That default matters. Learning histories are among the most revealing data a person produces, and a project that asks for them has to make the ask opt-in for the trust to be reasonable.

The feature list is long and, unusually, concrete. Bi-directional syncing between several devices. Clients for Windows, Mac, Linux and Android. Flashcards with rich content, meaning images, video and audio. Support for Google text-to-speech and Google translate. Powerful card types, a flexible card browser and card selection. Visualisation to illustrate the learning process. An extensive plugin architecture with external scripting. Different learning schedulers. A webserver for review through a browser, which the README qualifies by saying it does not implement any security features so far. A cramming scheduler to review cards without affecting the regular scheduler. And a core library that allows you to easily create your own front-end.

That last item and the webserver are the two that matter for anyone considering this as a platform rather than as an app.

A core library with several front-ends around it

The repository structure makes the architecture concrete, and it is the clearest signal of what the project really is.

There is the mnemosyne package itself, which is the bulk of the code. There is an openSM2sync package, which is the synchronisation layer, named for the SM-2 algorithm whose scheduling the project extends. There is a science_server directory, which is the web component. There is a po directory for translations, a pixmaps directory for the icon assets of the desktop client, and a tools directory.

The packaging shows the same split. The Poetry configuration includes the mnemosyne and openSM2sync packages in the distribution, and it excludes several directories outright: the android directory, an android_python directory, an embedded_in_C directory and a UDP_server directory. So the Android client and the embedded and UDP variants are developed in the tree but are not part of the Python package.

The core library is exposed through a console script entry that points at the PyQt user interface, so the shipped command launches the desktop client, and the README's feature list makes the same point in prose: there is a core library that allows you to easily create your own front-end. That is the architectural commitment. The scheduling, the card model and the synchronisation are the product; the PyQt interface is one consumer of them.

The Windows packaging is done in a distinctly old-fashioned way, which is worth noting if you are comparing build systems. The setup.py file in the tree contains a class that walks a distribution directory and writes an Inno Setup script, with the sections for setup, messages and files, so a release build generates a Windows installer script from a template. The macOS side has a separate command file, Mnemosyne-Installer-MacOS.command, and there is a spec file for Python and a desktop entry for Linux.

The browser server is the part to be careful with

One line in the feature list deserves to be read on its own. The webserver for review through the browser does not implement any security features so far.

That is the project's own words, and it is the kind of statement that is easy to skim past in a list of advantages. It means the review interface is not designed to be exposed to a network without something in front of it. There is no authentication, no authorisation and no session handling described, and the review process typically involves your card database and your account credentials for a sync service.

The requirement list shows the web stack underneath: cheroot 5 or later, WebOb 1.4 or later, and cherrypy in the dependency list, with the webserver built on those. The stack is a normal Python WSGI arrangement, and the absence of security features is a statement about the intended deployment, which is a local review session on your own machine.

If you want to review from a phone or another device, the README points to the Android client and the desktop clients instead, and the sync feature is the supported route for carrying state between devices. The webserver is a convenience for a browser on the same machine, and treating it as anything else needs a reverse proxy that handles authentication, plus a network you trust.

One more implementation detail from the requirements: legacy-cgi is needed when using Python 3.13 or later, and a specific version of the Google translate fork is called out as not working. Both are small signs of a codebase that is maintained against a moving set of upstream dependencies rather than frozen.

Content, plugins and the schedulers

The learning features fall into three groups, and they have different maturity.

The content group is the most polished. Rich card content covers images, video and audio, and the requirements list the supporting stack: Pillow for images, gTTS for Google text-to-speech, and a Google translate fork for translation. LaTeX support is optional and needs the latex and dvipng commands available, which the README maps to TeXLive on Linux, MacTeX on Mac and MikTeX on Windows, with an extra texlive-core package on Arch based distributions. That is a lot of optional machinery, and it is the difference between a flashcard app and a study environment.

The plugin group is what the research project needs. The README promises an extensive plugin architecture and external scripting, which lets the schedulers and the visualisations be extended without forking the core.

The scheduling group is the heart. There are different learning schedulers, and one of them is a cramming scheduler for reviewing cards without affecting the regular scheduler. That separation is a design decision worth understanding: cramming is a distinct mode with its own state, so a late-night session before an exam does not perturb the spaced schedule you have built over months. Visualisation to illustrate the learning process is the third element, and Matplotlib is in the dependency list for it.

For a research project, that combination is coherent. The data you want to study is the review history, and the ability to run a session that does not feed back into the long-term schedule gives you a clean experimental condition.

Building from source: three documented paths

The README documents development setup in detail, and it gives three routes, which is unusual and helpful.

The first is the system-wide Python installation. The recommendation is to install all dependencies with the distribution's package manager, then run make followed by make run from the top-level mnemosyne directory. That generates the auxiliary files and starts the application with a separate datadir under dot_mnemosyne2, so a development run does not touch your real collection. To work on the code interactively, you run python from the same top-level directory, and you can verify the right copy was imported with import mnemosyne and printing the module file path.

The second is a local virtual environment, for when the distribution does not package the libraries or packages them too old. You create the environment with virtualenv venv in the top-level directory, activate it with source venv/bin/activate, install the dependencies with pip, and then follow the same steps as before.

The third is pyenv and poetry, which the README says you may use as of Mnemosyne 2.11. You run pyenv local at the project root so that the interpreter matches the .python-version file, then set the Poetry configuration so that it recognises the interpreter pyenv activated, by setting the virtualenvs.prefer-active-python option to true. After that, poetry shell activates the project environment and poetry install installs the dependencies.

Dependency changes go through poetry add and poetry remove, and if you prefer to install from a requirements file you regenerate it with:

poetry export -f requirements.txt --output requirements.txt --without-hashes

The base dependency install for the older paths is a single pip line covering PyQt6, the WebEngine extra, matplotlib, cheroot, webob, pillow, the translate fork, gTTS and argon2-cffi, which is also the list of what you need for a bare system-wide run.

Tests, packaging and a stale release history

Testing moved frameworks recently. The README states that as of Mnemosyne 2.11, nose has been replaced by the modern pytest framework, and the suite runs through the makefile:

make test

or through the preparation target followed by pytest directly:

make test-prep
python3 -m pytest tests -r

The dependency list includes pytest and pytest-timeout, and the repository has a .coveragerc for coverage measurement.

The packaging is a mix of the old and the new, and it is worth understanding before you try to publish anything yourself. The build system requires poetry-core and uses the masonry backend, with a custom build script named poetry-build.py, and the generate-setup-file option is turned off so that the setup.py in the tree is not regenerated. The setup.py file is the older setuptools-based builder that also produces the Windows installer script. A requirements.txt is kept in the tree and is exported from Poetry, and there is a poetry.lock alongside it.

The state of maintenance is where an evaluator should look carefully. The published releases are 2.11 on 2023-11-12, 2.10.1 on 2025-02-06 and 2.10 on 2023-01-30, and the version in the project file is 2.11.1. The last push was on 2026-04-18 and the repository is not archived, so work is still landing, but the released artefact dates from 2023 and the release numbering has not advanced since. If you install from a package index you are installing a build from 2023; if you run from the tree, you are running code whose last change was in April 2026.

The licence is a custom one that GitHub cannot classify rather than a standard permissive licence, so read the LICENSE file before you redistribute it.

Editorial conclusion

Mnemosyne fits a learner or researcher who wants a spaced repetition system they can inspect, extend with plugins, and run on their own machine, and it does not fit a team that needs a shared multi-user service, because the browser review server implements no security features and the project ships no hosted offering. Before you deploy the web server, read that limitation and put an authenticating proxy in front of it. If you plan to contribute, note that the published version is 2.11 from 2023-11-12 and the last push was on 2026-04-18, so the code is workable but the release history is stale.

Frequently asked questions

Official sources

1. Issues
2. mnemosyne-proj/mnemosyne on GitHub
3. Project website
4. README
5. Releases