Pro Kirby Plugins

Kommerziell (2024)

Warum Plugins für das Kirby CMS verkaufen?

Alle meine Plugins für das Kirby CMS sind Open Source und kostenlos. Bis jetzt. Mit meinem letzten, dem Kirby Content Translator, welches DeepL-gestützte Übersetzung von Blöcken und anderen Feldern direkt im Kirby Panel ermöglicht, war ich so zufrieden, dass ich darüber nachdachte, kommerzielle Pro-Plugins zu entwickeln. Die User-Experience der Übersetzungs-Hilfe fühlte sich erstklassig an und der Nutzfaktor könnte einen Kauf rechtfertigen. Es wäre auch eine Möglichkeit, indirekt Spenden für meine Open-Source-Arbeit zu erhalten, die mich sonst nicht erreichen.

Es gibt bereits eine Reihe fantastischer Kirby-Plugins. Was gibt es zu bauen, was nicht schon gebaut wurde? Vielleicht kann ich mein Vue-Knowhow für Plugins einbringen, die sich hauptsächlich im Kirby Panel, also im Browser, abspielen und sich auf eine gute „Editor-Experience“ – als Pendant zur Developer-Experience – konzentrieren.

Kommerzielle Plugins für das Kirby CMS anzubieten – lohnt sich das überhaupt? Das werde ich in diesem Jahr herausfinden. Nicht nur der Verkauf von Plugins ist Neuland für mich. Es ist auch mein Debüt, digitale Produkte generell zu verkaufen.

Der Beginn: Kirby Copilot

Letztes Jahr schrieb ich eine Alternativ-UI zu ChatGPT. Ich hatte also bereits Erfahrung mit verschiedenen Bibliotheken, um mit Modellen wie OpenAI’s GPT zu interagieren. Daher war es für mich naheliegend, eine Brücke zwischen KIs und Kirby zu bauen. Es ist nur eine Frage der Zeit, bis jemand sich daran ausprobieren würde, dachte ich mir. Das spornte mich an, der Erste zu sein, der ein KI-Plugin zu schreiben ausprobiert. Meine Erfahrungen mit KI-Bibliotheken und dem Aufbau des Kirby-Panels bildeten eine gute Grundlage für die Umsetzung der Idee.

Der Kirby Copilot stellt in erster Linie einen Bereich im Kirby Panel zur Verfügung, in dem ein Editor in einem Textfeld einen Prompt schreiben kann. Wenn der KI-Provider vorkonfiguriert ist, wird Text auf Basis des Prompts generiert. Das ist nett, aber irgendwie auch ein Gimmick. Ohne Kontext ist eine KI kaum von Nutzen. Solange ein Redakteur nicht auf den Inhalt der Seite zugreifen kann, ist die Textvervollständigung wenig hilfreich. Daher kann der Prompt mit Kontext gefüttert werden, indem Feldnamen aus dem Blueprint der Seite in doppelten geschweiften Klammern referenziert werden: {{ title }} oder {{ date }} zum Beispiel.

Zusätzlich zum Prompt-Eingabefeld besteht die Möglichkeit, den Prompt mit Bildern (sofern das Modell GPT Vision aktiviert ist) und/oder PDF-Dateien anzureichern. Werden PDF-Dateien hinzugefügt, werden die Seiten ausgelesen und der gesamte Inhalt der Prompt angehängt. Damit die KI auch versteht, ab welcher Zeile der extrahierte Text beginnt, wird folgende Anweisung vorangestellt:

Additional context from the following PDF documents has been processed and made available to you. Include the information from these documents as applicable. [Hier folgt der Inhalt.]

Wie soll die Dokumentation aussehen?

Als Käufer eines Plugins habe ich andere Erwartungen an die Dokumentation, als wenn ich das README eines Open-Source-Projekts lese. Ich möchte meinen eigenen Erwartungen an meine Produkte gerecht werden. Deshalb legte ich Wert darauf, eine eigene Website für die Dokumentation des Copiloten zu erstellen. Genau das richtige Projekt, um Nuxt UI auszuprobieren, nachdem ich alle Dokumentationen der bisherigen Plugins mit VitePress realisiert hatte. Denn die Website sollte neben der Dokumentation auch eine Präsentation aller Features sein – individualisierte Seiten sind mit Nuxt als Meta-Framework einfach umzusetzen.

Ergänzend zur Website wollte ich das Plugin auf einer Spielwiese für Interessent*innen greifbar machen. Sodass nicht nur Videos, Screenshots und Beispielcode die Funktionalität belegen, sondern potenzielle Käufer*innen den Umfang eigenhändig testen können. Dazu baute ich einen Playground – eine Kirby-Instanz, die beim Aufruf auf das Kirby Panel weiterleitet, den User automatisch einloggt und so ohne Umwege das Plugin im Anwendungskontext des Panels präsentiert. Der User kann alle Funktionen ausprobieren und wird durch eingeschränkte Rechte nur daran gehindert, seine lokalen Änderungen zu speichern. Diesen Baukasten konnte für die folgenden Plugins wiederverwendet werden.

Das Schreiben und Gestalten von Website sowie Testumgebung dauerte gefühlt so lange, wie die Entwicklung des Plugins selbst. Es sollte eben ordentlich und hübsch werden.

Zweites Plugin: Kirby SEO Audit

Eines der bekanntesten und wohl auch weitesten verbreiteten Plugins für WordPress ist Yoast SEO. Es bietet verschiedene Werkzeuge, um Seiten für ein gutes Ranking in Suchmaschinen zu optimieren. Die Kirby-Community stellt einige großartige SEO-Plugins für das Kirby CMS zur Verfügung. Diese sind jedoch größtenteils nur für Entwickler*innen sichtbar. Die häufigste Frage, die ich bei der Migration von WordPress zu Kirby von Kund*innen vernahm, war, ob es „so etwas wie Yoast“ für Kirby gibt.

Die Kund*innen meinen damit den SEO-Report von Yoast SEO. Dieser kann einzelne Seiten nach zahlreichen SEO- und Lesbarkeitskriterien auswerten. Diese Analyse funktioniert im Browser und ist nicht auf serverseitig auszuführenden Code angewiesen. Sie kann daher prinzipiell auf das Kirby Panel portiert werden. Dies war auch möglich, da die Logik zur Auswertung von HTML-Texten glücklicherweise quelloffen auf GitHub angeboten wird. Mit einigen Anpassungen und Umwegen konnte ich die Bibliothek auch für das Kirby CMS zum Laufen bringen: Das SEO Audit Plugin war geboren.

Der Kirby Copilot ist meines Erachtens zu nischig, um eine breite Anwendung zu finden. Vielleicht braucht es noch etwas Gewöhnung und Übung, um KI sinnvoll in redaktionelle Prozesse zu integrieren. Das SEO-Audit hingegen könnte das Produkt sein, das vielen Business-Websites einen Mehrwert bietet. Derzeit ist es das meistverkaufte Plugin mit 20 Verkäufen (Stand Q1 2024).

Support und Service

Anders als bei Open-Source-Plugins sollten kommerzielle Produkte … Nun ja, funktionieren. Das bedeutet, auf Fragen von Entwickler*innen einzugehen und natürlich auftretende Bugs zu beheben. Obwohl ich eine 30-Tage-Rückgabefrist anbiete, war meine größte Sorge bei der Veröffentlichung beider Plugins, der Erwartungshaltung trotz Testumgebung nicht standhalten zu können. Ich bin froh, dass meine Sorge unbestätigt blieb.

Ganz im Gegenteil. Es entstand ein herzlicher Austausch zwischen Entwickler*innen und mir. Einige auftauchende Bugs wurden rasch behoben und Feature-Wünsche berücksichtigt. So konnten beide Plugins mit Feedback aus Anwendungssicht wachsen. Wenn bis jetzt niemand derart unzufrieden ist, sein Geld zurückbekommen zu wollen, dann können die Plugins nicht ganz dysfunktional sein.

Drittes Plugin: Kirby Live Preview

Eines der zehn am häufigsten gewünschten Features für Kirby ist eine in das Panel eingebettete Vorschau, sodass ein Editor während der Bearbeitung von Inhalten seine ungespeicherten Änderungen in einer Seitenvorschau direkt im Panel sehen kann. Diese Funktion arbeitet im Vergleich zu den meisten anderen Wünschen hauptsächlich im Panel. Gefundenes Fressen für mich. Also nahm ich die Idee auf. Nur war ich mir diesmal nicht sicher, ob mir die Implementierung gelingen würde.

In der Tat war der Weg etwas steinig. Eine Live-Vorschau balanciert auf einem schmalen Grat zwischen Nützlichkeit und Spielerei; redaktioneller Befähigung und Arbeitsblockade. Ist es mir gelungen? Ich finde schon. Probiere es gerne selbst aus.

Faires Preismodell

Ich gehe nicht davon aus, dass sich der Entwicklungsaufwand für die Plugins rechnet. Das muss er auch nicht. Die Umsetzung der Ideen war ein Erfolgserlebnis für sich. Gleichzeitig ist es eine spannende Erfahrung, digitale Produkt mit all ihren Abhängigkeiten vom Anbieter bis zur Steuer zu verkaufen.

Mir war es wichtig, dass sich der Nutzwert im Preis widerspiegelt, ohne dass die Plugins überteuert sind. Deshalb habe ich mich für ein Preismodell entschieden, das es erlaubt, das gekaufte Plugin für mehrere Projekte zu verwenden, solange der Entwickler oder die Entwicklerin Eigentümer des Projekts, also der Codebasis, bleibt. Im Sinne von einmal kaufen, für immer verwenden.

Installation mit Composer

Damit die Plugins nicht von jedem mit Composer installiert werden können, sind sie auf Packagist nicht zu finden. Für die die ersten Verkäufe war es mir zu aufwendig, die kommerziellen Plugins über ein privates Repository zur Verfügung zu stellen. Zum einen wusste ich nicht, wie das geht. Zum anderen wusste ich nicht, ob sich der Aufwand für ein paar Verkäufe lohnen würde. Diese Zeit wollte ich nicht investieren. Deshalb war die Installation nur über eine ZIP-Datei möglich. Schon nach den ersten Verkäufen wurde der Wunsch nach einer Versionsverwaltung via Composer laut. Verständlich, denn das Herunterladen und Entpacken der ZIP-Datei ist umständlich. Zumal der Aufwand bei jedem Projekt und jedem Versions-Upgrade gleich bleibt.

Ein Tipp aus der Community führte mich zu Satis, einem einfachen Generator für ein statisches Composer-Repository. Mit etwas Magie durch einen Cloudflare-Worker ist das private Repository für meine Plugins zwar zugänglich, die Build-Dateien der Plugins können jedoch nur nach Authentifizierung heruntergeladen werden. Dazu brauchte es noch eine Lizenzverwaltung, sodass für jede Bestellung eine eigene Lizenz erstellt wird, mit der sich im Repository authentifiziert werden kann.

Über den Kirby Tools Hub, eine kleine Nuxt-App, kann mensch sich mit der beim Kauf verwendeten E-Mail-Adresse und der entsprechenden Bestellnummer anmelden. Dort finden sich die Anweisungen zur Authentifizierung. Nach erfolgreicher Verknüpfung des Repositories mit dem Projekt kann mit nur einem Kommando eins oder alle meiner Plugins installiert und aktualisiert werden.

Aus dem Feature-Request sind also drei Websites entstanden:

  • das private Repository selbst (satis.kirby.tools, passwortgeschützt)
  • Proxy (Worker) zum privaten Repository (repo.kirby.tools)
  • Lizenzverwaltung (hub.kirby.tools)

Offene Fragen

Seit dem Verkauf des ersten Plugins ist mein ganzheitliches Konzept gleich geblieben. Ich bin ziemlich zufrieden, wie sich das Projekt insgesamt entwickelt hat. Jeder Entwicklungs- und Verkaufsprozess ist in Bewegung und vielleicht werde ich einige Dinge anpassen. Zum Beispiel bin ich mir nicht sicher, ob ich bei Lemon Squeezy als Zahlungsanbieter bleibe, da es eher für den amerikanischen Markt konzipiert ist und für mich als Verkäufer aus dem Ausland Nachteile hat (z.B. + 2,5 % Gebühr für Auszahlungen bei Standorten außerhalb der USA).

Ich möchte hier in loser Reihenfolge alle Punkte aufzählen, bei denen ich mir noch nicht sicher bin:

  • Käufer*innen in private Repository auf GitHub einladen, damit sie den Code einsehen können?
  • Auf Paddle umsteigen und Lemon Squeezy links liegen lassen?
Alle Arbeiten