LibreOffice Core: The Source Repository Behind the Open-Source Office Suite

Read-Only Mirror and the Gerrit Contribution Path

The GitHub repository is described in its own README as a read-only mirror. Pull requests on GitHub are not accepted. Contributions must go through Gerrit, the code-review system used by The Document Foundation. The README gives the Gerrit URL directly and instructs developers not to download the ZIP archive but to use git clone instead, because the build system depends on the full git history.

This matters practically: a developer who forks the GitHub repository and opens a pull request will receive no review. The Gerrit workflow requires a separate account and a signed contributor agreement. The mailing list [email protected] and IRC channel #libreoffice-dev on irc.libera.chat are the documented support channels, and the README notes that no subscription is required for the mailing list.

Build Toolchain Requirements by Platform

The README documents minimum compiler and OS versions for each supported platform. On Linux, the runtime baseline is RHEL 9 or CentOS 9, and the build requires either GCC 13 or Clang 18 with libstdc++ 11. On Windows, runtime requires Windows 10, and the build uses WSL as a helper alongside Visual Studio 2022. On macOS, the runtime baseline is macOS 11, and the build requires macOS 13 or later with Xcode 14.3 or later.

Java is required for building many parts of LibreOffice. The minimum Java Development Kit version is 17. The exact list of modules that depend on Java is maintained in the TDF wiki under Development/Java. Python 3.11 is the baseline Python version, tied to the version available in SUSE Linux Enterprise Desktop and the Maintenance Support version of Red Hat Enterprise Linux.

For initial setup on Windows and macOS, the project provides LODE (LibreOffice Development Environment) scripts. The TDF wiki at wiki.documentfoundation.org/Development/How_to_build holds the platform-specific build instructions.

Module Layout: Two Hundred Modules and Where the Core Logic Lives

The repository contains over 200 modules, each with its own README.md file. Those module READMEs are compiled into a documentation site at docs.libreoffice.org. The main repository README calls out the most important modules explicitly.

The system abstraction layer is in sal/. Basic internal types like Rectangle and Color are in tools/. The widget toolkit and rendering abstraction live in vcl/. The UNO framework that builds toolbars, menus, and the application chrome is in framework/, using XML descriptions from the /uiconfig/ files. The legacy core framework shared by Writer, Calc, and Draw is in sfx2/, handling document model, load, and save operations. Drawing model helpers, including much of Draw and Impress, are in svx/.

The application entry point is in desktop/, where main() for the application lives. Writer is sw/, Calc is sc/, and Draw/Impress is sd/. Graphics-related code is distributed across basegfx/ for algorithms and data types, canvas/ for the UNO canvas rendering model, and drawinglayer/ for rendering drawable objects.

Two Development Paths: Extension SDK vs Direct Code

The README explicitly describes two ways to develop for LibreOffice and rates them. The first is the SDK extension path, which uses UNO APIs and is also used by StarBasic macro scripting. The README calls this the "somewhat less recommended" approach, noting that the UNO APIs are "extremely generic."

The second path is working directly in the codebase. The README says this avoids arbitrary limitations of the scripting APIs and is "more simple and intuitive" for a reasonably able C++ programmer. The trade-off is that contributing a core change requires the full build toolchain and the Gerrit review process, which takes significantly more setup than writing an extension.

This distinction affects who should use this repository. An engineer who wants to automate spreadsheet tasks or add a menu item is better served by the SDK. A developer who wants to fix a rendering bug, add a file format importer, or improve a core algorithm needs the core repository.

Include Directive Rules and the Compiler Plugin Enforcement

The README includes a specific section on include directive rules for C and C++ files. The rule is: use the quoted form ("...") only when the included file is next to the including file; use the angle-bracket form (<...>) for everything else. UNO API include files consistently use double quotes for the benefit of external users.

These rules are enforced by a Clang compiler plugin: loplugin:includeform, defined in compilerplugins/clang/includeform.cxx. This means the build will reject includes that violate the convention during compilation. A contributor patching a module needs to follow the rule or the build will fail. The README notes that using Clang compiler plugins on macOS requires compiling your own Clang because Xcode does not provide the compiler plugin headers.

Static Analysis and Code Quality Tools

The README mentions PVS-Studio as a static analysis tool for C, C++, C#, and Java code. A Coverity scan badge is also included in the README, indicating integration with Coverity's static analysis service. These are tools used by the project itself and visible to contributors who want to understand what automated checks run against the codebase.

The repository includes a .clang-format file, an .editorconfig file, and .cspell/ configuration for spell checking. The .gitreview file points to the Gerrit server. The .gitpod.yml and .gitpod.dockerfile files support Gitpod-based development environments, giving contributors a path to a configured browser-based IDE without setting up the full local toolchain.

Licensing and the GPL-3.0 Obligation

LibreOffice is released under GPL-3.0 for most of the codebase, with portions also covered by the LGPL and MPL. The repository root contains COPYING, COPYING.LGPL, and COPYING.MPL. This multi-license structure reflects the historical origins of the code, parts of which trace back to OpenOffice.org.

GPL-3.0 has implications for any organization that modifies and distributes LibreOffice internally or to customers: the modified source must be made available. The SDK extension path, which uses the UNO API rather than the core C++ code, is subject to LGPL terms in the relevant parts, which is more permissive for proprietary integration. Organizations building on top of LibreOffice without distributing the binary externally typically use the SDK path to avoid the copyleft obligation on their own additions.

The last push to the repository was on 2026-09-27, indicating the core project is actively maintained.

Editorial conclusion

The LibreOffice core repository is for developers willing to work inside a large C++ codebase, set up the full build toolchain, and submit patches through Gerrit rather than GitHub pull requests. It is not for users who want to add functionality via macros or the SDK extension API, though those paths exist separately. Before starting, read the platform-specific build instructions on the TDF wiki, confirm your compiler version meets the minimums, and determine whether the Java-dependent modules you need require JDK 17.

Frequently asked questions

Official sources

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