OCA-Module einsetzen: Nutzen, Pflege, Risiken
Kurz gesagt
Die Odoo Community Association (OCA) ist ein gemeinnütziger Verein in der Schweiz, der mehrere tausend Odoo-Module unter Open-Source-Lizenzen über GitHub bereitstellt. Für den Produktivbetrieb zählen vier Angaben: Versionsabdeckung, benannte Maintainer, die letzte Version im Manifest und der Teststatus in CI und Runboat. Auf Odoo Online laufen eigene Module nicht; mit Odoo Enterprise deckt der Herstellervertrag nur Covered Extra Modules ab.
Das Wichtigste
- Die OCA ist ein gemeinnütziger Verein nach Schweizer Recht mit Sitz in Lausanne (Statuten Artikel 1 und 2).
- OCA-Module sind Odoo-Addons aus Python-Dateien und zählen als eigene Module; auf Odoo Online lassen sie sich deshalb nicht betreiben (Odoo-Dokumentation 20.0).
- Vor dem Einsatz prüfen: Versionszweig, Maintainer im Manifest, letzte Version und Teststatus in CI und Runboat. Ein Upgrade verlangt Modulquellcode für die Zielversion; bei OCA-Modulen steht er im Zweig der Zielversion bereit.
- Der Reifegrad steht im Manifest (development_status); fehlt der Schlüssel, gilt Beta.
- Ohne benannten Maintainer führt das Project Steering Committee des Repositories das Modul.
- Für Kunden mit Enterprise-Abonnement deckt Odoo S.A. nur Covered Extra Modules ab; Sicherheitshinweise schließen Extra Modules aus.
OCA-Module stehen unter Open-Source-Lizenzen, und der Quellcode liegt offen. Gepflegt werden sie von Freiwilligen und von Firmen, die ihre Arbeit teilen. Wer ein solches Modul produktiv einsetzt, trägt die Prüfung deshalb selbst: ob es für die eigene Odoo-Version vorliegt, wer das Modul pflegt, wann es zuletzt geändert wurde und ob die automatischen Tests laufen. Dieser Artikel zeigt, wo diese vier Angaben stehen und was ein Befund bedeutet.
Was die OCA ist
Die Odoo Community Association (OCA) ist ein gemeinnütziger Verein nach Schweizer Recht mit Sitz in Lausanne (Statuten Artikel 1 und 2). Sie ist von Odoo S.A. unabhängig und wird von ihr nicht kontrolliert: Odoo S.A. ist ein gewinnorientiertes Unternehmen, die OCA ein Verein ohne Gewinnabsicht (FAQ der OCA zu Rechtsform und Verhältnis zu Odoo S.A.). Nach ihren Statuten fördert sie die gemeinschaftliche Entwicklung von Odoo und veröffentlicht alle von ihr kontrollierten Entwicklungen unter einer von der Open Source Initiative anerkannten Lizenz (Artikel 3). Geführt werden die einzelnen Projekte von Project Steering Committees, die der Vorstand einsetzt und die je ein oder mehrere Projekte verantworten (Artikel 19 und 20).
Beiträge laufen über eine Contributor License Agreement (CLA): Wer Code, Ideen oder Dokumentation beisteuert, räumt dem Verein die Rechte ein, die nötig sind, um den Beitrag als Teil des Projekts weiterzugeben; Schreibrechte (commit rights) setzen ein unterschriebenes CLA voraus. Technisch sind die Module Odoo-Addons aus Python-Dateien. Sie erweitern den Standardcode und zählen damit als eigene Module im Sinn der Odoo-Dokumentation. Auf Odoo.sh und bei eigener Installation gehören sie zum normalen Bestand; auf Odoo Online laufen sie nicht, weil diese Hostingform mit eigenen Modulen und Modulen aus dem Apps Store unvereinbar ist. Die Lizenzpflichten behandelt Odoo Community: Lizenz, Rechte und Grenzen.
Diese vier Angaben prüfen Sie vor dem Einsatz
Vor dem Produktivbetrieb erheben Sie vier Angaben. Sie stehen öffentlich und brauchen kein Konto. Die Tabelle nennt sie und zeigt, wo sie stehen.
| Prüfpunkt | Wo Sie nachsehen | Was der Befund bedeutet |
|---|---|---|
| Versionsabdeckung | Versionszweige (Branches) des Repositories auf GitHub, Versionsfilter im OCA Apps Store, Zweigliste in conf/repo/ des Repositories OCA/repo-maintainer-conf |
Fehlt der Zweig Ihrer Odoo-Version, stellt die OCA für diese Version keinen Modulquellcode bereit; für ein Upgrade verlangt die Odoo-Dokumentation Modulquellcode, der zur Zielversion passt. Die Datei nennt zusätzlich den Standardzweig des Repositories. |
| Maintainer | Schlüssel maintainers im __manifest__.py, die Avatare im Modul-README, PSC-Team in conf/psc/ |
Der Schlüssel enthält GitHub-Logins; die Rollenrichtlinie erwartet eine kurze Liste (in der Regel ein bis zwei). Ohne benannten Maintainer führt das PSC das Modul. |
| Letzte Version | Schlüssel version im __manifest__.py und die letzten Commits im Zweig |
Der Wert beginnt mit der Odoo-Hauptversion und setzt sich mit der Modulversion x.y.z fort (Beispiel: 17.0.1.0.4); die Maintainer erhöhen ihn beim Merge oder gleich danach. |
| Teststatus | Schlüssel development_status im Manifest, CI-Lauf auf GitHub Actions, Runboat-Instanz zum Zweig |
Vier Stufen: Alpha, Beta, Production/Stable, Mature. Fehlt der Schlüssel, gilt Beta. |
Die Richtlinie des Vereins (Fassung vom 24. August 2018) verlangt für Stable einen grünen CI-Lauf mit allen Pflichtprüfungen, Tests, zwei Peer-Reviews und eine Reviewzeit von mindestens fünf Tagen; kürzer geht es nur, wenn drei oder mehr Reviewende zustimmen. Für Mature verlangt sie zusätzlich Tests mit guter Code-Abdeckung, mindestens zwei unabhängige Beitragende und mindestens einen benannten Maintainer. Die Beitragsseite der OCA nennt für das Mergen abweichende, aktuelle Zahlen: drei zustimmende Reviews innerhalb von fünf Tagen oder zwei danach, mindestens eines von einem PSC-Mitglied. Module aller Stufen liegen in denselben Zweigen, und der Reifegrad kann sich je Version unterscheiden; lesen Sie den Schlüssel in dem Zweig, den Sie einsetzen.
Ein Beispiel mit Zahlen
Der Versionsfilter im OCA Apps Store weist am 14. Oktober 2026 aus, für wie viele Module des Katalogs ein Zweig der jeweiligen Version geführt wird. Der Katalog listet 7.209 Module; jeder Eintrag trägt die Versionsabzeichen aller Zweige, die für das Modul geführt werden, ein Modul erscheint also unter mehreren Versionen.
| Odoo-Version | Module mit Zweig | Anteil am Katalog |
|---|---|---|
| 20.0 | 58 | rund 0,8 Prozent |
| 19.0 | 1.484 | rund 21 Prozent |
| 18.0 | 3.071 | rund 43 Prozent |
Beispielrechnung: Der Anteil ist die Zahl der Module mit einem Zweig dieser Version geteilt durch die 7.209 katalogisierten Module. Odoo 20.0 wurde im September 2026 veröffentlicht. Wer auf die neueste Hauptversion wechselt, findet dort für einen kleinen Teil des Katalogs einen Zweig; für 19.0 ist die Auswahl größer. Die Zahlen sind ein Katalogstand und kein Qualitätsurteil: Sie zeigen, wo die Umstellung der Module noch läuft, und damit, wo ein Upgrade stocken kann.
Was Odoo zusagt – und was nicht
Ein OCA-Modul in Ihrer Datenbank ist ein Extra Module im Sinn des Odoo-Enterprise-Abonnementvertrags (Fassung Version 13 vom 24. September 2026): Quellcode, der das Standardverhalten ändert und auch von Dritten stammen kann. Als Covered Extra Module abgedeckt ist es nach demselben Vertrag nur, wenn es auf Odoo Online läuft oder Sie dafür eine Wartungsgebühr zahlen. Der Dienst für Sicherheitshinweise schließt Extra Modules ausdrücklich aus (Ziffer 4.2); der Upgrade-Dienst wandelt nur Covered Extra Modules um, alle übrigen eigenen Module müssen Sie selbst für die Zielversion anpassen (Ziffer 4.3). Arbeiten Sie mit einem Odoo-Partner, untervergibt Odoo S.A. die Leistungen für Covered Extra Modules an ihn; arbeiten Sie direkt mit Odoo S.A., gibt es diese Leistungen nur auf der Odoo-Cloud-Plattform (Ziffer 4.6).
Der Standard-Support einer Odoo-Hauptversion dauert drei Jahre ab ihrer Veröffentlichung; danach beginnt der kostenpflichtige Extended Support, den es auf Odoo.sh für eine begrenzte Zahl von Versionen und bei eigener Installation für jede Version gibt, nicht auf Odoo Online. Den Supportzeitraum der Hauptversion prüfen Sie getrennt vom OCA-Zweig. Eine Datenbank mit eigenen Modulen lässt sich außerdem nicht auf eine neue Version heben, solange deren Quellcode nicht für die Zielversion vorliegt; bei einem OCA-Modul steht dieser Quellcode im Zweig der Zielversion bereit, fehlt er, bleibt die eigene Anpassung.
Typische Fehler
- Nur die Lizenz prüfen. Fehlt der Zweig für Ihre Version, nützt die Lizenz nichts; prüfen Sie die Versionsabdeckung zuerst.
- Das Repository mit dem Modul verwechseln. Module aller Reifegrade liegen in denselben Zweigen; der Reifegrad steht im Manifest des einzelnen Moduls, nicht am Repository.
- Den Merge als Wartungszusage lesen. Reviews macht die Community nach eigener Angabe ehrenamtlich; ein übernommener Pull Request belegt keine künftige Pflege.
- Ohne Quellcode für die Zielversion upgraden. Eine Datenbank mit eigenen Modulen lässt sich nicht aufrüsten, bis deren Quellcode für die Zielversion vorliegt; das trifft jedes OCA-Modul in der Datenbank. Bei einem OCA-Modul ist der Zweig der Zielversion die Fundstelle, fehlt er, bleibt die eigene Anpassung des Quellcodes — die Odoo-Dokumentation beschreibt dieses Vorgehen.
- Auf das Abonnement vertrauen. Abgedeckt sind nur Covered Extra Modules, und der Dienst für Sicherheitshinweise schließt Extra Modules aus.
So gehen Sie vor
- Suchen Sie das Modul im OCA Apps Store und notieren Sie die Versionen, die dort ausgewiesen sind.
- Öffnen Sie im passenden GitHub-Zweig das
__manifest__.pyund lesen Sielicense,development_status,maintainersundversion. Für Module außerhalb der OCA gilt dieselbe Prüfung; die Kriterien stehen in Fremdmodule für Odoo. - Prüfen Sie den CI-Lauf des Zweigs und testen Sie das Modul in einer Runboat-Instanz oder in Ihrer Testdatenbank.
- Legen Sie fest, wer Fehler behebt: eine Person im Haus oder ein Partner. Bei Odoo Enterprise klären Sie, ob das Modul als Covered Extra Module zählt.
- Prüfen Sie für das nächste Upgrade, ob Modulquellcode für die Zielversion vorliegt — bei einem OCA-Modul der Zweig der Zielversion, sonst die eigene Anpassung —, und den Supportzeitraum Ihrer Version in Odoo-Versionen: Support-Dauer. Community-Datenbanken hebt Odoo Community upgraden mit OpenUpgrade an.