ONLYOFFICE DesktopEditors: this repository is six other repositories mounted in

Six of the seven top-level directories are other repositories

The repository root contains a handful of files and then six directories that are not code. There is a submodule configuration file at the root, and the readme has a section listing these components as separate projects with their own links. The frontend for the desktop application, the desktop SDK, the server core used for format conversion, the JavaScript SDK, the web frontend shared with the document server, and the spellcheck dictionaries are all separate repositories with separate names and separate link targets. So this repository is an assembly point: it defines which version of which component goes together, and the submodule file pins them. That has two consequences. A contributor cloning this gets no implementation until submodules are initialised, and the build instructions are not here either but in a separate tools repository. The remaining directories are screenshots and .github.

Three packaging formats each have their own source repository

The install section offers the usual native packages first, listing deb, rpm, exe and dmg formats obtained from the project's website, and then offers three alternatives. Snap, Flatpak and AppImage are each named with a download location, and each of the three is followed by a link labelled as the official source code for that specific package, pointing at a different repository. So a user who wants to trace what is inside a Flatpak has three more repositories to read, none of which is this one and one of which lives under a different organisation entirely, since the Flatpak source is hosted in the packaging project's own repository rather than the vendor's. Add the separate tools repository that holds the build instructions and the total is ten repositories to read to understand how a desktop application gets onto a machine. That is a normal arrangement for a project of this size and it is still a real cost for anyone auditing it.

Working without a network is the strongest claim in the file

The description sentence says the application allows creating, viewing and editing documents stored on your machine without an Internet connection. That is the distinguishing capability compared with a hosted document suite, and everything else in the readme is either a standard editing feature or a way to add cloud back. The listed cloud targets for real-time collaboration are numerous and include ONLYOFFICE, Moodle, Box, Dropbox, ownCloud, Nextcloud, Seafile, Liferay and kDrive. So the architecture is offline-first with collaboration as an opt-in that requires connecting. That ordering matters for a deployment decision. A team that handles documents under a confidentiality regime can use the suite and never configure a cloud connection, and the readme does not require an account or a sign-in to reach the editors. The feature list also includes digital signatures and password protection, which are the two features that matter most for a document that will not leave the machine.

The plugin API is scoped to what the file format cannot express

The plugins section contains one sentence that defines the whole extension model, and it is a scoping statement rather than a description. Plugins let developers add specific features to the editors that are not directly related to the file format, with an API documentation link and a separate repository for the plugins themselves, plus a marketplace for browsing what already exists. That is a sensible boundary for an office suite, because a plugin that changes how a document is stored or how a format is parsed will corrupt files that another application has to read later. Anything that is genuinely about the document belongs in the format, and anything about the working environment belongs in a plugin. For a developer evaluating it, the API documentation and the plugin repository are the two places to look, since neither is in this repository.

The recorded primary language is unknown, and conversion covers seventeen formats

Two metadata facts are worth recording. The primary language recorded for this repository is unknown, which for an assembly point containing no implementation is arguably correct and for a project of this prominence is a gap in its published description. And the conversion capability belongs to one of the submodules, described as enabling conversion between the most popular office document formats, with the list running to seventeen entries across text, spreadsheet and presentation families: DOC, DOCX, ODT, RTF, TXT, PDF, HTML, EPUB, XPS, DjVu, XLS, XLSX, ODS, CSV, PPT, PPTX and ODP. The readme's own compatibility claim is narrower, limited to the three OOXML formats the suite says it is fully compatible with. So the application reads and writes three formats properly and converts to and from a much wider set, and the conversion is handled by the server core component rather than by the desktop frontend.

The licence link points at a document host rather than the file in the tree

The licence section states the Affero General Public License version three, describing it as ensuring transparency and commitment to the open-source community. The link labelled as the licence, however, does not point at the licence file in the repository. It points at a link on a document sharing service hosted on the vendor's own domain. There is a licence file at the root of this repository, and it is not what the readme sends you to. That is a small thing with a real consequence: the authoritative text should be the file in version control, because a document on a sharing service can be replaced without a commit and without any reviewer seeing it. It also means a tool that resolves licence references automatically from the readme will not find a licence. The licence choice itself is worth pausing on independently, since the Affero variant adds a condition triggered by offering the software over a network, which is the deployment model the readme also advertises with its collaboration features.

A spellcheck dictionary is committed for the documentation

Two root files describe how the prose in this repository is checked. A configuration file governs the markdown linter, and a personal word list for the spell checker sits beside it, carrying the extension that identifies it as an English dictionary in the expected format. Committing a word list is how a documentation set stops a spell checker from flagging product names, and the size of such a file is a rough measure of how many proprietary terms a project has. A change log is also committed. Otherwise the root is sparse: the submodule file, the licence, the readme, the screenshots, and the six component directories that hold the actual project.

Editorial conclusion

ONLYOFFICE Desktop Editors suits an organisation that needs to open and edit office documents without sending them to a server, since working without a network connection is the claim the readme leads with. Two things to check first. Understand where the code actually is, because this repository is an assembly point holding submodules rather than the implementation, so a contributor has to initialise submodules before anything builds. And note that the licence is the Affero variant, which carries the network use condition, so an organisation that exposes the suite to users over a network needs to read what that obliges them to do. A team that wants a single self-contained binary from one source tree should use the packages rather than the repository.

Frequently asked questions

Official sources

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