Seite kopieren

Architektur und Grundsätze

Zuletzt geändert am 7. Oktober 2026

Aufbau eines OSPO-Stacks

Jeder Stack besteht aus einem Shopsystem und optionalen Randsystemen, die jeweils eine Aufgabe übernehmen. Shop und Randsysteme laufen als Docker-Container, die Verbindung zwischen ihnen steckt nicht in der Container-Definition, sondern in der Konfiguration der Anwendungen: ein Plugin im Shop, ein Konnektor im PIM, ein Flow in der Automatisierung.

Stand der Evaluierung

Erprobt ist bisher nur der Stack mit WooCommerce. Alles in der Tabelle unten wurde mit einer WooCommerce-Instanz aufgebaut und getestet. Ob und wie sich die Randsysteme an Shopware 6 und Mage-OS anbinden lassen, ist noch offen. Die Evaluierung dieser beiden Shopsysteme läuft.

Randsysteme, wie sie mit WooCommerce erprobt sind:

Bereich	Gewählte Komponente	Lizenz	Anbindung an WooCommerce
Zahlung	Mollie	GPLv2 (Plugin)	Plugin im Shop, API-Schlüssel des Händlers
Newsletter	Newsletter (Stefano Lissa)	GPLv2+	läuft im Shop selbst
Produktdaten (PIM)	LibrePIM	OSL-3.0	Akeneo Connector (GPLv3), nur PIM → Shop
Web-Analyse	Matomo	GPLv3	Connect Matomo (wp-piwik)
Automatisierung	Activepieces	MIT	REST-API und Webhooks von WooCommerce, kein Plugin
Zusammenarbeit	Nextcloud	AGPLv3	nicht gekoppelt, Arbeitsumgebung fürs Team
KI	Ollama mit offenem Modell	MIT, Modell Apache-2.0	serverseitig umgeleitet, siehe KI-Produkttexte

Die Details stehen unter WooCommerce: Randsysteme anbinden.

Shopware 6 und Mage-OS: Für Matomo sind Konnektoren gefunden (tinect/matomo für Shopware 6, fnogatz/magento2-matomo für Mage-OS), aber noch nicht erprobt. Für die übrigen Randsysteme ist die Anbindung an diese beiden Shopsysteme noch nicht untersucht.

Auswahlkriterien

Eine Komponente kommt nur in den Stack, wenn sie alle vier Punkte erfüllt:

1. OSI-anerkannte Open-Source-Lizenz, möglichst verträglich mit der GPL des übrigen Stacks. „Fair Code" oder Freemium mit gesperrten Kernfunktionen zählt nicht.
2. Selbst betreibbar. Kein Pflicht-Clouddienst, keine Kontingente, ab denen es kostet.
3. Kein Abfluss von Daten an Dritte ohne Not, insbesondere nicht außerhalb der EU.
4. Tatsächlich anbindbar. Ein offener Konnektor muss existieren und funktionieren. Ein kostenpflichtiger Konnektor für ein freies System hilft nicht.

Werbung ist kein Beleg

Mehrfach hat sich ein Plugin im Code anders verhalten, als es beworben wird. Beispiele: Ein KI-Plugin nennt sich anbieterunabhängig, ist aber fest auf drei Cloud-Anbieter verdrahtet. Ein Matomo-Plugin bringt eine eigene Matomo-Kopie mit, statt die vorhandene Instanz anzusprechen. Vor einer Entscheidung lohnt der Blick in den Quelltext.

Geprüft und verworfen

Kandidat	Wofür	Warum verworfen
n8n	Automatisierung	Sustainable Use License, keine OSI-Lizenz, Betrieb als bezahlter Dienst untersagt
Node-RED	Automatisierung	lizenzrechtlich sauber, aber eher Flow-Programmierung für IoT als App-Automatisierung
Odoo, Pimcore	ERP, PIM	WooCommerce-Konnektoren nur kostenpflichtig
Tinify	Bildoptimierung	Clouddienst mit Freikontingent, danach kostenpflichtig
Akismet	Spamschutz	schickt Formulardaten an Server in den USA
Google reCAPTCHA	Spamschutz	ersetzt durch EU-Captcha (Hosting in Deutschland)
WPForms, Ninja Forms, Forminator	Formulare	Freemium, Kernfunktionen gesperrt
„Matomo Analytics" (matomo)	Analyse	bettet eine eigene Matomo-Kopie ein, statt eine zentrale Instanz anzubinden
PayOne	Zahlung	technisch geeignet, MIT-Lizenz; Mollie (GPLv2) passt besser zum GPL-Stack

ERP und PIM

Für ERP- und PIM-Anbindungen an WooCommerce bleibt mit strengen Open-Source-Vorgaben oft nur die eigene Entwicklung über die REST-API. Odoo und Pimcore bieten ihre WooCommerce-Konnektoren nur kostenpflichtig an. LibrePIM ist die Ausnahme, weil der Akeneo Connector frei ist. Wie es bei Shopware 6 und Mage-OS aussieht, ist noch nicht untersucht.

Gemeinsame Muster

Diese Erkenntnisse stammen aus dem Betrieb der WooCommerce-Instanz.

Reverse Proxy mit TLS. Shop und Randsysteme laufen hinter einem Reverse Proxy (bei uns Traefik), der TLS terminiert. Die Anwendungen müssen dem Proxy vertrauen, sonst erzeugen sie http://-Adressen statt https://. Das betrifft Nextcloud (OVERWRITEPROTOCOL), Symfony-Anwendungen wie LibrePIM (TRUSTED_PROXY_IPS) und Matomo.

Basic-Auth auf Testinstanzen. Sandboxen liegen hinter HTTP-Basic-Auth. Alles, was Server miteinander oder Besucher mit einem Tracker sprechen, braucht dann eine Ausnahme mit eigener Authentifizierung: die REST-API des Shops (/wp-json), die API von LibrePIM (/api), der Matomo-Tracker. Anwendungen mit viel Hintergrundverkehr wie Activepieces gehören gar nicht hinter Basic-Auth, sie bleiben sonst in einer Anmeldeschleife hängen.

Projekteigene Anpassungen als Must-Use-Plugin. In WordPress liegen alle eigenen Anpassungen unter wp-content/mu-plugins/, nie im Code eines fremden Plugins. So überstehen sie jedes Update.