CommunityServer: the product was renamed at version 11.0, the repository was not, and the README has no install command

The product was renamed at version 11.0 and the repository was not

The repository name and the product name have been out of step for several major versions.

The README announces ONLYOFFICE Groups, and states that it was formerly Community Server: a free, open-source collaborative platform that acts as the central hub for a team, managing documents, projects, clients, and email in one place. One sentence dates the change precisely, saying that starting from version 11.0, Community Server is distributed as ONLYOFFICE Groups under the Apache 2.0 license.

Everything downstream kept the old name. The repository is still CommunityServer, the Docker image is still published from a repository named Docker-CommunityServer, the issue tracker lives under the old path, and the campaign parameter carried on every link is still GitHubCommunityServer.

That matters for anyone arriving from a search rather than from the vendor's own navigation. A product called Groups is documented in a repository called CommunityServer, at a version numbered 12.x, and the first thing the file explains is that the two names refer to the same thing.

The README contains no build command and no install command

The installation surface of this README is a list of links, and that is all it is.

There is no clone command, no build command, no framework version requirement, no database prerequisite, and no configuration step. In a repository whose root contains a Visual Studio solution, that absence is the first thing to notice.

What the file offers instead is a pointer to a Docker image maintained in a separate repository, described as the quickest and easiest way to deploy ONLYOFFICE Groups, and a pointer to the help center for installation options, specifically a page under the Workspace installation path for Community on Linux. A third link covers creating and connecting custom modules.

So the documented path is: build an image from somewhere else, or follow vendor documentation for the platform of your choice. Anyone who wants to compile this source tree has to work that out from the solution file and the NuGet configuration without a written procedure to follow.

Everything except the groupware lives in four other repositories

The feature list covers five areas, and the workspace section explains why the repository itself covers only one of them.

Document management organizes and shares files with flexible access permissions, integrates with Google Drive, Box, Dropbox, OneDrive, and ownCloud, and embeds documents into websites or applications. Project management creates projects with milestones, tasks, and subtasks, visualizes workflows with Gantt charts, and tracks time spent to generate automated reports. The CRM keeps a customer database with contacts and logged interactions, generates invoices, tracks payments, and captures leads through web-to-lead forms. Collaboration tools cover blogs and forums, an internal wiki, a shared calendar, a mail client that aggregates several accounts, and a People module for a central directory.

The missing piece is the document editor. The README states that Groups is the foundation of the Workspace suite and that functionality is enhanced by integrating other components, naming four: ONLYOFFICE Docs for online document, spreadsheet, presentation, and PDF editing, a Mail Server for running a corporate mail domain, Talk for real-time messaging, and a Control Panel for central administration.

Each of those four is a separate repository with its own release cycle, so a complete deployment is five moving parts rather than one.

The release line skipped seventeen months and the newest tag drops a component

Three releases are visible, and the gaps between them are the story.

v12.7.0 was tagged on 2024-10-21 and v12.7.1 on 2024-12-23, two months apart. Then v12.8 arrives on 2026-05-05, about seventeen months later. The most recent commit carries the same date as that tag, 2026-05-05.

The tag naming is inconsistent at the same time. The oldest two releases are tagged with a three-part version, v12.7.1 and v12.7.0, while the newest is a two-part v12.8, even though its release name inside is v12.8.0. So the newest tag in the repository is not the same string as the version it releases, which matters for any script that matches tags against versions.

For an operator, the practical consequence is that a gap this long makes the intermediate versions hard to reason about, and that the newest release is the only one recent enough to assume reflects the current state of the tree.

Two escape characters survive in the text, which dates the file's processing

The prose is not quite markdown any more, and the traces are small but informative.

Two sentences end with a backslash-escaped exclamation mark: the opening description of the platform ends with what reads as an escaped bang, and the closing line thanking readers for feedback does the same. A converter that escaped punctuation for some downstream format wrote those backslashes into the file, and nobody removed them.

The headings carry the same treatment in a different way. Every section title in this README is wrapped in bold markers and followed by an emoji, from the welcome line through the four feature headings and the two resource sections, so the document is styled rather than plain.

None of this changes what the project does. It does tell a reader that this file has been through at least one automated round trip, which is worth keeping in mind when a line in it looks machine-made, and it is a reminder that the README is maintained by the vendor's publishing pipeline rather than edited by hand.

Third-party licensing is recorded twice, and NuGet has its own configuration

The root listing describes a Visual Studio project rather than a self-contained product.

There is Studio.sln as the solution, a NuGet.Config at the root, and a .nuget directory beside it. There are also .gitmodules, so parts of the tree arrive as submodules rather than as tracked files.

Third-party licensing appears in two places at once: a 3rd-Party.txt file in the root and a licenses/ directory holding the texts. For an Apache 2.0 project whose README makes a point of the licence, having both a summary file and a directory of full texts is thorough rather than redundant.

The remaining directories describe the shape of the product. common/ holds shared code, module/ holds the modules the custom-modules documentation talks about, web/ is the web front end, build/ is the build, and redistributable/ is where redistributable artifacts are kept. Two project-level documents sit in the root as well, a CHANGELOG.md and a Roadmap.md.

Notably absent from the root are a Dockerfile and any compose file, which is consistent with the README sending deployment to a separate repository.

Every link in the file is a tracked campaign link, including the help center

The header block is worth reading as a document in itself, because it is all links.

The first element is a link to the vendor website carrying three tracking parameters, and the fourth element is a link to the same website with the same three parameters. Between them sit four inline links, a website, a help center, an API site, and an about page, each carrying the identical parameter set with a source of github, a medium of cpc, and a campaign named after this repository.

A fourth row of links goes out to Facebook, X, YouTube, and Instagram with no parameters at all, and a fifth row points at the Apache licence text and at this repository's releases page.

So the technical destinations are tagged as marketing destinations. The help center link, which is the one a self-hoster actually needs, arrives through a campaign URL, and the same is true of the API documentation link later in the file. Nothing is hidden, but the file presents technical documentation and advertising through one mechanism.

Editorial conclusion

Use it if you want one self-hosted system for documents, projects, customers, and mail rather than four separate services, and evaluate it as the foundation of a suite rather than a standalone app, since editing, mail, messaging, and administration are separate repositories with their own release cycles. Before you commit, read the deployment path properly: the README here contains no build or install command, so the vendor's Docker image and help center are the only documented routes. And check the release line, because the jump from v12.7.1 to v12.8 spans about seventeen months.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. ONLYOFFICE/CommunityServer on GitHub
3. Project website
4. README
5. Releases