Devlog
Pimcore Community Edition wird zu OpenDXP
8. September 2026 · Lesezeit 4 Minuten
Pimcore hat mit Platform 2025.1 die Lizenz der Community Edition gewechselt: weg von der GPLv3, hin zur Pimcore Open Core License, kurz POCL. Das letzte Release unter GPLv3 war 2024.4.
Kostenlos ist die Community Edition seither nur noch unter Bedingungen: für den Einsatz außerhalb der Produktion, für Bildung und Non-Profit sowie für Unternehmen unter 5 Mio. € Jahresumsatz. Wer Pimcore als SaaS für andere betreibt, kommt ohne OEM-Lizenz nicht aus. Dazu kommt ein Produkt-Key: Auch die kostenlose Ausgabe wird beim Aufsetzen registriert. Und die POCL ist inkompatibel zu Abhängigkeiten unter GPL, LGPL und AGPL — wer solche Bibliotheken im Projekt hat, hat damit ein Rechtsproblem.
Der Fork
Am 12. Februar 2026 hat DACHCOM.DIGITAL aus Rheineck in der Schweiz OpenDXP veröffentlicht: einen community-getragenen Fork der letzten freien Community Edition, Pimcore 11.5.13, Commit 9246a42, weiterhin unter GPLv3. Der Name steht für „Open Data & Digital Experience Platform". OpenDXP ist unabhängig und steht nicht mit der Pimcore GmbH in Verbindung; der Trademark-Hinweis dazu steht im README des Projekts.
Wo das Projekt heute steht
Aktuell ist Version 1.4.1 vom 8. September 2026, ein Wartungs-Release: Es stopft NULL-Schreibvorgänge in NOT-NULL-Spalten und korrigiert die URL-Auflösung für Dokumente über mehrere Sites hinweg. Die Funktionslinie 1.4.0 kam am 17. August 2026, davor 1.3.3 am 30. Juni und 1.2.0 am 6. Januar 2026, die erste Linie 1.1.x im Herbst 2025. Die Basis ist PHP 8.3 bis 8.5, Symfony 7.4 und Doctrine ORM 3.
Funktional ist OpenDXP das, was die Community Edition war: Produktdaten (PIM/MDM), Assets (DAM), Headless-CMS, Data-Hub, FormBuilder, E-Commerce, Composable Commerce und Web-to-Print, verteilt auf 24 Bundle-Repositories. Packagist zählt rund 33.000 Installationen. Was in 1.4 dazugekommen ist, sind Betriebsthemen: Tag-basierte HTTP-Cache-Invalidierung, Permission Voters und indexierte Relation-Lookups, die die Zahl der Datenbank-Abfragen senken. In 1.2 flog Quill als Editor raus und TinyMCE kam rein, dazu ging symfony/templating über Bord.
Editionen kennt OpenDXP nicht. Es gibt keine zweite, bezahlte Ausgabe daneben, in die man später wechselt: Der Fork ist die Fortführung dessen, was die Pimcore Community Edition bis 11.5.13 war.
Warum mein Starter jetzt auf OpenDXP läuft
Neue CMS-Projekte setze ich aus einem eigenen Skeleton auf: Docker-Umgebung, Build-Kette, Komponenten-Katalog, Install-Commands — alles vorbereitet, damit ein Projekt am ersten Tag steht. Seit dem Lizenzwechsel ließ sich dieses Skeleton mit der Community Edition nicht mehr durchinstallieren: Sie will einen Produkt-Key, und ohne Registrierung kommt man nicht bis zum ersten Login.
Bei OpenDXP fehlt dieser Schritt schlicht. Ein composer create-project auf open-dxp/skeleton, danach vendor/bin/opendxp-install, fertig — kein Key, keine Registrierung. Deshalb steht mein Starter für neue Projekte jetzt auf OpenDXP 1.4.
Für ein Skeleton ist das kein Nebenschauplatz. Sein einziger Zweck ist, sich jederzeit frisch aufsetzen zu lassen — vom leeren Ordner bis zum ersten Login, ohne Handgriffe, die nur ich kenne. Genau diese Probe lief nicht mehr durch, und ein Setup, das man nicht mehr von vorne bauen kann, ist beim nächsten Projekt keine Grundlage, sondern eine Altlast. Das Pimcore-Skeleton bleibt daneben bestehen, für Projekte, die bewusst bei Pimcore bleiben wollen.
Was das für einen kleinen Betrieb mit Pimcore CE heißt
Der Support für Pimcore 11 ist ausgelaufen. Ab Pimcore 12 beziehungsweise 2026.1 ist Pimcore Studio Pflicht: 2025.4 war das letzte Release, das beide Oberflächen mitbrachte, danach läuft der alte ExtJS-Admin aus. Module wie Portal Engine oder Datenqualität kosten inzwischen extra. Wer heute eine Community Edition betreibt, hat also bis Ende 2026 eine Entscheidung zu treffen: mit der POCL leben und auf Studio umbauen, oder auf den Fork wechseln.
Der Umzug ist überschaubarer, als das Wort Migration klingt. Zuerst geht der Stand auf Pimcore 11.5.x, dann wird umbenannt: Namespace Pimcore zu OpenDxp, Präfix pimcore_ zu opendxp_, Konstanten PIMCORE_ zu OPENDXP_, config/pimcore zu config/opendxp. In der Datenbank betrifft es den settings_store und die serialisierten Klassennamen in documents_editables und properties; die Inhalte selbst bleiben liegen. Arbeit machen die Bundles, weil Pimcore-Bundles und OpenDXP-Bundles getrennte Forks sind. Sylphen ordnet den Gesamtaufwand typischerweise kleiner ein als einen Umstieg auf Pimcore 12. Wie das bei mir abläuft, steht auf der Seite Pimcore zu OpenDXP Migration.
Was dagegen spricht
OpenDXP ist ein junges Projekt, die erste öffentliche Version liegt gut ein halbes Jahr zurück, und getragen wird es im Wesentlichen von einem Hauptsponsor. Das Bundle-Ökosystem ist zwischen Pimcore- und OpenDXP-Versionen aufgeteilt, und die Trademark-Lage zwischen Fork und Pimcore GmbH bleibt ein Reibungspunkt. Wer eine Community Edition unter der Umsatzgrenze betreibt, wenig Eigencode hat und mit der Registrierung leben kann, hat keinen Grund zu wechseln. Ich empfehle den Fork da, wo die Lizenz konkret im Weg steht.
Quellen
- github.com/open-dxp/opendxp — README, Releases und Trademark-Hinweis
- docs.opendxp.io — Dokumentation und Umbenennungs-Hinweise Pimcore zu OpenDXP
- opendxp.io — Projektseite und News
- pimcore.com — Ankündigung des Lizenzwechsels zur POCL
- lightningjar.com — Einordnung des Forks
- sylphen.com — Support-Ende von Pimcore 11 und Aufwandsvergleich
Reden wir über dein Projekt
Kein Vertrieb. Nur ich.
mail@sparcode.dev