Fidus Writer: a collaborative editor that separates content from layout

Content first, layout later, and the same text in several media

Fidus Writer is an online collaborative editor especially made for academics who need to use citations and formulas, and the sentence that explains the whole design is that the editor focuses on the content rather than the layout.

The consequence is stated next. With the same text, you can later publish it in multiple ways, on a website, as a printed book, or as an ebook, and in each case you can choose from a number of layouts that are adequate for the medium of choice.

That is a publishing tool rather than a document editor, and the difference shows up in the topic list. Alongside the obvious text-editor and word entries there are biblatex, bibtex, citations, jats, jats-publishing, jats-xml, latex, math, docx, opendocument and word. The academic formats are not an afterthought bolted onto a general word processor; they are the reason the project exists.

The implementation is a Django application. The package metadata names Django 6.0 in the framework classifier, requires Python 3.13 or newer, and describes the project as a semantic wordprocessor for academic purposes. The editor itself is ProseMirror, with both the JavaScript and the Rust implementations available as optional dependencies, and the Rust one is the interesting choice for a collaboration tool because the editing model is shared between the browser and the server.

The project is developed by Lund Info AB, and the maintainers sell a commercial product alongside it. The open source repository is the whole application, not a cut-down edition, which is unusual and worth noting for anyone assessing the licensing.

Five installation routes, and they are not equivalent

The installation section points to a documentation directory and then offers a quick start that is really a menu of packaging options.

For Debian, Ubuntu and Mint the recommended route is the APT repository, and there is a separate document for Debian packaging. For RHEL, Rocky, AlmaLinux and Fedora there are RPM packages, and for Ubuntu there is a Snap installation. There is a Docker installation and a developer setup for people who want to work on the code.

That spread is more than a convenience. A project written in Django and Python with an optional Node and Rust toolchain has a genuinely different installation story depending on the environment, and the fact that the Debian path is the recommended one tells you where the deployments actually are.

The documentation itself is organised into installation guides, Debian packaging, configuration, development and contributing, with a full documentation entry point at docs/README.md.

The optional dependencies in the package metadata are where the feature set becomes visible, and there are a lot of them. There is a books extra for the fiduswriter-books package, a citation API import extra, a languagetool extra for spell and grammar checking, an ojs extra for Open Journal Systems, a pandoc extra for document conversion, a phplist extra for mailing list integration, a gitrepo-export extra for pushing to a Git repository, a payment-paddle extra for payments, a website extra, a mysql extra using mysqlclient and a postgresql extra using psycopg2.

The database choices are the notable part of that list. MySQL and PostgreSQL are opt-in extras, so a deployment that expects to use PostgreSQL has to be planned for at install time rather than discovered later.

Licensing is AGPL with an exception for third party libraries

The licence section is one paragraph and it is precise about a distinction that matters.

All of Fidus Writer's original code is licensed under the GNU Affero General Public License, for details see LICENSE. Some third party libraries are licensed under other, compatible open source libraries, and licensing information is included in those files.

The AGPL choice has a specific consequence for a collaborative editor used by institutions. The Affero clause requires that users interacting with a modified version over a network be offered its source, which for a hosted academic writing service means the deployment has obligations toward its users, not only toward its contributors. The package metadata records the licence as AGPL-3.0-or-later, so the or-later clause is part of the grant.

Contributions are handled through a Contributor License Agreement, and the readme asks you to sign it before you start. That is the standard mechanism, and pairing it with an AGPL project means the copyright assignment is compatible with the copyleft grant rather than sitting awkwardly beside it.

The repository layout is consistent with a project that ships a lot of formats. There are fiduswriter/ for the application, docs/ for the documentation, debian/ and rpm/ for the native packaging, docker/ for the container image, ci/ for the pipeline, lint/ and stylelint.config.js and biome.json for the linting setup, build-deb.sh and build-rpm.sh for the packaging scripts, and setup.py, pyproject.toml and a MANIFEST.in for the Python build.

The top level also has a pyproject.toml with a setuptools build and Babel in the build requirements, which is what the custom setup.py commands below exist to work around.

The Python build has hand written setuptools overrides

The setup.py file is unusual enough that it is worth reading, because it is not a plain setuptools manifest and it documents why.

It starts by importing the namespace package finder and four setuptools commands, and it tries to import bdist_wheel inside a try block. The comment explains the reason: setuptools 70.0.0 removed bdist_wheel from setuptools.command, so the import is optional and the name is bound to None when it fails.

Then there are three custom command classes. The compile_catalog class extends Babel's own so that the gettext catalogues are compiled for both the django and djangojs domains into the locale directory of the application, which is a Django specific arrangement that plain Babel does not do on its own. The build_py class comes from a setuptools pull request and excludes platform specific files from the package, matching the pattern list against the package directory and removing the matching modules.

The bdist_egg and sdist classes both run compile_catalog before doing their own work, and sdist carries a docstring of exactly one line, Custom build command.

The effect of all this is that translations are compiled whenever a distribution is built rather than as a separate manual step, and the packaging matches what the platform expects. It is the sort of scaffolding that tells you the project has been packaged for Debian and RPM targets for a long time, since the wheel command handling and the platform pattern exclusion are both workarounds for specific packaging behaviours rather than general needs.

For a contributor, the practical point is that translations are handled by the build, so a change to a locale file does not need a separate compilation step before testing.

The version itself is dynamic, read from fiduswriter/version.txt, and the dependencies are dynamic as well, which is how a project with this many optional extras keeps the manifest small.

A 5.0 alpha on top of a stable 4.1 line

The release history shows a project in the middle of a major version change, and the cadence is steady.

The three most recent releases are v5.0.0-alpha3 from 2026-10-20, v5.0.0-alpha2 from 2026-10-09 and v4.1.21 from 2026-09-11. So a stable 4.1 patch line and a 5.0 alpha are both being worked on, about a fortnight apart, with the alpha being the forward line.

The repository is not archived, the default branch is main, and the last push is very recent, right after the newest alpha. The project is clearly active.

For an institution deciding what to deploy, the practical question is which line to run. The 4.1.21 release is a mature patch of a stable branch, and the package metadata classifies the project as production or stable with an intended audience of science and research, which is the right classification for a system that holds unpublished manuscripts.

Two packaging artefacts are worth knowing about. There is a Snap package with its own badge, and a Debian build script, and the readme lists the Debian APT repository as the recommended route, so the most polished install is probably the one on Debian-family systems.

The coverage status is tracked through Coveralls, and the project uses pre-commit with an.ackrc and a.atomignore for Atom package publishing, both of which are older conventions that hint at the age of the deployment tooling around it.

Editorial conclusion

Fidus Writer suits a research group or an academic publisher that needs collaborative editing with real citation and formula support, and that wants to publish the same manuscript to several media from one source. It does not suit a team that needs a permissive licence, since the original code is AGPL, and it does not suit someone who expects the output to be a Word document you can open and edit further, since the export is a rendering of a structured document rather than a round trip. Before deploying, pick the package that matches your distribution, read the installation guide rather than the quick start, and check the optional dependencies for the features you actually need, since the citation, pandoc and books integrations are separate extras.

Frequently asked questions

Official sources

1. fiduswriter/fiduswriter on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases