Wir bauen mit am Shopware-Core - und warum Ihr Shop davon profitiert

Sie suchen eine Agentur für Ihren Shopware-Shop und holen drei Angebote ein. Alle drei nennen sich "Shopware-Experten", alle drei haben ein paar Referenzlogos auf der Website, alle drei klingen am Telefon kompetent. Wer von ihnen das System bis ins Innerste versteht, lässt sich nach dem ersten Gespräch trotzdem nicht sagen. Weiter hilft ein Kriterium, das selten in Verkaufsgesprächen auftaucht und viel über die technische Tiefe eines Partners verrät: Arbeitet er aktiv am offenen Shopware-Core mit?

In diesem Artikel erklären wir, was "Core Contributor" konkret bedeutet, warum Open-Source-Beiträge mehr sind als ein Imagethema und woran Sie als Entscheider erkennen, ob hinter dem Wort "Experte" echte Substanz steckt. Ja, wir gehören selbst zu den Agenturen, die zum Core beitragen. Trotzdem soll dieser Text Ihnen vor allem ein Werkzeug an die Hand geben, mit dem Sie jeden Dienstleister besser einschätzen können.

Was "am Core mitarbeiten" wirklich heißt

Shopware 6 ist Open Source. Der komplette Quellcode der Community Edition liegt öffentlich auf GitHub unter shopware/shopware. Jeder kann ihn lesen, herunterladen und Verbesserungen vorschlagen. Diese Vorschläge laufen über sogenannte Pull Requests: Ein Entwickler ändert eine Stelle im Code, beschreibt das Problem und die Lösung, und das Shopware-Team prüft den Vorschlag, diskutiert ihn und übernimmt ihn oder lehnt ihn mit Begründung ab.

"Core Contributor" zu sein bedeutet also nicht, ein offizielles Zertifikat an die Wand zu hängen. Es bedeutet, dass nachweisbar Code von einem in das Produkt eingeflossen ist, das Tausende Shops weltweit nutzen. Das umfasst in der Praxis mehrere Dinge:

• Bugfixes: Ein Fehler im Standard wird an der Wurzel behoben statt im eigenen Projekt umschifft, und zwar für alle Shops.

• Issues melden: Reproduzierbare Fehlerberichte mit klarer Beschreibung, damit das Kernteam schneller reagieren kann.

• Verbesserungen & Erweiterungen: Vorschläge, die Randfälle abfangen, Antwortzeiten senken oder die Bedienung per Tastatur und Screenreader verbessern.

• Wissensaustausch: Antworten in Community-Foren, Beiträge auf Events wie dem Shopware Community Day, offene Tutorials und Code-Beispiele.

All das ist öffentlich nachprüfbar. Ein Pull Request hat einen Autor, ein Datum und einen Status. Wer am Core mitarbeitet, kann das mit einem Link belegen. Wer es nur behauptet, kann das nicht.

Warum das für Ihr Projekt einen Unterschied macht

Open-Source-Engagement klingt erst einmal nach einem Thema für Entwickler, nicht für Geschäftsführer. Ob Ihre Agentur den Core nur benutzt oder ihn mitgestaltet, wirkt sich aber direkt auf Budget, Zeitplan und Risiko Ihres Shops aus.

1. Tieferes Verständnis statt Halbwissen

Wer einen Fehler im Shopware-Core findet, analysiert und im Core behebt, muss verstehen, wie das System unter der Oberfläche funktioniert, und nicht nur, wie man im Admin ein Plugin anklickt. Dieses Wissen schlägt sich in Ihrem Projekt nieder: bei der Architektur, bei Performance-Entscheidungen und vor allem dann, wenn etwas nicht nach Lehrbuch läuft. Probleme, die andere mit einem Workaround zukleistern, werden an der richtigen Stelle gelöst.

2. Weniger Workaround-Pfusch, bessere Update-Fähigkeit

Ein häufiges Muster in schlecht gepflegten Shops: Statt einen Fehler im Standard zu beheben, wird der Core direkt überschrieben oder mit fragilen Hacks umgangen. Solche Eingriffe brechen beim nächsten Update, und jedes Shopware-Upgrade wird zum teuren, riskanten Großprojekt. Wer gewohnt ist, über die vorgesehenen Erweiterungspunkte zu arbeiten und Fehler dort zu melden oder zu fixen, wo sie hingehören, hinterlässt einen Shop, der updatebar bleibt. Das spart Ihnen genau die Wartungskosten, die sonst mit jedem Jahr wachsen.

3. Direkter Draht und schnellere Lösungen

Wer regelmäßig zum Core beiträgt, kennt die Diskussionen im Repository, weiß, welche Änderungen in den nächsten Versionen kommen, und steht im Austausch mit anderen Entwicklern und teils dem Kernteam. Wenn in Ihrem Shop ein seltener Fehler auftritt, ist der Unterschied spürbar: Statt tagelang im Dunkeln zu raten, lässt sich oft schnell einordnen, ob es sich um einen bekannten Core-Bug, ein Plugin-Problem oder einen Eigenfehler handelt.

4. Frühe Signale aus dem Repository

Open-Source-Projekte entwickeln sich im Offenen. Wer mitliest und mitarbeitet, sieht früh, wohin sich Shopware bewegt: Headless-Architektur, neue APIs, die schrittweise Integration von KI-Funktionen. Das fließt in Empfehlungen ein, bevor die Änderung in den Release Notes auftaucht. Für Sie heißt das: weniger Investitionen in Sackgassen, mehr Entscheidungen, die in zwei Jahren noch tragen.

Open Source ist Geben und Nehmen

Jeder, der Shopware einsetzt, profitiert von der Arbeit unzähliger Entwickler, die das System über Jahre verbessert haben. Diese Grundlage ist kostenlos nutzbar, aber sie ist nicht von selbst entstanden. Sie lebt davon, dass ein Teil der Nutzer auch zurückgibt. Das halten wir für die richtige Haltung: Wer jeden Tag mit einem offenen System Geld verdient, sollte etwas davon an die Gemeinschaft zurückfließen lassen.

Konkret kann das viele Formen annehmen, und keine davon ist exklusiv. Andere Agenturen, Freelancer und Inhouse-Teams tragen ebenfalls bei, und das ist gut so. Typische Beiträge sehen so aus:

• Ein Bug, der im eigenen Kundenprojekt auffällt, wird mit Reproduktionsschritten beschrieben und als Fix zurück in den Core gegeben, statt ihn nur lokal zu umschiffen.

• Erfahrungen aus echten Projekten werden in Foren, auf Community-Events und in offenen Beiträgen geteilt, damit andere nicht dieselben Fehler machen.

• Lücken in der Dokumentation werden geschlossen, oft das undankbarste, aber für Einsteiger wertvollste Stück Arbeit.

Der angenehme Nebeneffekt für Sie als Kunde: Eine Agentur, die regelmäßig zurückgibt, hat ein echtes Interesse daran, dass Shopware als Plattform gepflegt bleibt. Das ist eine andere Grundhaltung als die eines reinen Wiederverkäufers, der das System nur als Mittel zum schnellen Umsatz sieht.

Woran Sie eine Agentur mit echtem Core-Bezug erkennen

Sie müssen kein Entwickler sein, um die technische Tiefe eines Partners einzuschätzen. Diese Fragen lassen sich in jedem Erstgespräch stellen, und die Antworten sind aufschlussreich:

1. "Können Sie mir öffentliche Beiträge zum Shopware-Core zeigen?" Eine ehrliche Antwort enthält Links zu Pull Requests oder Issues. Vages "Wir sind sehr aktiv in der Community" ohne Beleg ist ein Warnsignal.

2. "Wie gehen Sie mit Fehlern im Standard um?" Gute Antwort: melden, im Core fixen, updatefähig bleiben. Schlechte Antwort: "Das überschreiben wir einfach."

3. "Wie stellen Sie sicher, dass mein Shop updatebar bleibt?" Wer hier konkret über Erweiterungspunkte, Plugin-Grenzen und Tests spricht, denkt langfristig.

4. "Was geben Sie an die Community zurück?" Die Antwort zeigt, ob es eine Haltung gibt oder nur ein Verkaufsversprechen.

Wichtig ist die Verhältnismäßigkeit: Ein einzelner Pull Request macht niemanden zum besseren Partner, und nicht jedes gute Team trägt aktiv zum Core bei. Aber ein nachweisbares, regelmäßiges Engagement ist ein starkes Signal dafür, dass die Menschen dahinter das System wirklich verstehen und es nicht nur als Black Box bedienen.

Unser Anspruch

Wir bei CODING9 entwickeln auf Shopware und arbeiten am offenen Core mit: Bugfixes, Fehlerberichte und Wissen, das wir in die Community zurückgeben. Das ist für uns die ehrlichste Form, ein System zu beherrschen, von dem wir und unsere Kunden täglich leben. Jeder Beitrag zwingt uns, das Fundament genauer zu verstehen, und dieses Verständnis fließt in jedes Projekt ein, das wir umsetzen.

Und weil wir genau das von jedem Partner einfordern würden, machen wir es vor. Hier sind einige unserer Beiträge zum öffentlichen Repository shopware/shopware, nachprüfbar auf GitHub:

• Core: Leere sw-* ID-Header werden korrekt als "nicht gesetzt" behandelt, statt zu fehlerhaftem Verhalten zu führen (PR #16839, gemerged).

• Storefront-Performance: Korrekte XXL-Breakpoint-Werte im sizes-Attribut von Thumbnails, damit Browser die passend großen Bilder laden (PR #16825, gemerged).

• Bild-Ladeverhalten: Entfernen von nativem Lazy-Loading bei Galerie-Thumbnails, das die wahrgenommene Ladezeit verschlechtern konnte (PR #16870, in Review).

• Administration: Leere Varianten-Suchbegriffe werden ignoriert, statt unnötige Anfragen auszulösen (PR #16840, in Review).

Mehrere dieser Beiträge drehen sich um Ladezeit und um das Standardverhalten in Randfällen, also um die Themen, die im Tagesgeschäft eines Shops über Conversion und Wartbarkeit entscheiden. Was wir im Core verbessern, wirkt in jedem Shopware-Shop, nicht nur bei unseren eigenen Kunden.

Für Sie als Entscheider zählt vor allem eines: Machen Sie das Open-Source-Engagement Ihres Dienstleisters zu einem festen Kriterium in der Auswahl, egal für wen Sie sich am Ende entscheiden. Es kostet Sie nichts, danach zu fragen, und es trennt diejenigen, die ein System beherrschen, von denen, die es nur bedienen.

Was daraus für Ihre Auswahl folgt

"Shopware-Experte" ist ein Begriff, den sich jeder selbst verleihen kann. Mitarbeit am offenen Core ist dagegen öffentlich nachprüfbar und zeigt, ob jemand das System bis zur Wurzel versteht. Für Ihr Projekt heißt das: Erweiterungen über die vorgesehenen Punkte statt Core-Overrides, ein Shop, der das nächste Upgrade übersteht, und im Ernstfall eine schnellere Einordnung, ob der Fehler im Core, im Plugin oder im eigenen Code sitzt. Nachweisbar ist das mit Links auf Pull Requests, und die kann jede Agentur liefern, die tatsächlich am Core arbeitet.