OpenMS: a C++ library for LC-MS data management and analysis

An infrastructure library, not a finished application

OpenMS is described in two sentences: an open-source software C++ library for LC-MS data management and analyses, offering an infrastructure for rapid development of mass spectrometry-related software. That second clause is the one to hold on to. The deliverable is not a program you install and click, it is a set of building blocks plus the analysis tools built on them, aimed at people writing mass spectrometry software. The topic list gives the domain precisely, with proteomics and metabolomics alongside mass spectrometry, ms-data, algorithms and analyses, and the language is C++. The project site is openms.org, the homepage in the repository metadata is openms.de, and the repository is described simply as the codebase of the OpenMS project. There is no homepage field, no separate documentation site in the metadata and no releases under the name most people would expect, which tells you the published artefacts live elsewhere.

The tree shows a library, a tool suite and a careful build

The top level directory listing is the most informative thing about this repository. There is a src directory for the library, a tools directory for the command line tools built on it, a doc directory, a share directory for data files, and a cmake directory beside the top level CMakeLists.txt and a CMakePresets.json. The build has clearly been thought about beyond the minimum. There is a CTestConfig.cmake, so the test suite is wired to CTest, a .clang-format so formatting is enforced rather than debated in review, and a vcpkg.json with vcpkg-configuration.json and a vcpkg-overlays directory, which is how a C++ project pins its third party dependencies on Windows. Docker images live in dockerfiles, a .devcontainer directory provides a ready made development environment, and .git_archival.txt and .gitattributes point at a repository that can export a usable version string from an archive. A CHANGELOG, an AUTHORS file, a CITATION.cff and a THIRDPARTY directory make the project citeable and its bundled third party code accountable, and ARCHITECTURE.MD, AGENTS.md and CLAUDE.md suggest the code base is expected to be navigated by tools as well as by people.

Distribution runs through conda rather than a download page

There is no download link in the README and no install instructions, which for a C++ library with a vcpkg dependency set is not an oversight but a statement of how the project expects to be consumed. The badges point at two conda channels. One is the openms organisation on anaconda.org, and the other is bioconda with a package named pyopenms, so there is a separate distribution for the Python side of the project alongside the C++ package itself. Bioconda is the channel that many bioinformatics projects use, and being packaged there means the dependency resolution, the platform matrix and the update cadence are handled by the conda community rather than by the project. The documentation is published on Read the Docs at openms.readthedocs.io, and the API reference is generated with Doxygen and archived on the openms.de domain, which is a different host from the docs, so the two are maintained separately. For questions there is a Discord server and a Gitter chat, and the project participates in Hacktoberfest, listed among the repository topics.

Three licence files and a badge that does not match

The licensing is the one place where the repository contradicts itself, and the contradiction needs resolving before anyone ships a binary. The README badge announces a 3-clause BSD licence, and 3-clause-bsd is one of the repository topics, which suggests permissive licensing is the intent. However, the licence field in the repository metadata is recorded as a custom one that GitHub cannot classify, which is what happens when the root licence file is not a recognised licence text. And there are three licence files in the root at once, LICENSE, LICENSE.md and License.txt, which is usually the sign of a transition in progress, a relic of an older licence alongside a newer one, or a copy for a specific downstream build. The topics list also includes the string 3-clause-bsd as a separate tag, which is a topic label rather than the legal text. This is a case where reading the files beats reading the badges, and where asking the project is the right move if you intend to redistribute. The same caution applies to the bundled third party code in the THIRDPARTY directory, which has its own terms.

A develop branch and dated release tags

The branching and tagging tells you how releases are cut. The default branch is develop, which is the usual arrangement where that branch is the integration branch for the next release, and the tags are dated release points: v3.6.0 on 2026-09-30, release/3.5.0 on 2025-12-11 and release/3.4.1 on 2025-05-20. The mix of naming conventions is worth noticing, one tag uses the v prefix and the other two use a release/ prefix, so a script that filters tags by name has to handle both patterns. The release cadence implied by those dates is a few releases a year, with roughly eight months between 3.4.1 and 3.5.0 and about nine months to 3.6.0. The repository is not archived and the last push was on 2026-10-20, weeks after the 3.6.0 tag, so the develop branch is carrying work toward a later release. The CHANGELOG file at the root is the place to read what changed between those points, and the CITATION.cff file gives the metadata a citing tool needs.

What the README does not tell you

The limitation here is not the software, it is the documentation in the repository, and it is worth being blunt about it. The README consists of a title, a set of badges and two sentences of description, so it answers none of the questions a new user has. Which version of the library do I install, what are the dependencies beyond the ones vcpkg manages, how do I build from source, which tools are in the tools directory and what each one does, what file formats are supported, how large is a typical dataset, what does the API look like. None of that is in the repository, and the answer is the Read the Docs site, the Doxygen reference and the project website, all hosted outside the repository. The practical consequences are that you cannot evaluate the project from a clone, and that a downstream packager has to read the Doxygen and the CMake files to work out the build. The repository is not abandoned, the badges for tests, coverage, documentation and the dev container are all live, but the entry point for a newcomer is the documentation site rather than the code.

Editorial conclusion

Adopt OpenMS if you are writing mass spectrometry software in C++ and want the LC-MS data infrastructure and the existing tool suite rather than your own file format handling. Do not judge it from its README, which is a pointer rather than a guide, and read the three licence files in the repository root before you ship a binary, since the badge and the repository metadata do not agree.

Frequently asked questions

Official sources

1. Issues
2. OpenMS/OpenMS on GitHub
3. Project website
4. README
5. Releases