Wir sind Plugin-Hersteller (fast) der ersten Stunde. Unser erstes Plugin für Shopware 4 (eine mobile App, um die Shop-Umsätze auf Apple- und Android-Geräten schnell abrufen zu können) haben wir Ende 2014 veröffentlicht, mittlerweile stetig und stark weiterentwickelt und bieten das immer noch an, neben ca. 50 weiteren Plugins.
Wir sind also kein ganz kleiner Anbieter, auch durchaus erfolgreich damit und zufrieden mit den Verkäufen. Shopware hat es geschafft, ein funktionierendes Ökosystem (Community Store) zu bauen, das
honorieren wir durchaus und sind dafür dankbar.
Mittlerweile ist Shopware 6 erschienen – wir gehen an dieser Stelle nicht
weiter auf die u.E. misslungene Kommunikation zur Einführung ein – und ist auch so langsam einigermaßen benutzbar, zumindest für einfachere Shops.
Daneben gibt es noch ein SaaS-Angebot, die Shopware Cloud.
Hier stellt Shopware die gesamte Infrastruktur/Hosting bereit,
ein Shop ist in wenigen Minuten eingerichtet. (Allerdings lassen sich Cloud-Shops seit Februar 2022 nicht mehr selbst eröffnen, dazu ist ein Kontakt mit Shopware notwendig, und die Preise sind auch drastisch in die Höhe gegangen. Aber das ist noch ein ganz anderes Thema.)
Und hier beginnt das Ungemach. Bisher konnten Shopware 5 und 6 über sogenannte Plugins erweitert werden, das sind PHP-Module kleineren oder auch größeren Umfangs, die dann im jeweiligen Shop geladen werden und direkt dort ablaufen. Mit Hilfe dieser Plugins können im Grunde genommen alle Bestandteile und Verhaltensweisen eines Shops auch sehr drastisch verändert werden – hier gilt dann das Prinzip: „with great power comes great responsibility“. Ein Plugin kann durch eine einzige Code-Zeile einen Shop gehörig „zerschießen“ (und das kommt auch immer mal wieder vor!).
Das ist natürlich und insbesondere in Cloud-Shops unmöglich, wo sich zig unterschiedliche Shops eine gemeinsame Code-Basis teilen.
Natürlich hat auch Shopware das erkannt und sich eine (vermeintliche) Lösung dafür ausgedacht: in einem Cloud-Shop dürfen und können keine Plugins geladen werden, sondern: Apps.
Im Frühjahr 2021 hat Shopware den Plugin-Herstellern mitgeteilt, dass Plugins (also auch die „echten“, für Shopware 5 und 6) jetzt ab sofort bitteschön „Apps“ zu heissen haben. Kein Widerspruch geduldet, alle
Beschreibungen sind anzupassen. Ob das zur Entwirrung der Begrifflichkeiten beiträgt, sei mal dahingestellt. Raider heisst jetzt Twix.
Angekündigt wurde das App-System für die Cloud etwa im Juni 2020. Es gab ein Whitepaper und natürlich viel kommunikatives Getöse, wie von Shopware bekannt und erwartet 😉
Wir haben uns das frühzeitig angeschaut und waren – gelinde gesagt – entsetzt. Und wir haben sehr schnell die Entscheidung getroffen, dass wir definitiv keine Apps entwickeln werden. (Update 2022: probeweise haben wir dann doch mal 2 Apps umgesetzt, nur um zu schauen, ob unsere unten stehenden Grundannahmen stimmen. Spoiler: ja, niemand will Cloud-Apps!).
– Rückblick –
Shopware hat in der Vergangenheit zwar durchaus Innovationen vorgestellt, unseres Erachtens aber viel zu lange an offensichtlichen Rohkrepierern festgehalten und sogar noch versucht, diese
wieder auferstehen zu lassen. „Bepado ist tot, es lebe Shopware Connect“ – mittlerweile ist auch das Vergangenheit und für mich war
sehr früh absehbar, dass das aus unterschiedlichen Gründen nicht funktionieren kann.
Möglicherweise gibt es eine Tendenz bei Shopware, sich in technische Lösungen zu verlieben und zu lange daran fest zu halten.
Also, was sind unsere Kritikpunkte konkret?
- Eine App kann nichts und darf nichts. Logisch, sonst müsste sie ja auch Code im Kontext der Cloud ausführen, und genau das soll ja verhindert werden.
- Eine App läuft maximal im Client (= Browser) als JavaScript. Dabei können möglicherweise einige Funktionen des Shopware Backends aufgerufen/verändert werden, aber im Vergleich zu den herkömmlichen Plugins ist das minimal.
- Das Backend einer App kann zwar in der Administrationsoberfläche des Cloud-Shops angezeigt werden, wird aber im Grunde von einem externen Server geladen. Die Benutzeroberfläche muss selbst aufgebaut werden, es kann nicht auf das Admin-Framework und die Steuerelemente von Shopware 6 zurückgegriffen werden. (Es gibt ein paar „Krücken“ dafür, aber wirklich sinnvoll und komfortabel ist das nicht.)
- Eine App kann (und muss) auf einem externen Server laufen. Den muss der App-Anbieter bereitstellen und warten.
- Eine App kommuniziert über sogenannte Webhooks mit dem Cloud-Shop und kann darüber hinaus auch die REST-API nutzen (die ok ist, aber die gibt es ohnehin und hat erst einmal nichts mit Apps zu tun.) Hiermit lassen sich aber keinerlei komplexe Modifikationen im Shop-Ablauf vornehmen (s.o. – das ist ja aus guten Gründen nicht gewollt.)
- Zwischenzeitlich wurde mit App Scripting noch eine neue und ziemlich krude Scripting-Möglichkeit eingeführt. Diese bietet zwar moderat mehr Möglichkeiten für Apps, aber erhöht die Komplexität, Fehleranfälligkeit und Lernkurve nochmals weiter.
Wir müssen noch dazu sagen, das 80-90% unserer Plugins komplexere Funktionen bereitstellen und keineswegs trivial sind.
Und genau das zeichnet sich ab: auch ein Jahr mehrere Jahre nach der ersten Ankündigung der Cloud-Apps gibt es im Store eher triviale Apps, verglichen mit den echten Plugins, die Shopware teilweise um sehr umfangreiche und komplexe Funktionen erweitern.
Das liegt mit Sicherheit nicht daran, dass das Interesse nicht prinzipiell gegeben wäre. Im Gegenteil: an herkömmlichen Shopware 6 Plugins gibt es keinen Mangel, nahezu jeden Tag kommen 2-3 weitere in den Store. Wo es potentiell Geld zu verdienen gibt, muss man nicht lange auf Anbieter warten.
Kommunikation und Shopware-Marketing
Die Shopware Marketing-Abteilung ist bekannt dafür, alles zu verkaufen 😉 In den buntesten Farben, schrillsten Tönen und der maximalen Aufmerksamkeit, im Grunde: sie macht ihren Job gut.
Aber: wenn Du ein schlechtes Produkt hast, nützt das beste Marketing nichts. Natürlich gab und gibt es auch hier immer wieder Versuche, das App-Angebot zu steigern, persönliche Aufrufe an die Plugin-Hersteller etwa, „Verkaufsveranstaltungen“ im Rahmen der Boost Days und einen extra eingerichteten Diskussionskanal auf Slack, der bisher eher wenig genutzt wird.
Der letzte, in unseren Augen sehr verzweifelte Versuch, ist die Auslobung von echt.viel.Geld (beworben werden 100.000 €, teilweise aber in Sachleistungen) für die „App of the Universe“ im Rahmen eines „App Contest“. Wir sind gespannt, wie kommunikativ mit möglicherweise eher mindergalaktischen Einsendungen umgegangen werden wird. So richtig hoch wurde das Ergebnis dann tatsächlich nicht gehängt. Und es gab auch noch einen Nachfolger, bei dem allerdings dann kein Geld mehr versprochen wurde, sondern generös auf die Provisionszahlungen an Shopware für App-Verkäufe verzichtet wurde. Kann man gut machen: keine App-Verkäufe – keine Verluste bei den Provisionen…
Natürlich haben wir das alles schon mal in Richtung Shopware kommuniziert, aber dort läuft die Verständigung leider immer und immer stärker nur in eine Richtung: von Shopware zum Kunden (Partner, Hersteller, …). Die Botschaft lautet: Kaufen! Mehr! Schneller! Teurer!
Feedback wird nur der Form halber aufgenommen, eine wirkliche, und möglicherweise auch kritische und intensive Auseinandersetzung erfolgt nicht. Es wird alles schöngeredet und wegdiskutiert. Technisch wirklich kompetente Ansprechpartner sind nicht greifbar, das ist auch gar nicht gewollt.
Daher an dieser Stelle noch einmal Klartext, warum wir als langjähriger Plugin-Hersteller keine Apps entwickeln werden:
- Das Grundprinzip ist falsch, eine App kann und darf nichts. Das ist prinzipbedingt (beim Konkurrenten Shopify sieht es nicht wirklich anders oder besser aus), ändert aber nichts daran.
- Triviale Erweiterungen lassen sich umsetzen – aber warum sollte man damit mehr als 0,99 € bis vielleicht 5 € / Monat / App verdienen können, falls überhaupt? Die Zielgruppe für die Cloud
sindwaren eCommerce-Einsteiger, ob die neuen Shopware-Pläne ab 600 € / Monat aufgehen werden, muss sich erst noch zeigen! Zu diesen immensen Grundgebühren kommen dann noch die App-Mieten hinzu, die Apps bieten jedoch prinzipbedingt keine echte und wertvolle Zusatzfunktionalität. - Im Umkehrschluss: komplexe Erweiterungen lassen sich nicht umsetzen. Wo ist dann das Geschäftsmodell, das die deutlich gestiegene Komplexität und das Risiko gegenfinanziert?
- Wir haben Plugins für Shopware 5 entwickelt und müssen/wollen diese auch noch bis sicherlich 2024 oder länger weiter pflegen und warten. Wir haben mit großem Lern- und Resourcen-Aufwand Plugins für Shopware 6 entwickelt und hoffen hier natürlich auf eine ähnlich erfolgreiche Zukunft. Auch hier sind Pflege, Wartung und Support mit einem erheblichen Aufwand verbunden. Und dann noch zusätzlich Apps für die Cloud entwickeln? Auf einer nochmals anderen Basis, mit erheblicher zusätzlicher Infrastruktur und Fehlermöglichkeiten? Danke, nein, da ist die Risiko-Ertrags-Balance ziemlich unausgeglichen.
- Ob und wie gut das Massengeschäft mit der Shopware Cloud tatsächlich funktionieren wird, muss Shopware erst noch beweisen (gerade nach der großen Preisumstellung im September 2022). So ganz ist ja noch nicht einmal klar, in welchem Maße Shopware 6 selbst überhaupt angenommen wird, da gibt es durchaus Kritik und Unmut. Und Massengeschäft bedeutet: viele Kunden, richtig viele, minimal mehrere tausend zahlende Nutzer. Das muss organisatorisch beim Plugin-Entwickler aufgefangen werden können und sich letztlich rechnen. Das Risiko ist hier groß.
- Der Zwang, eigene Server für die Apps zu betreiben, führt ebenfalls zu neuen Risiken: Diese Server müssen natürlich eine höchstmögliche Verfügbarkeit gewährleisten, um halbwegs ruhig schlafen zu können. Was passiert wohl, wenn der Server auch nur temporär ausfällt (Massengeschäft, s.o.!), über den 10-20 Apps mit jeweils 1000-2000 Nutzern laufen?! Die Hotline/Support benötigt dann echt gute Nerven. (Abgesehen davon ist erhöhte Komplexität in der IT selten der richtige Weg.) Shopware verkauft das übrigens markting-positiv: „Du hast die volle Kontrolle auf Deinem eigenen Server!“, ah ja, dankeschön.
- Was passiert wohl, wenn der Besitzer eines Cloud-Shops vielleicht im Schnitt 3-5 Apps laufen hat, und „irgendetwas“ funktioniert nicht? Wieviele Plugin-Hersteller werden dann völlig überflüssigerweise mit Supportanfragen überhäuft, weil er nicht genau weiss, was und warum gerade nicht geht?
- Der Plugin-Hersteller ist, da zwangsläufig personenbezogene Daten über den bereitgestellten externen Server laufen, plötzlich Auftragsdatenverarbeiter (bei den klassischen Plugins ist das nicht der Fall, da alles auf dem Server des Shopbetreibers abläuft). Das erhöht den organisatorischen Aufwand, das Risiko und stellt neue Haftungsfragen. Wir wollen das nicht. Und mancher Cloudkunde möglicherweise auch nicht.
Oder vielleicht doch Apps…?
Wir haben überlegt, für welche Einsatzzwecke eine Shopware Cloud App vielleicht doch sinnvoll sein könnte, auf viele Ideen sind wir allerdings nicht gekommen.
- Zunächst sind da natürlich Themes. Das ist unstrittig und dürfte gut funktionieren. Aber wenn ein Theme dann doch auch noch etwas mehr Funktionalität erweitern soll (was eben über klassische Plugins problemlos möglich ist), klappt das schon wieder nicht.
- Die oben schon erwähnten Trivialitäten: Schneeflocken und Hinweis-Banner gehen immer im Shop. Gibt es aber schon als App 😉
- Anbindung an Drittsysteme: hier macht das definitiv und zum ersten Mal wirklich Sinn. Eine Warenwirtschaft, ein CRM oder ERP-System wird so etwa von einem Webhook durch die App benachrichtigt, wenn sich ein neuer Kunde registriert hat oder eine neue Bestellung eingegangen ist. Die Daten werden dann direkt weiterverarbeitet, und im Shop wird ein Verarbeitungsmerkmal gesetzt. Wir sind aber leider kein Hersteller eines solchen Systems, das eine derartige Anbindung benötigen würde 😉
- Testweise haben wir einmal zwei – nicht ganz unerfolgreiche – klassische Plugins als Apps umgesetzt. Zwischenergebnis nach knapp einem Jahr: kaum Interesse. q.e.d.
…zum Schluß bleibt die Frage: warum das alles? Der Aufwand bei Shopware dürfte ja für das neue App-System auch nicht gering gewesen sein. Warum wurde hier nicht über eine saubere Virtualisierung/Containerisierung der Cloud-Shops nachgedacht und erlaubt dann die ganz normalen und bewährten Shopware 6 Plugins auch in der Cloud? Wenn ein Shop crasht, fällt eben nur dieser eine Shop aus. Dafür dürfte es jetzt natürlich zu spät sein, die Cloud ist ja bereits groß ausgerollt und produktiv.
Das Grundproblem ist verständlich, aber die dafür gefundene Lösung scheint uns schlichtweg falsch zu sein. Das lässt sich in der IT leider ziemlich oft beobachten. Schade, Shopware.