Coders gonna code

Plug-in Marke Eigenbau: So schaffen Sie sich ein zweites Standbein mit WordPress Plug-ins
4 Kommentare

Coders gonna code. Coder coden gerne. Und einige von ihnen verdienen viel Geld mit ihren Produkten. Die Entwickler hinter dem populären Theme „Avada“ nehmen beispielsweise circa 100 000 US-Dollar ein. Pro Woche. Aber nicht nur mit Themes lässt sich Gewinn machen. Auch Plug-ins holen immer weiter auf. In der 36. Kalenderwoche 2017 wurde der Visual Composer – ein Page-Builder für WordPress – knapp 2 000 Mal verkauft. Bei einem Preis von 38 US-Dollar ergibt das immerhin auch noch 60 000 US Dollar pro Woche.

Hand aufs Herz – Welcher Freiberufler schiebt so viel Umsatz? Keiner. Diese hohen Summen lassen sich mit bloßem Zeiteinsatz nicht erzielen. Unsere Arbeitszeit pro Tag ist nun einmal begrenzt. Zeit, endlich Produkte zu verkaufen.

Warum eigentlich?

Warum sollte man ein WordPress-Plug-in erstellen und verkaufen? Die Antwort auf diese Frage kann unterschiedlich ausfallen. Je nach persönlicher Präferenz. Für mich gibt es zwei Hauptgründe:

Grund 1: Plug-ins sind für mich eine sehr gute Einnahmequelle neben meiner klassischen Entwicklertätigkeit. Als Webdesigner befand ich mich im Jahr 2010 in einer Situation, die sicherlich jeder Freiberufler einmal durchmachen muss: Große Kunden fielen weg, parallel dazu ereignete sich die damalige Wirtschaftskrise. Das hat die Situation weiter verschärft. Neue Aufträge blieben aus oder wurden gleich storniert. Plötzlich steht man ohne Einkommen da und weiß nicht, wie man die nächste Miete begleichen soll. Da tauchen schnell Existenzängste auf. Sieben Jahre später sieht die Welt, dank meiner Plug-in-Verkäufe, deutlich besser aus. Der regelmäßige Cashflow durch passive Einnahmen (Supportaufwand mal nicht eingerechnet) ist eine feine Sache.

Erst in jüngerer Vergangenheit passierte einem Kollegen, mit dem ich seit kurzem zusammenarbeite, fast das gleiche wie mir damals. Der einzige Kunde fiel weg. Uff. Da kamen gleich wieder die Erinnerungen hoch. Es begann für ihn eine verzweifelte Suche nach Möglichkeiten der Geldbeschaffung. Aber das ist in einer solchen Situation meist schwierig. Deswegen sollte man vorsorgen. Und wenn es um das Thema Vorsorge geht, komme ich zu meinem zweiten Grund.

Grund 2: Software ist mittlerweile eine Art Anlageform geworden. Das sagt zumindest der österreichische Manager, Investor und Autor Gerald Hörhan in einem kürzlichen veröffentlichten Interview auf YouTube. Und auch in seinem aktuellen Buch erklärt er Software zu einem der größten Wirtschaftstrends für digitale Aufsteiger [1]. Die Gesamtheit seiner Onlinegeschäfte (sowie einige Investitionen in diesem Bereich) nennt er dann auch passend „Digitale Assets“. So gesehen, muss man das eigene Plug-in also als Investition in die Zukunft betrachten. Immerhin kann damit nicht nur eine gute Einkommensquelle, sondern sogar eine Art Kapitalanlage geschaffen werden. Ich persönlich sehe hier also eher den monetären Vorteil, wobei es – wie man am Ende des Artikels erfahren wird – noch weitere gute Gründe gibt, warum man ein Plug-in erstellen sollte.

Wer, ich?

Bin ich der Richtige für so ein Vorhaben? Wer öfter mit WordPress arbeitet und erfolgreich seine Brötchen damit verdient, ist in der Regel prädestiniert für eine solche Aufgabe. Es geht nämlich nicht nur mir, sondern auch vielen meiner Kunden oft wie folgt:

  • Irgendwann stößt man an die Leistungsgrenzen von bereits vorhandenen Plug-ins.
  •  Ein Plug-in wird nicht mehr weiterentwickelt.
  • Aus den rund 52 000 Plug-ins im offiziellen www.wordpress.org-Verzeichnis ist keines dabei, das zu einer bestimmten Aufgabe (genau) passt.
  • Es gibt kein Plug-in für einen bestehenden Sonderwunsch.

Die Welt ist groß, und die Wahrscheinlichkeit, dass jemand an genau dieselben Grenzen stößt wie man selbst, ist damit ebenfalls hoch. Wenn man als Entwickler eine Lösung für ein gewisses Problem hat, dann ist die Chance groß, dass jemand anderes die gleiche Lösung benötigt. Man muss sich also nicht hinsetzen und stundenlang darüber nachdenken, welches Plug-in man entwickeln soll. Die Ideen kommen fast von ganz alleine, wenn man sich längere Zeit mit WordPress beschäftigt. Das Beste dabei ist, dass Plug-ins, die so entstehen, einfach die besten sind. Denn man selbst kennt die eigenen Probleme am besten und kann somit die optimale Lösung finden.

Lohnt sich das?

Es ist wie mit jedem Geschäft: Ohne umfangreiche Tests weiß man im Voraus nicht, ob ein Plug-in bei den Kunden einschlägt oder nicht. Eine Möglichkeit wäre, vorab eine Produktwebseite aufzusetzen und über AdWords zu testen, ob die Benutzer überhaupt kaufen würden. Das schlägt beispielsweise Tim Ferriss in seinem Buch „Die 4-Stunden-Woche“ vor, um schnell zu einer Antwort zu kommen. Nicht zuletzt hängt ein Verkaufserfolg aber von weiteren Faktoren ab: dem Grad der Problemlösung, Preis und Marketing, um nur einige zu nennen.

Grundsätzlich würde ich aber sagen: Jede Idee ist es wert, dass man ihr nachgeht. Ich hatte bis dato noch kein Plug-in, das sich nicht verkauft hat. Und das, obwohl ich fast keine Anstrengungen unternommen habe, herauszufinden, ob es sich lohnt, ein Plug-in für ein Problem zu entwickeln. Natürlich schwankten die Verkaufszahlen deutlich, was letztlich auch dazu führte, dass ich einige davon nicht mehr weiterentwickle. Wenn ein Plug-in nicht dadurch entstanden ist, dass ich selbst eine Lösung für etwas benötigte, dann entstand es meist durch einen Kundenwunsch. Oft wurde ich also ohnehin für die Entwicklung entlohnt, und ich musste die jeweiligen Plug-ins nur noch für den Verkauf vorbereiten. Dieser Aufwand war für mich meist überschaubar und akzeptabel.

Zurzeit existieren weit mehr als 1,2 Milliarden Websites. Laut W3Techs werden knapp 29 % dieser Seiten mit WordPress betrieben [2]. Wir sprechen also von ungefähr 350 Millionen potenziell verkaufbarer Lizenzen, wenn man von einer Lizenz pro Domain ausgeht. Da sieht man sich schon wie Dagobert Duck im Geldspeicher baden. Das ist schon eine schier unendliche Menge und sicherlich auch der Grund, warum fast jedes Plug-in einen Käufer findet. Dazu kommt eine wichtige Feststellung: Wir Menschen unterschätzen regelmäßig die Größe der Märkte. Natürlich ist es immer besser, wenn man die härteste aller Nüsse knackt und eine größere Zielgruppe anspricht, denn das verspricht meist einen höheren Umsatz. Aber eventuell auch mehr Konkurrenz.

Was sind gefragte Themen?

Stellt man sich die Frage, warum die meisten WordPress-User überhaupt eine Website betreiben, dann stößt man unweigerlich auf die Antwort: um Geld zu verdienen. Ich persönlich frage mich immer, wie man diesen WordPress-Benutzern helfen kann, noch mehr oder einfacher Geld mit ihren Websites zu verdienen. Und dafür kann es durchaus mehrere Lösungen geben. Plug-ins für die Suchmaschinenoptimierung (SEO) sind zum Beispiel Erweiterungen, die immer gut ankommen. Denn sie helfen hoffentlich, bessere Rankings in Suchmaschinen zu erhalten. Und das wiederum hilft, Geld zu verdienen.

Mein erstes Plug-in machte nichts anderes als einen Google-Plus-Profillink in eine WordPress-Seite einzubinden. Das führte dazu, dass Google den Namen und das Profilbild des Autors auf der Suchtrefferseite einblendete (Abb. 1). Easy und cool zugleich, denn damals war ein Bild in Suchtreffern das Highlight schlechthin. Rich Snippets gab es noch nicht.

Abb.1: Google-Plus-Profillink auf der Google-Suchtrefferseite

Ein Kollege fragte mich einmal, ob sich dieses Plug-in tatsächlich verkauft hat. Ja, und es brachte circa 150 Euro pro Monat. Fast passiv und so lange, bis sich Google entschied, die Bildchen wieder zu entfernen. Das reichte mindestens schon einmal für die Telefonrechnung. Ich habe ihm empfohlen, endlich auch selbst ein Plug-in zu verkaufen.

Wie fange ich an?

Grundsätzlich kann jeder sofort loslegen, der Grundwissen in der PHP-Entwicklung mitbringt. Zur Ausführung von WordPress benötigt man einen lokal laufenden Webserver mit einer MySQL-Datenbank und PHP. Das alles zusammen nennt sich Web-Service-Stack. Diesen kann man sich selbst installieren oder auf bestehende Tools zurückgreifen. Das wohl bewährteste davon ist XAMPP, das für alle Betriebssysteme zur Verfügung steht. Darüber hinaus gibt es noch weitere Derivate, die sich aber auf bestimmte Betriebssysteme beschränken. Als Beispiele seien an dieser Stelle MAMP für macOS sowie WampServer für Windows genannt. Diese Tools bieten den Vorteil, dass sich Folgendes dynamisch einstellen lässt:

  • der Webserver (meist Apache oder nginx)
  • die PHP-Version (in der Regel von 5.2.x bis 7.1.x)
  • die MySQL-Version (oft 5.4 und 5.5 oder MariaDB > 10.x)

Warum die Umstellung von Webserver und/oder PHP-Version wichtig ist, werde ich gleich noch näher erläutern. Zuerst möchte ich jedoch noch weitere interessante Tools nennen: Local by Flywheel (Windows, Mac) ist mein Favorit. Das Programm erstellt eigene WordPress-Umgebungen in virtuellen Docker-Containern auf dem heimischen Rechner. Es wurde für die WordPress-Entwicklung geschaffen und installiert WordPress mit jeder neuen Seite gleich mit, ebenso das WordPress-Kommandozeilentool (WP-CLI). Im Übrigen ist das Programm auch für jeden interessant, der WordPress nur mal schnell ausprobieren will. Chassis ist aktuell in der Betaphase und kommt mit einer Desktop-App für macOS daher. Es ist aber auf allen Rechnern lauffähig, auf denen auch Vagrant läuft. Ziel ist es, eine externe Serverkonfiguration exakt nachzubauen, um sie lokal nutzen zu können. Darüber hinaus existieren weitere Tools und Systeme wie Laravel Homestead , ServerPress DesktopServer oder Laravel Valet für alle Mac-Minimalisten.

Wie entwickelt man ein WordPress Plug-in?

1. Die lokale Entwicklungsumgebung: Der Motor tuckert. Das heißt, die lokale Testumgebung läuft. Jetzt kann man auch schon loslegen. Wer als Entwickler allerdings noch nie mit WordPress gearbeitet hat, sollte sich mit den WordPress Coding Standards vertraut machen. Es gibt sie für HTML, CSS, PHP und JavaScript, und sie gelten in der Regel für die Entwicklung von WordPress selbst. Ich empfehle ihre Nutzung aber trotzdem, da nur so jeder Quellcode gleich aufgebaut ist und man sich dadurch schneller zurechtfindet.

Natürlich ist es aber jedem freigestellt, wie er seinen Code entwickelt. Tom McFarlin, der auf seinem Blog viel über WordPress-Entwicklung schreibt, empfiehlt beispielsweise, sich an die PSRs (PHP Standards Recommendations) zu halten. Und das kann mehrere Gründe haben. So erwähnt er in seinem Artikel, dass moderne Tools ohne PSRs für ihn nicht nutzbar seien. Andere wiederum wollen die Lücke zwischen den WordPress-Entwicklern und dem, was die restlichen PHP-Entwickler tun, nicht vergrößern. Deshalb kommen beide Standards gleichzeitig zum Einsatz. Am Ende ist das also eine Präferenzfrage.

2. Codeeditoren für die WordPress-Entwicklung: Nun ist es Zeit, mit der Entwicklung zu starten. Dazu benötigt man einen Editor. Am besten einen, der die WordPress Coding-Standards versteht und dem Entwickler per Autocomplete hilft, bekannte Funktionen, die bereits im Kern enthalten sind, zu finden und zu nutzen. Das erleichtert gerade Unerfahrenen die Arbeit. Die wohl bekannteste Anwendung ist PhpStorm des tschechischen Herstellers JetBrains. Es kommt mit einer direkten WordPress-Integration daher. Das ist wohl auch der Grund, warum viele Entwickler auf die – so kann man sie schon fast bezeichnen – eierlegende Wollmilchsau zurückgreifen. PhpStorm kann nämlich noch weit mehr als „nur“ WordPress. Für Einsteiger sind die 200 Euro, die man für die Lizenz im ersten Jahr bezahlen muss, vielleicht ein Hinderungsgrund. Das sollte aber definitiv kein Ausschlusskriterium sein.

International PHP Conference 2018

Getting Started with PHPUnit

by Sebastian Bergmann (thePHP.cc)

Squash bugs with static analysis

by Dave Liddament (Lamp Bristol)

API Summit 2018

From Bad to Good – OpenID Connect/OAuth

mit Daniel Wagner (VERBUND) und Anton Kalcik (business.software.engineering)

Deutlich günstiger gehts da mit Atom. Dieses Programm gibt es kostenlos und seit Kurzem auch mit nachrüstbaren IDE-Funktionen, die in Zusammenarbeit mit Facebook entstanden sind. Über sogenannte Packages lassen sich extra für die WordPress-Entwicklung entstandene Erweiterungen nachrüsten.

Zum Schluß möchte ich noch Sublime erwähnen. Diese App wird von Kollegen oft verwendet und geschätzt. Eine direkte WordPress-Integration gibt es hier zwar nicht, diverse im Netz kursierende Erweiterungen rüsten aber einige Funktionen nach.

Wie immer gilt: Code lässt sich mit nahezu jedem Editor schreiben, es muss nicht unbedingt einer der oben genannten sein. Tools wie PhpStorm erleichtern aber die Arbeit extrem. Coding-Standards, die sich per Tastenkombination auf jedes beliebige Script anwenden lassen, sowie das eingebaute Debugging sind Gold wert.

3. Mit der Entwicklung starten: Die Idee ist im Kopf, WordPress läuft lokal und der Codeeditor ist geöffnet. Zeit, ans Werk zu gehen. Aber wie fängt man an und wie strukturiert man ein Plug-in? Eine Möglichkeit stelle ich in meinem Buch „Ein WordPress Plug-in erstellen“ vor. Die ersten beiden Kapitel lassen sich online kostenlos lesen. Damit schafft man es schon einmal, eine Dateistruktur anzulegen, sodass sich das erste eigene Plug-in aus WordPress heraus aktivieren lässt. Richtig durchstarten kann man dann mit dem Verständnis der sogenannten Hooks. Diese können Plug-ins zu sehr mächtigen Konstrukten anwachsen lassen, ganz ohne in den WordPress-eigenen Quellcode eingreifen zu müssen. Doch damit nicht genug. Die vielen Application Programming Interfaces (APIs) von WordPress lassen sich nutzen, um schneller ans Ziel zu kommen. So gibt es zum Beispiel ein Widget-API, um eigene Widgets für Seitenleisten zu erstellen. Oder das HTTP-API, das das Abrufen von externen Inhalten vereinfacht. Somit muss das Rad nicht immer neu erfunden werden.

Wie man im Detail an die Sache herangeht, soll nicht Thema dieses Artikels sein. Wer hier mehr Input benötigt, für den ist die offizielle Seite „Introduction to Plugin Development“ (englisch) Anlaufstelle Nummer Eins. Eine Onlinesuche nach „WordPress Plug-in Boilerplate“ bringt zudem viele Codebeispiele, die zeigen, wie mögliche Grundstrukturen aussehen können.

Gibt es Standards für ein Plug-in?

Wie viele Funktionen soll mein Plug-in haben? Wie anfangs erwähnt: Coders gonna code. Entwickler entwickeln einfach gerne. Oft stundenlang, tagelang, monatelang. Dann wird alles über den Haufen geworfen und von Neuem begonnen. Aber um zu einem ersten eigenen und verkaufbaren Plug-in zu kommen, muss es, meiner Meinung nach, schnell gehen. Nicht überstürzt und nicht ohne vorher ausführlich getestet zu haben, natürlich. Den Ausdruck „Early Launch“ (schnelle Markteinführung) sollte man verinnerlichen. „Weniger ist mehr“ gilt auch hier: Lieber ein kleines Plug-in mit weniger Funktionen als ein überladenes Flaggschiff veröffentlichen, und zwar aus zwei Gründen:

Grund 1: Je mehr Code man erzeugt, desto mehr muss man testen. Weiter oben im Artikel habe ich empfohlen, lokale Web-Service-Stacks wie Local for Flywheel zu verwenden, unter anderem, um schnell zwischen PHP-Versionen hin- und herspringen zu können. Denn es ist nicht klar, welche Version bei einem Benutzer tatsächlich zum Einsatz kommt. Deswegen muss man auch mit älteren Versionen testen. Bei Supportanfragen muss man darüber hinaus in der Lage sein, die ungefähren Gegebenheiten eines Kunden nachzubauen, um einen etwaigen Fehler nachvollziehen zu können.

Grund 2: Die Kunden geben die Richtung vor. Viele Funktionen, von denen man am Anfang dachte, dass sie unbedingt nötig seien, werden oft gar nicht genutzt. Das heißt, man entwickelt sie oft ganz umsonst. Fängt man klein an und hört auf seine Kunden, entwickelt man genau das, was sie brauchen. Eine Win-win-Situation entsteht, und man erspart sich womöglich viel Arbeit.

Erst vor Kurzem schrieb mir jemand eine sehr lange E-Mail, in der ausführlich dargelegt wurde, welche Funktionen in meinem Plug-in noch fehlen würden, um es zu verbessern. Dieser Input kostete mich nichts. Aber ich bin mir sicher, dass die Ideen des Verfassers vielen weiteren Kunden weiterhelfen würden. Denn sie deckten sich teilweise mit meinen eigenen Ideen für zukünftige Erweiterungen. Wie bereits erwähnt: Man ist nie allein mit seinen Ideen.

In der Vergangenheit habe ich durchschnittlich ca. 75 Arbeitsstunden in ein Plug-in gesteckt. Dazu zähle ich die initiale Entwicklung, Einrichtung einer rudimentären Website mit FAQ-Bereich, Support und Updates. Plug-ins, die sich gut verkaufen, erweitere ich ab und an um gewisse Funktionen. Meist um solche, die von Benutzern als sogenannte Feature-Requests auf der Website eingereicht werden. Mit der Entwicklung von Zusätzen steigt die Arbeitszeit natürlich deutlich an. 250 Stunden und mehr sind keine Seltenheit. Dafür gibt es auch Plug-ins (wie das oben beschriebene Google-Plus-Plug-in), in die ich nicht mehr als 40 Stunden investiert habe (Abb. 2).

Plug-in Plug-in Initialentwicklung Support Gesamtstundenzahl Durchschnitt
Rich Snippets A 27 35
Purple Heart B 250
G+ Author C 35
Drive CDN D 195
Countdown E 90
Redirect if not logged in F 5
Amazon G 23
Search H 90
Analytics Opt out I 26
Line Break J 27
Comment Rating K 65
Social L 60
CAP M 46 72,84615385

Abb. 2: Arbeitsaufwand für ein WordPress-Plug-in

Das heißt also: Bestimmte Standards bei der Entwicklung gibt es nicht. Gut ist, was funktioniert, und am besten hört man auf seine Kunden. Das hat sich bewährt.

Welche technischen Anforderungen gibt es?

WordPress ist offiziell noch mit PHP 5.2.4 und MySQL 5.0 lauffähig. Empfohlen wird allerdings PHP 7.0, MySQL 5.6 oder MariaDB 10.0. Man tut gut daran, ältere Versionen weiterhin zu unterstützen, denn viele Benutzer können aus Abhängigkeit von alten Themes und Plug-ins oder schlicht aus Unwissenheit nicht auf neuere Versionen updaten. Seit Juli 2017 gibt es eine PHP-Meeting-Group in der WordPress-Community. Die Mitglieder haben es sich zum Ziel gemacht, ältere PHP-Versionen schrittweise nicht mehr zu unterstützen. Das ist durchaus eine schwierige Aufgabe, denn es kursieren immer noch ältere WordPress-Versionen im Netz, die zuvor aktualisiert werden müssen. Zu diesem Zweck wird demnächst eine Infoseite auf wordpress.org eingerichtet werden, die dem technisch nicht so versierten Benutzer beibringen soll, wie er PHP aktualisiert. Und falls das nicht geht, wird er Informationen erhalten, wie er dies an seinen Webhoster weitergeben kann.

Ich tendiere dazu, eher die neuesten Versionen zu unterstützen. Bezogen auf PHP wäre das die Version 7.0.x. Allerdings muss man sich dann im Klaren darüber sein, dass das kategorisch einige Kunden ausschließt. Aus Erfahrung kann ich dazu sagen: Kunden kaufen oft impulsiv, lesen die Anforderungen nicht und beschweren sich hinterher, dass das Plug-in nicht funktioniert. Ganz konkret habe ich vor nicht allzu langer Zeit mein Rich Snippets Plug-in auf Version 2.0 aktualisiert. Zur Ausführung benötigt es PHP 7.0 oder höher. Das Plug-in kann ohne die richtige Version erst gar nicht aktiviert werden. Obwohl auf der Verkaufsseite im ersten Satz (!) darauf hingewiesen wird, erhalte ich regelmäßig Zuschriften von Käufern, die sich beschweren.

Wer plant, sein Plug-in in das kostenlose WordPress-Verzeichnis auf wordpress.org hochzuladen, hat es da bald etwas leichter. In der readme.txt, die jedem Plug-in beiliegen muss, kann man ab sofort eine minimal unterstützte PHP-Version hinterlegen. Es ist nur eine Frage der Zeit, bis dieses Feature auch in den WordPress-Kern übernommen wird. Und dann können Benutzer gar keine Versionen von Plug-ins mehr installieren, wenn der Webserver nicht die richtige Voraussetzung mitbringt.

Aftersales – wie geht es nach dem Verkauf weiter?

Nun ist es fertig, das eigene Plug-in. Oder doch nicht? Coders gonna code. Aber nicht nur der Code ist wichtig, sondern auch das Layout, das Design, das UX-Design und vieles mehr. Es gibt tausend Gründe, warum sich Kunden beschweren und das Plug-in dann schlecht bewerten. Da Bewertungen am Ende deutlich zur Kaufentscheidung beitragen, sind sie ein wichtiges Marketinginstrument. Allzu schlechte Bewertungen sollte man zu vermeiden versuchen.

Benutzer lesen fast nie Code, und sie wollen das auch nicht. Schlechte Bewertungen erhält man meist nur wegen der Funktionalität oder einer schwierigen Handhabung. Wer in seinem Team keinen Designer hat, sollte sich zumindest das Grundwissen anlesen. Bücher, die ich hier empfehlen kann, sind zum Beispiel [3] und [4]. Nun kann man sich schon denken, dass die Erwartungshaltung eines Kunden gegenüber einem Plug-in hoch ist. Es sollBenutzer lesen fast nie Code, und sie wollen das auch nicht. Schlechte Bewertungen erhält man meist nur wegen der Funktionalität oder einer schwierigen Handhabung. Wer in seinem Team keinen Designer hat, sollte sich zumindest das Grundwissen anlesen. Bücher, die ich hier empfehlen kann, sind zum Beispiel [3] und [4]. Nun kann man sich schon denken, dass die Erwartungshaltung eines Kunden gegenüber einem Plug-in hoch ist. Es soll

  • sich gut präsentieren,
  • einwandfrei funktionieren,
  • genau das tun, was der Benutzer sich vorstellt,
  • möglichst erschwinglich sein und
  • immer weiter entwickelt werden.

Aber auch hier hört es nicht auf. Der Kunde erwartet, dass er Support auf höchstem Niveau erhält. Am besten zu jeder Tages- und Nachtzeit. Daran Schuld sind natürlich die Plug-ins und Themes, die sich am besten verkaufen, 60 000 US-Dollar Umsatz pro Woche generieren und für dieses Geld viele Mitarbeiter einstellen können, die den Supportaufwand von den eigentlichen Entwicklern fernhalten. Für einen Anfänger kann das schon erschlagend sein. Gerade unter dem Aspekt, dass man es nie allen recht machen kann. Wenn man an einem Wochenende zwei Tage nicht auf Supportanfragen reagiert, ist das für die meisten Kunden ein Grund, eine schlechte Bewertung abzugeben oder sofort das Geld zurückzuverlangen. Das ist alles schon passiert.

Wo kann man veröffentlichen?

Was sind die bekanntesten Stores? Nachdem ein Plug-in das Licht der Welt erblickt hat, muss es verkauft werden. Die Frage ist nur: Wo? Den mit Abstand meisten Traffic hat codecanyon, ein Ableger der Envato-Marktplätze. Dort werden unter anderem auch WordPress-Plug-ins gelistet. Darüber hinaus gibt es noch den MOJO Marketplace, WordPress Eden und weitere. Meines Erachtens kommt keiner an codecanyon heran, und zwar aus einem simplen Grund: Coders wanna code. Marketing ist ein Klotz am Bein. Bei codecanyon gibt es so viel Laufkundschaft, dass fast kein Marketing notwendig ist, um ein gutes Nebeneinkommen erzielen zu können.

Diesen Luxus erkauft man sich allerdings mit Gebühren zwischen 12,5 und 55 Prozent (Abb. 3). Will man sein Plug-in neben codecanyon zusätzlich auch auf der eigenen Website verkaufen, so muss man grundsätzlich 55 % abdrücken. Wer mehr verdienen will, dem bleibt hier nur eine Option: Plug-ins exklusiv und ausschließlich bei codecanyon anzubieten. Dann fängt man mit Gebühren von 37,5 % an und schlängelt sich nach oben, bzw. nach unten. Denn die Gebühren sind abhängig vom Umsatz. Erst ab einem Umsatz von 75 000 US-Dollar muss man nur noch 12,5 % an die Betreiber abgeben.

Abb. 3: Gebührenstaffelung beim Marketplace codecanyon

Eher negativ ist, wie Envato mit neu eingereichten Produkten umgeht. Man bekommt nämlich nur eine kurze E-Mail, die entweder signalisiert, dass das Plug-in in den Marktplatz aufgenommen wurde, oder man erhält eine Absage, die wenig aussagekräftig ist. Die Absage-E-Mails, die meist nur einen Satz enthalten, sind sogar online aufgelistet. Darin steht dann so etwas wie „Your submission doesn’t meet our quality requirements“. Natürlich kann man das Plug-in erneut einreichen, doch jegliche Verbesserungsmaßnahme, die man diesbezüglich macht, geht absolut ins Blaue hinein. Denn wie die Voraussetzungen im Detail aussehen, darüber schweigt Envato.

Wie verkauft man selbst?

Marktplatzseiten wie codecanyon können helfen, den Einstieg in das neue Plug-in-Business zu erleichtern. Man kommt schnell an die ersten zahlenden Kunden und kann sich so langsam an das Drumherum, wie den Support, gewöhnen. Das klappt aber nicht mit jedem Produkt, zum Beispiel, wenn man Software as a Service (SaaS) anbieten will und man darauf angewiesen ist, monatliche Zahlungen von Kunden zu erhalten. Letzteres ist nämlich in keinem der Envato-Marktplätze möglich. Darüber hinaus will man vielleicht auch keinen solchen Marktplatz nutzen oder das Marketing komplett selbst übernehmen. Dann sind folgende Tools hilfreich: Mit dem E-Commerce-Plug-in WooCommerce lassen sich digitale Produkte (Downloads) verkaufen.

Easy Digital Downloads ist ebenfalls ein Plug-in für WordPress, welches sich als Shopsystem auf den Vertrieb von digitalen Produkten spezialisiert hat. Der Hersteller geht da noch einen Schritt weiter als WooCommerce. So lässt sich das Plug-in wiederum um weitere Plug-ins, zum Beispiel für das Software-Licensing, erweitern. Freemius betreibt ein Webportal, das sich um die Zahlungsabwicklung, Lizenzierung und automatische Updates kümmert.

Man sieht: Jede Erweiterung bzw. jeder Marktplatz hat Vor- und Nachteile. Bei codecanyon hat man mit der Zahlungsabwicklung fast nichts am Hut. Gleiches gilt für Freemius. Mit WooCommerce und Easy Digital Downloads muss man sich bei allen möglichen Zahlungsanbietern selbst anmelden, sich um die Zahlungsvorgänge und die Rechnungsstellung kümmern. Letzteres kann ganz schön verzwickt sein. In jedem Land gibt es einige steuerliche Hürden, die man kennen muss, wenn man internationalen Handel treibt. Hier hilft im Zweifelsfall nur der Gang zum Steuerberater.

Warum nicht kostenlos anbieten?

Natürlich gibt es immer die Möglichkeit, Plug-ins komplett kostenlos weiterzugeben. Vielleicht auch in der Hoffnung, dass die Benutzer bereit sind, einen gewissen Betrag zu spenden. Ich persönlich würde aber die Finger davon lassen. Denn die Erfahrung hat gezeigt, dass fast niemand spendet und wenn, dann nur solch kleine Beträge, dass man sich kein sicheres zusätzliches Einkommen schaffen kann. Deswegen gehe ich erst gar nicht näher darauf ein.

Der eine oder andere hat aber sicher schon einmal mit dem Gedanken gespielt, zwei Plug-ins zu erstellen: ein kostenloses Basisprodukt und eine kostenpflichtige Vollversion. Das nennt sich „Freemium“. Und wie man am Namen schon erkennen kann, ist das die Basis, auf der der oben genannte Dienst Freemius basiert.

Wie man sich letztlich entscheidet, ist jedem selbst überlassen und hängt sicherlich von der eigenen Überzeugung sowie dem Businessvorhaben ab. Mit großer Wahrscheinlichkeit hat das offizielle WordPress-Plug-in-Verzeichnis noch mehr „Laufkundschaft“ als alle oben genannten Seiten zusammen. Zusätzlich schafft man sich von Anfang an eine hohe Nutzerbasis.

Das wohl bekannteste Freemium-Plug-in ist das Yoast SEO Plug-in. Es hilft, WordPress im Bereich der Suchmaschinenoptimierung zu erweitern. Das Yoast-Team nutzt die kostenlose Version als Eintrittstor für weitere Produkte. Es bietet daher nicht nur eine Premiumversion, sondern auch Dienstleistungen zum Thema SEO an, die dann für das nötige Einkommen sorgen. So ähnlich hat Pippin Williamson, Entwickler von Easy Digital Downloads, angefangen. Seine ersten Plug-ins fand man bei codecanyon. Später verkaufte er sie mehr und mehr auf der eigenen Website. Er nutzte die Plattform quasi als Sprungbrett, ähnlich wie Yoast das offizielle Plug-in-Verzeichnis nutzt. Zusammengefasst lässt sich also Folgendes sagen:

  1. Keine Plug-ins kostenlos weitergeben, wenn man die Absicht hat, Geld damit zu verdienen.
  2. Freemium nur, wenn man schnell eine hohe Nutzerbasis aufbauen kann und es schafft, die Premiumversion an möglichst viele Nutzer zu verkaufen. Vielleicht auch erst dann, wenn man neben der Premiumversion noch weitere Produkte oder Dienstleistung anbieten kann.
  3. Marktplätze nutzen, wenn man sich vorerst nicht auf das Marketing konzentrieren will und auch sonst keine außergewöhnlichen Produkte (wie SaaS) anbieten möchte.

Wie finde ich den richtigen Preis?

Das ist eine gute Frage, und am Ende wohl eine kaufmännische Entscheidung, die jeder für sich selbst treffen muss. Vor einigen Jahren konnte man bei codecanyon (wie auch bei allen anderen Plattformen des Betreibers) den Preis nicht selbst wählen. Das eigene Plug-in wurde dann auf zwischen fünf und ungefähr 50 US-Dollar bewertet. Wie diese Preise entstanden sind, habe ich nie so richtig verstanden. Grundsätzlich hatte man meist das Gefühl, dass die Betreiber die Preise möglichst niedrig halten wollten. Das ist wohl auch der Grund, weshalb die meisten Kunden nun einen Preis von bis zu 30 US-Dollar für akzeptabel halten – ähnlich wie ein Preis zwischen einem und fünf Euro in Apples App Store okay ist. Alle anderen schlagen nach oben aus und haben sicherlich ihre eigenen Gründe dafür, was auch in Ordnung ist.

Mittlerweile kann man die Preise selbst wählen. Wie in jedem Fall gilt: Den Preis sollte man mit Bedacht festlegen und möglichst nicht zu gering ansetzen. Pippin Williamson schrieb seine Gedanken zu einer Preiserhöhung in einem Blogpost nieder. Ende Dezember 2016 hat er fast alle Preise seiner Produktreihe um 50 % bis 250 % erhöht. Wie man sich denken kann, kam das bei einigen Kunden gar nicht gut an. Natürlich war es nicht seine Intention, Kunden zu verärgern. Als Hauptgrund gab er an, einfach müde geworden zu sein. Die soziale Verantwortung seinen Mitarbeitern gegenüber und der große Supportaufwand machten ihm und seinem Team zu schaffen. Summa summarum hat sich die Preisänderung für ihn mehr als gelohnt. Nicht nur gab es trotz sinkender Verkaufszahlen höhere Einnahmen, auch die Moral des Teams ist gestiegen.

Man sollte sich also bereits am Anfang die folgenden Fragen stellen:

  • Wie viel Zeit habe ich in mein Plug-in investiert?
  • Wie viel ist diese Zeit wert?
  • Mit wie viel Supportaufwand rechne ich?
  • Was sind die zusätzlichen Kosten (Paypal-Gebühren etc.) und wie bringe ich sie in die Rechnung mit ein?

Zusätzlich stellt sich die Frage, ob ein Einmalpreis rentabel ist oder ob man monatliche oder jährliche Preise einführen muss, um die Weiterentwicklung finanzieren zu können. Auch dafür hat Pippin eine Antwort auf seinem Blog parat. Anfang 2016 stellte er sein System auf die automatische Abbuchung der jährlichen Plug-in-Preise um. Und wieder war diese Umstellung für ihn mehr als rentabel. Der wohl positivste Effekt dabei ist der, dass die Einnahmen sich erhöhen, je mehr Kunden man gewinnt und über mehrere Jahre halten kann.

Mir fällt da aber noch ein weiterer positiver Punkt ein: Kunden können früher und schneller auf neueste Versionen updaten. Somit hat man weniger mit alten Plug-in-Versionen zu tun. Der Supportaufwand verringert sich, und es entsteht erneut eine Win-win-Situation für alle Beteiligten.

Worauf muss ich mich noch einstellen?

Wie oben erwähnt, ist der Support der wohl größte Kostentreiber. Allerdings kann ich sagen, dass dieser sich sehr in Grenzen hält, wenn man sich anfangs bemüht, alle Probleme möglichst schnell zu beheben. Wenn nach ein paar Wochen die gröbsten Schnitzer entfernt wurden, verkauft sich das Plug-in – im Fall, dass man es über codecanyon anbietet – fast von selbst.

Während dieser Zeit wird man viel lernen. Man muss auf die wildesten Webserverkonfigurationen und die wirrsten WordPress-Installationen mit den unterschiedlichsten Plug-in- und Theme-Konstellationen vorbereitet sein. Analytisches Denken, das Debugging durch Tools wie XDebug und eine geeignete Software, wie das zu Beginn erwähnte PhpStorm, helfen an dieser Stelle, dem Kunden schnell eine Lösung zu präsentieren und das eigene Stresslevel gering zu halten. Man darf allerdings nicht vergessen, regelmäßig bei Kunden um positives Feedback, sprich Bewertungen, zu bitten. Ich habe das nie gemacht, sehe aber im Nachhinein, dass das ein Fehler war. Denn meist beschweren sich nur die Kunden, bei denen etwas nicht funktioniert. Alle anderen verhalten sich in der Regel sehr still. Wie bereits erwähnt, kann sich das schlecht auf die Bewertungen und damit die Verkaufszahlen auswirken. Und das wäre schade, wenn man viel Zeit in die Entwicklung gesteckt hat.

Und nun?

Ein Plug-in von Grund auf zu entwickeln ist das eine. Sich mit Design, Marketing, Preisfindung und dergleichen zu beschäftigen, ist das andere. Wer bereits ein Freelancer ist, der ist gewohnt, viele Dinge allein zu machen. Deswegen, so denke ich, ist das erste eigene Plug-in zwar eine Herausforderung, aber kein unmögliches Ziel. Der Moment, in dem man den Veröffentlichungsbutton drückt, ist unbeschreiblich. Genau wie der Moment des ersten Verkaufs und Kundensupports. Vom Weg dorthin kann man nur profitieren. Man lernt Dinge, die man vorher nicht wusste, sei es technischer Natur (Eigenheiten von PHP, eines Webservers oder total irre WordPress-Konfigurationen), auf der menschlichen Ebene (vom kleinen Start-up bis zum italienischen Pornoseitenbetreiber war bei mir schon alles dabei) oder einfach mehr über sich selbst (wenn Kunden einen wild beschimpfen und man selbst nicht ausrasten darf).

Dabei muss man nicht immer etwas komplett Neues entwickeln. Es gibt viele Plug-ins, deren Grundidee man verbessert umsetzen kann. Immerhin belebt Konkurrenz das Geschäft. Nicht umsonst gibt es heute mehrere Formular-Plug-ins: Contact Form 7, WPForms, Ninja Forms, weForms, Torro Forms, Gravity Forms, Pirate Forms, Formidable und so weiter. Und jeder macht sein Geschäft. Heutzutage unterscheiden sich diese Plug-ins nicht etwa im Funktionsumfang, sondern durch andere Dinge wie das Design. Und das fängt bei der Verkaufsseite an, geht über die Handhabung des Plug-ins, den Kundensupport und darüber hinaus.

Am Ende wird man merken, dass man das Gefühl hat, dass die Welt durch WordPress immer näher zusammenrückt. Und das ist ein tolles Gefühl. In diesem Sinne: Coders gonna code. Viel Erfolg beim ersten eigenen WordPress Plug-in!


Literatur
[1] Hörhan, Gerald: „Der Stille Raub: Wie das Internet die Mittelschicht zerstört und was Gewinner der digitalen Revolution anders machen“, edition a, Kindle Edition, Pos. 1807
[2] Genutzte CMS weltweit: https://w3techs.com/, Stand: 14. Sept. 2017
[3] Korthaus, Claudia: „Das Design-Buch für Nicht-Designer“, Rheinwerk Verlag
[4] Krug, Steve: „Don’t make me think“, mitp Verlag

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -