LibreOffice/core: a C++ codebase that rewards patient contributors

What this repository actually is

LibreOffice/core is the read-only mirror of the main LibreOffice source tree. The README is clear about the contribution model: no pull requests, use Gerrit instead, and do not download a zip. The repository is not a product you install; it is the working tree for the office suite. The description says it is read-only, which means you clone it, build it, and submit patches through the separate Gerrit instance. The primary language is C++, and the license is GPL-3.0. The README positions the codebase as the recommended way to add features, as opposed to writing extensions against the UNO API. If you are an engineer evaluating whether to fork or vendor this code, the read-only nature and the Gerrit workflow are the first constraints you will hit.

The build chain is the real gatekeeper

The README lists exact baselines for each platform. On Windows, the runtime is Windows 10, and the build uses WSL as a helper plus Visual Studio 2022. On macOS, the runtime is 11, and the build requires macOS 13 or later with Xcode 14.3 or newer. On Linux, the runtime is RHEL 9 or CentOS 9, and the build needs either GCC 13 or Clang 18 with libstdc++ 11. Java is required for many parts, with JDK 17 as the baseline. Python must be at version 3.11. These are not suggestions; they are the versions used by The Document Foundation's own builds. If your toolchain is older, you will likely face compilation failures before you can run the suite. The README also notes that Clang compiler plugins require Clang 18, and on macOS you must build your own Clang because Xcode does not ship the plugin headers. That is a concrete cost for anyone on macOS who wants to use the plugin system.

Module layout: where the useful code lives

The README maps the codebase into modules. The system abstraction layer is in sal/, basic types like Rectangle and Color are in tools/, and the widget toolkit and rendering abstraction is in vcl/. The framework/ module builds toolbars and menus, while sfx2/ holds the legacy core framework for Writer, Calc and Draw, including document model and load/save logic. The application entry points are in desktop/, with sw/ for Writer, sc/ for Calc, and sd/ for Draw and Impress. There are also graphics libraries: basegfx/ for graphics algorithms, canvas/ for the UNO canvas model, cppcanvas/ for C++ helpers, and drawinglayer/ for view rendering. This layout matters because the README says each module has its own README.md, and the docs are aggregated at docs.libreoffice.org. So if you want to change how Calc loads a file, you start in sc/ and sfx2/, not in a single monolithic source file.

Include directive rules are enforced by a plugin

The repository has a specific rule for C and C++ include directives. Use the quoted form "..." only when the included file is next to the including file. Otherwise use the angle bracket form <...>. The UNO API include files must use double quotes, for the benefit of external users. This rule is not just a style suggestion; it is enforced by a compiler plugin called loplugin:includeform, located in compilerplugins/clang/includeform.cxx. That means any patch you submit will be checked against this rule. The README links to a mailing list message from 2017 that explains the rationale. For a contributor, this is a concrete coding standard you must follow before your patch is accepted. It also shows that the project has invested in tooling to keep the codebase consistent, which is useful to know if you are planning to merge upstream changes into a fork.

Two development paths: SDK versus core

The README presents two ways to develop for LibreOffice. The less recommended path is to use the SDK to build an extension, using the UNO APIs that also serve StarBasic macros. That path reuses the generic UNO interfaces, and you can read the API docs and Developers Guide. The recommended path is to work on the codebase itself. The README argues that working in the core is easier to compile and build, avoids limitations of the scripting APIs, and is more intuitive for a reasonably able C++ programmer. This is a clear trade-off. The SDK path is lighter: you do not need to build the entire suite, but you are constrained by what the UNO API exposes. The core path gives you full access, but you must meet the build baselines and understand the module structure. If your goal is a small macro or a simple extension, the SDK is the wrong tool. If your goal is a deep change to document loading or rendering, the SDK will not let you do it.

Limitations and failure modes

The most obvious limitation is the build complexity. The README lists six platform targets, including iOS and Android, but those are only for LibreOfficeKit, not the full desktop suite. The Emscripten/WASM target requires a browser with SharedMemory support, which means threads and atomics must be enabled. That is a niche constraint. Another failure mode is the compiler plugin requirement: if you use Clang, you need version 18, and on macOS you must compile your own Clang to get plugin headers. That is a significant setup cost. The README also warns that the code can be hard to get into at first, and the two hundred modules mean you can easily get lost. There is no release history in the retrieved data, so you cannot rely on a stable release branch from this repository. The read-only nature means you cannot contribute directly; you must use Gerrit, which is an extra step for developers used to GitHub pull requests.

Alternatives: the SDK and other office suites

The direct alternative is the LibreOffice SDK, which is mentioned in the README. The SDK lets you build extensions using the UNO API without touching the core codebase. The difference in approach is fundamental: the SDK gives you a stable, generic API layer, while the core gives you direct access to the C++ implementation. If you need to add a toolbar button or a macro, the SDK is sufficient. If you need to change the document model, you must work in the core. Outside LibreOffice, other office suites exist, but the README does not compare them, and the material does not provide enough detail to make a fair comparison. The only verifiable alternative from the source is the SDK path. That is the one to weigh against the core repository.

Maintenance and license implications

The repository is under GPL-3.0, which means any derivative work you distribute must be under the same license, unless you have separate licensing from The Document Foundation. The README does not discuss dual licensing, so you should assume the GPL applies to the whole codebase. Maintenance cost is high: the README requires you to keep up with compiler and OS baselines, and the build chain includes Java, Python, and platform-specific toolchains. The project uses Coverity and best practices badges, but the README does not describe a release cadence. The last push date is unknown, and no recent releases were retrieved, so you cannot infer how frequently upstream updates land. For a fork, you would need to track upstream changes through Gerrit, which is a separate workflow from the usual GitHub merge process. The include rule plugin is part of the build, so any local changes that violate it will fail the build, which is a maintenance constraint you must respect.

Editorial conclusion

Adopt LibreOffice/core if you are a C++ programmer who wants to add a generally useful feature to Writer, Calc, Draw or Impress, and you can meet the build baselines: GCC 13 or Clang 18 on Linux, Visual Studio 2022 on Windows, or Xcode 14.3 on macOS. Do not adopt it if you only need a small macro or an extension, because the README explicitly says the SDK path avoids the full codebase. Before you start, verify that your system matches the runtime and build versions listed in the README, and confirm that you can use Gerrit for patches, since this repository does not accept pull requests or zip downloads.

Official sources

1. Official documentation
2. Official README
3. Project repository