Verkaufen, was der Laden längst kann
Ich hatte eine Erweiterung gebaut, um Plugins zu verkaufen. Sie lief. Dann habe ich sie verworfen — weil das Shop-System es mit Bordmitteln kann und Bordmittel Updates überleben.
Blackzack1031 Wörter · 5 Min. Lesezeit
- shop
- produkt
- meinung
Ich wollte über meinen Laden auch Software verkaufen: eigene Plugins, mit Versionen, Lizenzen und Downloads für Käufer. Also habe ich eine Erweiterung gebaut — eine eigene Seite mit Kachelansicht, ein eingeschobenes Menü in der Kopfzeile, alles ordentlich.
Sie lief. Und ich habe sie verworfen.
Was der Laden bereits konnte
Beim Durchsehen der Datenbank vor dem Ausrollen ist mir aufgefallen, wie viel von dem, was ich gebaut hatte, bereits vorhanden war:
Versionen pro Artikel — Datei, Nummer, Änderungsliste.
Lizenzen — werden beim Kauf automatisch angelegt.
Ein Downloadweg, der gegen eine aktive Lizenz prüft. Genau das, was ich als Kernfunktion selbst gebaut hatte.
Ein Kundenbereich, in dem man seine Lizenzen und Downloads sieht.
Zusatzartikel, die an einen Hauptartikel gekoppelt sind.
Und sogar eine Rückverfolgung: Beim Download werden Käufernummer und ein Einmalwert in die Datei eingespritzt — damit lässt sich eine weitergegebene Datei einem Käufer zuordnen.
Das war alles da. Ich hatte es nur nie benutzt, weil ich den Laden als Shop für Serverränge betrachtet hatte und nicht als Software-Vertrieb.
Auch das Menü konnte er selbst
Der zweite Teil meiner Erweiterung war ein Aufklappmenü in der Kopfzeile, das die Kategorien zeigt. Beim Nachsehen in der Vorlage: Das eingebaute Menü tut bereits genau das — es zeichnet jede oberste Kategorie mit Symbol und darunter ihre Unterkategorien.
Was ich für ein fehlendes Feature gehalten hatte, war eine fehlende Kategorie-Struktur. Zwei Kategorien anlegen, Artikel einsortieren, fertig.
Es gibt einen Unterschied zum Vorbild, das ich im Kopf hatte: Das eingebaute Menü listet Kategorien, nicht einzelne Artikel, und kennt keine Kurzbeschreibungen je Eintrag. Das ist weniger. Es ist auch weniger Arbeit, und es überlebt jedes Update.
Warum ich die eigene Lösung verworfen habe
Die Entscheidung fiel nach einer einfachen Überlegung: Was passiert beim nächsten Update?
Meine Erweiterung greift an zwei Stellen in den Kern ein und hängt an internen Strukturen. Bei jedem Update des Ladens muss ich prüfen, ob sie noch passt. Bei jedem größeren Umbau muss ich sie nachziehen. Und wenn ich einmal ein halbes Jahr nicht hinsehe, ist sie kaputt, wenn ich sie brauche.
Die Bordmittel-Variante hat null solcher Punkte. Ein Update kann sie nicht brechen, weil sie nichts ist, was ich gebaut habe.
Der Preis: Es sieht weniger gut aus als das, was ich mir vorgestellt hatte.
Das war die eigentliche Abwägung — Optik gegen Wartungsfreiheit. Ich habe mich für Wartungsfreiheit entschieden, und ich glaube, dass das bei jedem Nebenprojekt die richtige Wahl ist. Wer nicht hauptberuflich an einem System arbeitet, muss davon ausgehen, dass er es monatelang nicht anfasst.
Infobox
Was ich aus dem verworfenen Anlauf mitgenommen habe, war trotzdem nicht umsonst — zwei Dinge, falls doch je eine Erweiterung nötig wird. Erstens: Die Aktivierung steht an zwei Stellen — eine entscheidet, ob der Code überhaupt registriert wird, die andere über Menüeinträge und Einstellungen. Nur eine gepflegt heißt: Seite erreichbar, aber in keiner Navigation. Zweitens: Eine neue Kategorie kann den ganzen Laden umlegen, weil die Navigation jedes Kategorie-Symbol auf jeder Seite zeichnet. Ein Symbolname ohne hinterlegte Grafik wirft einen Fehler — und dann ist nicht eine Seite kaputt, sondern alle.
Was ich vor dem Verkauf noch prüfen musste
Ein Punkt, der nichts mit dem Laden zu tun hat und den ich fast übersehen hätte: Die Auslieferungskonfiguration einer Eigenentwicklung.
Meine Konfigurationsdatei war durchgehend auf mein eigenes Netzwerk gemünzt — Serveradressen, Anzeigetexte, sogar die Kennung eines bestimmten Containers. Wer das Plugin kauft, bekommt eine Konfiguration, die auf meine Infrastruktur zeigt.
Im Verkaufspaket liegt deshalb eine bereinigte Fassung. Der Quelltext ist unverändert — es geht nur um die Datei, die beim ersten Start herausgeschrieben wird.
Was nicht verkauft wird
Zur Vollständigkeit, weil das eine Frage der Redlichkeit ist:
- Ein Plugin, das von jemand anderem stammt und das ich nur angepasst habe.
- Ein Plugin, das aus entobfuskiertem Fremdcode entstanden ist.
- Alles, was Bestandteil eines gekauften Pakets ist.
Das ist keine juristische Beratung, sondern eine einfache Linie: Verkauft wird, was ich geschrieben habe. Bei allem anderen ist die Antwort nein, auch wenn die Arbeit an der Anpassung echt war.
Was ich vor dem ersten Verkauf geprüft habe
Software zu verkaufen ist etwas anderes, als sie zu betreiben. Ein paar Punkte, die vorher zu klären waren.
Was genau wird verkauft? Die Programmdatei, eine Nutzungserlaubnis, Aktualisierungen für einen Zeitraum? Das gehört auf die Artikelseite, nicht in die Fußnoten.
Welche Lizenz gilt? Bei einer Eigenentwicklung meine eigene. Bei allem, was fremde Bestandteile enthält, deren Bedingungen — und die können eine kommerzielle Weitergabe ausschließen.
Was passiert bei einem Fehler? Ein Käufer erwartet zu Recht, dass etwas funktioniert. Das bedeutet, dass ich für verkaufte Sachen eine andere Verbindlichkeit habe als für das, was ich verschenke.
Was ist mit Erstattungen? Bei digitalen Gütern mit sofortigem Download gelten eigene Regeln, und die sollte man kennen, bevor jemand danach fragt.
Der dritte Punkt ist der, der mir am meisten zu denken gegeben hat — und der Grund, warum ich zunächst nur wenige, gut abgehangene Sachen anbiete statt allem, was ich gebaut habe.
Die Auslieferungskonfiguration, die ich fast übersehen hätte
Ein Detail, das in keiner Anleitung steht und mich beim Prüfen kalt erwischt hat: Die Standardkonfiguration meines Plugins war vollständig auf mein eigenes Netzwerk gemünzt.
Serveradressen, Anzeigetexte mit meinem Namen, sogar die Kennung eines bestimmten Containers — alles Werte, die beim ersten Start herausgeschrieben werden.
Wer das Plugin kauft, bekommt also eine Konfiguration, die auf fremde Infrastruktur zeigt. Im besten Fall funktioniert es nicht, im schlechtesten schickt es Anfragen an meine Server.
Meine Konsequenz: Im Verkaufspaket liegt eine bereinigte Fassung, der Quelltext bleibt unverändert. Und eine Prüfung vor jedem Verkauf: Was schreibt diese Software beim ersten Start heraus, und steht darin etwas, das nur bei mir gilt?
Das gilt nicht nur für Konfigurationen. Auch Standardtexte, Beispieldaten, Verweise in der Hilfe und Adressen in Fehlermeldungen gehören dazu.
Die Regel, die daraus geworden ist
Keine Eigenbauten dort, wo das gekaufte System es selbst kann.
Nicht weil eigener Code schlechter wäre. Sondern weil jeder Eigenbau an einem fremden System eine Verpflichtung ist, die bei jedem Update fällig wird — und weil ich diese Rechnung schon einmal falsch gemacht habe, als ich ein Content-System durch eigene Masken ersetzt habe und feststellen musste, dass ich damit auch die Pflege übernommen hatte.