Zettelkasten is a desktop slip box that insists on Java 25

The model is Luhmann's slip box, not a folder tree

Zettelkasten is a knowledge management tool inspired by Niklas Luhmann's note-taking system, and the documentation explains the name directly: Zettelkasten is German for slip box.

That origin is the design statement. A slip box is a box of index cards where each card is a single idea and each card points at the others. The implication for a software tool is that the note, not the folder, is the unit, and that relationships between notes carry the meaning. Luhmann's own practice was to write one thought per card and to link each new card to the existing ones in a way that a reader could follow.

The tool is a desktop application rather than a web service, and the screenshot in the documentation shows the main window on macOS. The homepage is hosted at zettelkasten.danielluedecke.de and the project lives under the Zettelkasten-Team organisation on GitHub.

What the repository listing adds is a hint about the tooling culture. Beyond src/ and docs/ there are AGENTS.md and CONTRIBUTING.md for agent and contributor instructions, a CHANGELOG.md, a repomix.config.json, a flake.nix and flake.lock for Nix, and a .mvn/ directory holding Maven configuration. The local-repository/ directory is unusual and is discussed below.

Java 25 is a hard runtime requirement, not a suggestion

The note to users is the most consequential line in the documentation for anyone evaluating this tool.

To run Zettelkasten you need a Java Runtime Environment for Java 25 or newer, with Eclipse Temurin given as an example. On macOS the documentation names the exact command:

brew install openjdk@25

That is the whole installation story for the runtime. There is no bundled JRE in the application, and there is no mention of an alternative such as GraalVM native images or a self-contained package.

The consequence is that every machine that opens the application needs a recent JDK-era runtime present, including the ones where the tool is used casually. On a corporate mac or a locked-down desktop that has been provisioned with a long-term-support Java version, that is a real blocker rather than a note in the docs.

Java 25 is a recent long-term release, and requiring it means the tool can use recent language and standard library features without compatibility shims. The trade is the same one any recent-Java desktop tool makes: fewer old machines work out of the box.

For developers the requirement is stated separately. To build Zettelkasten you need a Java Development Kit for Java 25 or newer and Maven 3.9 or later. The distinction between the runtime for users and the JDK for developers is explicit, and both are pinned to the same Java version.

Building it is a git clone and one Maven command

The build instructions are short and complete. To get a local repository, use Git:

git clone [email protected]:Zettelkasten-Team/Zettelkasten.git

Then, in the root directory of the local repository, run:

mvn clean package

The documentation points out that `mvn` is Apache Maven and suggests confirming with `mvn -v` in a new shell. The build result is found in the `target` directory.

That is a conventional Maven layout, and the repository confirms it with a pom.xml at the root and a .mvn/ directory for project-level Maven configuration. The primary language is Java.

One directory in the tree deserves a note because it is not standard for a Maven project: local-repository/. A project that vendors its own local repository typically does so to pin or to mirror the artifacts its build resolves, so that a clone builds the same way on any machine and in CI without depending on the state of a shared cache. The .envrc file at the root is the kind of file that loads environment variables for a directory when you enter it, commonly used with direnv, and flake.nix with flake.lock is the Nix equivalent of pinning a toolchain and its dependencies.

The combination means the build is reproducible in a stronger sense than a bare mvn package, at the cost of a repository that is larger to clone.

The release tags and the source tree have drifted apart

The maintenance picture here needs care, and the two sets of dates in the repository say different things.

The repository is not archived, and the last push was on 2026-10-12, which is recent work on the source tree. The documentation also carries a CI badge and a repository layout with .github/ and scripts and tests directories, so the project is built and checked automatically.

The published releases are older. The latest GitHub release tag is v3.2022.8, published on 2022-10-01, before that v3.3.1 from 2020-04-06 and v3.3.0 from 2020-04-02. The naming convention itself changed across that history, from a v3.3.x scheme to a year-based v3.2022.x scheme.

So the source tree is being maintained while the downloadable build line has not had a new tag since 2022. That is a meaningful distinction for anyone adopting the tool. If you install from the releases page, you get a build from October 2022, running against whatever Java you point it at. If you build from source, you get the current tree, which may behave differently from the build people are downloading.

The download route is the releases page, and the wiki is the place for user-facing documentation and contributed content. The GPLv3 licence applies, with details in the LICENSE file.

What a Java note tool implies operationally

Choosing Zettelkasten means accepting a specific set of operational characteristics, and they follow directly from what the documentation states.

The application is a desktop program with a runtime dependency on Java 25, so it is installed per machine rather than served centrally. The build is a Maven project, so a custom or patched build is a Java build, not a container image or a binary drop-in. The repository is GPLv3, which matters if you intend to modify and distribute it rather than just use it.

What the documentation does not state is equally relevant to a decision. It does not describe the note format, the linking mechanism, the search or tagging model, the export paths, or whether it synchronises. A reader choosing between note tools normally wants to know exactly how a link is expressed in the note text and how that differs from another tool's convention, and this documentation does not answer that. There is a wiki where that content lives, and reading it is part of the evaluation rather than an optional extra.

The concept, though, is stated clearly enough to judge the fit. If what you want is a folder hierarchy with tags and search, a slip box is the wrong model. If what you want is a set of atomic notes connected by explicit links, the premise is at least coherent and the naming makes the intent obvious.

Where this sits against other linked-note tools

The comparison with the wider category of linked-note software is mostly a comparison of premise rather than of features, because the feature documentation here is thin.

The Luhmann premise is the differentiator. Tools built around a folder and tag hierarchy treat the hierarchy as the structure and the link as an extra. A slip box treats the link as the structure and the folder as incidental, which is closer to how hypertext was originally imagined and how the literature on note-taking systems describes the method. Adopting Zettelkasten means adopting that premise, and if you already have a large body of notes in another format, the migration question is the one the wiki would need to answer.

The second difference is the desktop, Java-shaped delivery. Tools in this category frequently arrive as Electron applications, as mobile apps with sync, or as plain text directories that you edit in any editor. A Java desktop application with a required Java 25 runtime is a different distribution model, and it is one that suits a single-machine, file-based workflow.

The third difference, and the practical one, is the release situation. A tool whose latest tag is from 2022 while its source moves on tells you something about how the project distributes its work, and that affects whether you would rather install a build or compile one yourself.

Editorial conclusion

Adopt Zettelkasten if you want a note tool built around linked notes rather than folders, and you are willing to install a Java 25 runtime on every machine that opens it, because that runtime requirement is not optional and there is no native build without it. Skip it if you need a build with an active release cadence you can point at, since the latest published tag is v3.2022.8 from 2022-10-01 while the source tree has moved on since. Verify first that a Java 25 runtime is available on your target machines, and check the releases page for the build that matches the state of the source you are evaluating.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Zettelkasten-Team/Zettelkasten on GitHub