SOGo compiles two Objective-C projects from two repositories with a GNU makefile

Standards are the product, and that is a real architectural commitment

The description is a list of capabilities followed by a design statement, and the design statement is the second half. It offers calendaring, address book management, a full webmail client, and resource sharing with permission handling, and it makes use of documented standards including IMAP, CalDAV and CardDAV, which gives native connectivity without plugins to clients such as Microsoft Outlook, Apple iCal, the iPhone, the Thunderbird add-on and a range of mobile devices. That last clause is the one to hold onto. The alternative architecture for a groupware server is to publish its own API and ship a connector for every client, and that is what a vendor-integrated product does. A standards-based server instead does not care what the client is, so a new phone or a new calendar application works on day one without anyone writing code. The cost is that implementing CalDAV and CardDAV correctly is genuinely hard, because the specifications are large and clients are inconsistent about which parts they implement, and because a server that claims the standard has to accept what the specification allows even when it is inconvenient. So the standards claim is a real differentiator and a real maintenance obligation, and the feature list above it is the easier half of the product.

Two repositories, because SOGo sits on top of SOPE

The build section is short and it tells you the structure. To compile the suite you first need to obtain the source of both the suite and a second project, and the readme links two separate archive downloads for them. The second project is a framework, and it is not optional: the suite's own directory listing includes a subdirectory for it, and there is a submodules file at the top of the repository, which is the mechanism that would normally pull it in. So the dependency is real, it is external, and the readme's advice is to download the archive rather than to initialise the submodule. That is a meaningful signal about the project's age and its conventions. Modern C or Objective-C projects would use the submodule mechanism and pin a commit. This one documents a manual download of two archives, which is what you do when a project has a long history of telling people to fetch a second tree by hand. The primary language field being Objective-C is worth noting against that: this is a GNUstep-era codebase, which is a technology choice with real consequences for how you deploy it, since it means an Objective-C runtime and a set of GNUstep libraries on the host. The top-level listing confirms the vintage in other ways, with a change log and an older change log kept side by side and a version file.

A dev container, a makefile, and instructions that live somewhere else

The build tooling is old-style and the readme is candid about it. The compile instructions are not in the repository, and the readme points at a support page and a separate how-to:

https://sogo.nu/support/faq/how-do-i-compile-sogo.html

The top level has a GNU makefile and a general makefile, a configure script, a Scripts directory, a Tools directory, a packaging directory and a Tests directory, plus separate top-level directories for the API layer, the ActiveSync support, an Apache integration directory, the documentation, the main application code, a migration directory, the object layer, a user interface directory and the framework subtree. That is a directory-per-concern layout of the kind that C and Objective-C codebases grew in the 2000s, and it is legible in a way that a flatter modern layout would not be. The dev container is the modern addition, with a directory and its own readme, and it is the fastest way to get a working build if you are starting today. Everything else defers to a website: the readme links a support page, and separately a how-to page for compilation instructions, so the actual build steps are not in the repository. That is a documentation structure choice rather than a quality problem, but it does mean the readme is not self-sufficient and a reader without network access cannot build from it. The version file and a release configuration script at the top suggest version strings are generated rather than hand-maintained, which is another sign of process maturity.

Forty-one named maintainers, which tells you what kind of project this is

The translations section is the longest part of the readme and it is not filler. Each entry names a language and the person responsible for it, and there are around forty of them, covering European languages, several Asian languages, a set of regional variants for Portuguese, Spanish, Chinese and the two Norwegian written standards, and a Serbian entry that exists twice for two scripts. Two languages are attributed to the company itself. That structure is a project with a governance model, not a hobby: named maintainers per locale means a change to a user-facing string has an owner, and it means the localisation surface is treated as part of the product. It also tells you something about the deployment reality. A groupware suite that is officially translated into this many languages is one being run by organisations in those countries, which is consistent with the self-hosted positioning and inconsistent with a product aimed at one enterprise market. Two process signals sit alongside it. There is a translation service configuration directory at the top, which is the usual way to route string changes through a translation platform, and the readme links a separate how-to page for anyone who wants to add a language not on the list. The readme's contribution section reinforces the same impression, listing documentation work, feature requests, mailing list discussion, patches and new translations as five distinct ways to help.

Two licence files, a Thunderbird connector, and an ActiveSync directory

Three things at the top level are worth drawing out. First, the licensing: there are two licence files at the root, one for the GPL and one for the LGPL, so the project uses both, and the readme describes it as a free and open source groupware solution without naming a single grant. Dual licensing like that is normal in a codebase where older components carry one licence and newer ones another, and it means a distributor needs to know which is which rather than assume. If you are packaging the suite, that is a question for the licence headers in the source rather than for the readme. Second, the Thunderbird connector is a separate repository, and the readme names the minimum version of the mail client it targets. That is a meaningful detail because it tells you the connector is not part of the build and has its own release cycle, so a deployment has two things to keep current rather than one. It also sits slightly against the standards claim in the description: a connector for one mail client exists because that client does not speak the relevant standards natively, which is a reminder that the client list in the description is a goal for the standards-based clients and a reality for the connector-based ones. Third, there is a top-level directory for ActiveSync support, and the presence of a mobile device sync protocol alongside a standards-based story is exactly the shape of a product that has to serve both worlds.

Editorial conclusion

Adopt SOGo if you need a self-hosted groupware server whose clients work without plugins, because speaking the documented standards rather than a proprietary protocol is the property that makes Outlook, desktop calendars and phones work against it, and that is exactly what a hosted suite takes away. Do not adopt it as a first groupware deployment, because the build is two Objective-C projects from two repositories with a makefile and instructions on a separate site, which is not a weekend project. Four things to verify. Where the build instructions actually are, since the readme sends you to a support site and a separate how-to page rather than describing the build itself. That you can obtain both source trees, because the readme says you need the suite and a second framework project and points at two separate archives, plus a submodules file at the top of the repository. Which version you install, since the release names carry a product line, a major and a patch, and the current series has shipped monthly and near-monthly patches. And that the dual licensing is what you expect, since two licence files sit at the root and the project describes itself as free and open source rather than naming a single grant. The last push was on 2026-09-21 and the newest release is 5.12.11 from 2026-09-14.

Frequently asked questions

Official sources

1. Alinto/sogo on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases