Geld verdienen mit WordPress Plugins

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 durch Themes lässt sich mords Gewinn machen. Auch Plugins holen immer weiter auf. In der Kalenderwoche 36/2017 wurde der Visual Composer – ein Page-Builder für WordPress – knapp 2000 mal verkauft. Bei einem Preis von 38 US Dollar ergibt das immerhin auch noch 60’000 US Dollar pro Woche.

Hand auf’s Herz. Welcher Freiberufler schiebt so viel Umsatz? Keiner. Denn 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 Plugin 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: Plugins 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 mal 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 man 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 Plugin Produktverkäufe, für mich deutlich besser aus. Der regelmäßige Cashflow durch passive Einnahmen (Supportaufwand mal nicht eingerechnet) ist eine feine Sache. Das machte mich ein Stück weit unabhängig und ich musste nicht mehr so viele WordPress Aufträge annehmen.

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 meinen zweiten Grund:

Grund 2: Software ist mittlerweile eine Art Anlageform geworden. Sagt zumindest der österreichische Manager, Investor und Autor Gerald Hörhan in einem kürzlichen veröffentlichten Interview auf Youtube1. Und auch in seinem aktuellen Buch erklärt er Software zu einem der größten Wirtschaftstrends für digitale Aufsteiger2. Die Gesamtheit seiner Online-Businesses (sowie einige Investitionen in diesem Bereich) nennt er dann auch passend „Digitale Assets“.

So gesehen muss man das eigene Plugin also als Investition in die Zukunft betrachten. Immerhin kann damit nicht nur eine gute Einkommensquelle, sondern sogar eine Art Kapitalanlage geschaffen werden.

Ich persönliche sehe hier also eher den geldwerten Vorteil, wobei es – wie man am Ende des Artikels erfahren wird – noch weitere gute Gründe gibt, warum man ein Plugin 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, der 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 Plugins.
  • Ein Plugin wird nicht mehr weiterentwickelt.
  • Aus den rund 52’000 Plugins im offiziellen wordpress.org-Verzeichnis ist keines dabei, welches zu einer bestimmten Aufgabe (genau) passt.
  • Es gibt kein Plugin für einen bestehenden Sonderwunsch.

Die Welt ist groß und die Wahrscheinlichkeit, dass jemand an genau die selben Grenzen stößt wie man selbst, ist damit ebenfalls hoch. Wenn man als Entwickler also 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 Plugin 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 Plugins, die so entstehen, einfach die besten sind. Denn nur 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 vorher nicht, ob ein Plugin 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 auf eine Antwort zu kommen.

Nicht zuletzt hängt ein Verkaufserfolg aber von weiteren Faktoren ab: Grad der Problemlösung, Preis und Marketing. Um nur einige Punkte zu nennen.

Grundsätzlich würde ich aber sagen:

Jede Idee ist es wert, dass man ihr nachgeht.

Ich hatte bis dato noch kein Plugin welches sich nicht verkauft hätte. Und das, obwohl ich fast keine Anstrengungen unternommen hatte herauszufinden, ob es sich lohnt ein Plugin für ein Problem zu entwickeln. Natürlich schwankten die Verkaufszahlen extrem und führten letztlich auch dazu, dass ich einige davon nicht mehr weiterentwickle. Wenn ein Plugin nicht dadurch entstanden ist, dass ich selbst eine Lösung für etwas benötigte, dann entstanden sie meist durch einen Kundenwunsch. Oft wurde ich also ohnehin für die Entwicklung entlohnt und ich musste die jeweiligen Plugins nur noch für den Verkauf vorbereiten. Dieser Aufwand war für mich meist überschaubar und akzeptabel.

Zur Zeit existieren weit mehr als 1,2 Milliarden Websites3. Laut W3Techs werden knapp 29% dieser Seiten mit WordPress betrieben4. Wir sprechen also von ungefähr 350 Millionen potentiell verkaufbaren Lizenzen wenn man eine Lizenz pro Domain zählt. 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 Plugin einen Käufer findet. Dazu kommt eine wichtige Aussage, die ein Freund immer wieder wiederholt:

Wir Menschen unterschätzen regelmäßig die Größe der Märkte.

Und es ist tatsächlich so! Aber natürlich ist es immer besser, wenn man die härtesten 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 des Geldverdienens. 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. Plugins 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 Plugin machte nichts anderes als einen Google Plus Profillink auf die WordPress-Seite einzubinden. Das führte dazu, dass Google dann den Namen und das Profilbild des Autors auf der Suchtrefferseite einblendete. Easy und cool zugleich. Denn damals war ein Bild in Suchtreffern das Highlight schlechthin. Rich Snippets gab es anno dazumal noch nicht.

Rich Snippet Suchtreffer bei Google
Abb. 1: Beispiel eines Google-Suchtreffers mit Autorenbild

Der eingangs erwähnte Kollege fragte mich einmal, ob sich dieses Plugin tatsächlich verkauft hat. Circa 150 Euro pro Monat. Fast passiv. So lange, bis sich Google entschied, die Bildchen wieder zu entfernen. Das zahlt mindestens schonmal die Telefonrechnung. Ich habe ihm empfohlen, endlich auch selbst ein Plugin zu verkaufen.

Wie fange ich an?

Achtung, nerdig: 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 XAMP5, welches 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 MAMP6 für MacOS sowie WAMP7 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)
  • sowie 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 Flywheel8 (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-Kommandozeilen-Tool (WP-CLI). Im übrigen ist das Programm auch für jeden interessant, der WordPress nur mal schnell ausprobieren will.

Chassis.io9 ist aktuell in der Beta-Phase 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 Homestead10, ServerPress DesktopServer11 oder Laravel Valet12 für alle Mac-Minimalisten.

Wie entwickelt man ein WordPress Plugin?

A) 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 Coding-Standards13 vertraut machen. Es gibt sie für HTML, CSS, PHP und JavaScript. Sie gelten in der Regel für die Entwicklung an WordPress selbst. Ich empfehle deren Nutzung aber trotzdem, da nur so jeder Quellcode gleich aufgebaut ist und man sich dadurch schneller zurecht findet.

Natürlich ist aber es jedem freigestellt, wie man seinen Code entwickelt. Tom McFarlin, der auf seinem Blog viel über WordPress-Entwicklung schreibt, empfiehlt14 beispielsweise, sich an die PSRs15 (PHP Standards Recommendations) zu halten. Und das kann mehrere Gründe haben. So erwähnte er in seinem Artikel, dass moderne Tools ohne PSRs für ihn nicht nutzbar wären. 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 Einsatz16. Am Ende also eine Präferenzfrage.

B) Code-Editoren 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 PHPStorm17 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ückgreifen18. 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.

Deutlich günstiger geht’s da mit Atom. Dieses Programm gibt’s kostenlos und seit kurzem auch mit nachrüstbaren IDE-Funktionen19, die in Zusammenarbeit mit Facebook entstanden sind. Über so genannte Packages20 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 zwar hier ebenfalls 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, oder das eingebaute Debugging sind Gold wert.

C) Mit der Entwicklung starten

Die Idee ist im Kopf, WordPress läuft lokal und der Code-Editor ist geöffnet. Zeit an’s Werk zu gehen. Aber wie fängt man an und wie strukturiert man ein Plugin? Eine Möglichkeit stelle ich in meinem Buch „Ein WordPress Plugin Erstellen“21 vor. Die ersten zwei Kapitel lassen sich online kostenlos lesen. Damit schafft man es schon einmal eine Dateistruktur anzulegen, sodass sich das erste eigene Plugin aus WordPress heraus aktivieren lässt. Richtig durchstarten kann man dann mit dem Verständnis der sogenannten Hooks. Sie können Plugins zu sehr mächtigen Konstrukten anwachsen lassen. Und zwar ganz ohne in den WordPress-eigenen Quellcode eingreifen zu müssen.

Damit noch nicht genug. Die vielen Application Programming Interfaces (APIs) von WordPress lassen sich nutzen, um schneller ans Ziel zu kommen. So gibt es zum Beispiel eine Widget-API, um eigene Widgets für Seitenleisten zu erstellen. Oder die HTTP-API, die das Abrufen von externen Inhalten extrem vereinfacht. Somit muss das Rad nicht immer neu erfunden werden.

Wie man im Detail rangeht sollte nicht Thema dieses Artikels sein. Wer hier mehr Input benötigt, für den ist die offizielle Seite „Introduction to Plugin Development“ 22 (englisch) Anlaufstelle Nummer 1. Eine Online-Suche nach „WordPress Plugin Boilerplate“ bringt zudem viele Code-Beispiele,die zeigen, wie mögliche Grundfesten aussehen können.

Gibt es Standards für ein Plugin?

Wie viele Funktionen soll mein Plugin 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. Ja, wir lieben das Coden und das ist auch gut so. Aber um zu einem ersten eigenen und verkaufbaren Plugin zu kommen bin ich der Meinung, dass es schnell gehen muss. Nicht überstürzt und nicht ohne vorher ausführlich getestet zu haben natürlich. Aber den Ausdruck „Early launch“ (schnelle Markteinführung) sollte man verinnerlichen. „Weniger ist mehr“ gilt auch hier. Lieber ein kleines Plugin mit weniger Funktionen, als ein überladenes Flaggschiff. 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 Support-Anfragen 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 Plugin 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 alleine mit seinen Ideen.

In der Vergangenheit habe ich durchschnittlich ca. 75 Arbeitsstunden in ein Plugin gehängt. Dazu zähle ich die initiale Entwicklung, Einrichtung einer rudimentären Website mit FAQ-Bereich, Support und Updates. Plugins, die sich gut verkaufen, erweitere ich ab und an um gewisse Funktionen. Meist um solche, die von Benutzern als so genannte 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 Plugins (wie das oben beschriebene Google+ Plugin) für die ich nicht mehr als 40 Stunden investiert hatte.

Graph zeigt die durchschnittliche Plugin-Entwicklungszeit
Bild 2: Durchschnittliches Entwicklungszeit meiner Plugins

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.023. Man tut gut daran ältere Versionen weiterhin zu unterstützen, denn viele Benutzer können aus Abhängigkeit von alten Themes und Plugins 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 auch aktualisiert werden müssen. Zu diesem Zweck wird demnächst eine Infoseite auf wordpress.org eingerichtet werden, die dem technisch nicht so versierten Benutzer schonend beibringen soll, wie er PHP aktualisiert. Und falls das nicht geht, wird er Informationen darüber erhalten, wie er dies an seinen Webhoster weitergeben kann.

Ich tendiere dazu, eher die neuesten Versionen zu unterstützen. Bezogen auf PHP wäre dies also die Version 7.0.x. Allerdings muss man sich dann im Klaren sein, dass das kategorisch einige Kunden ausschließt. Aus Erfahrung kann ich dazu folgendes sagen:

Kunden kaufen oft impulsiv, lesen die Anforderungen nicht und beschweren sich hinterher, warum das Plugin nicht funktioniert.

Ganz konkret habe ich vor nicht all zu langer Zeit mein Rich Snippets Plugin24 auf Version 2.0 aktualisiert. Zur Ausführung benötigt es PHP 7.0 oder höher. Das Plugin 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, weil es wohl nicht eindeutig hervorging.

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

After-Sales. Wie geht es nach dem Verkauf weiter?

Bam. Nun ist es fertig, das eigene Plugin. 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 Plugin dann schlecht bewerten. Da Bewertungen am Ende deutlich zur Kaufentscheidung beitragen, sind sie ein wichtiges Marketing-Instrument. 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:

  • „Das Design-Buch für Nicht-Designer“ von Claudia Korthaus und
  • „Don’t make me think!“ von Steve Krug

Nun kann man sich schon denken, dass die Erwartungshaltung eines Kunden gegenüber einem Plugin hoch ist. Es soll:

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

Aber auch hier hört es nicht auf. Vom Kunden wird erwartet, dass er Support auf höchstem Niveau erhält. Am besten zu jeder Tages- und Nachtzeit. Daran Schuld sind natürlich die Plugins und Themes die sich am besten verkaufen, 60’000 USD pro Woche Umsatz schieben und für dieses Geld viele Mitarbeiter abstellen können, die den Support-Aufwand von den eigentlichen Entwicklern fern halten. Für jeden Anfänger kann das schon erschlagend sein. Gerade unter dem Aspekt, dass man es nie allen recht machen kann. Sie können beispielsweise keine erschwinglichen Preise für jemanden erzielen, der in der dritten Welt sitzt. Gleiches gilt für Support: wir Deutsche sind stolz auf unsere Wochenenden. Wenn man zwei Tage nicht auf Supportanfragen reagiert, ist das für die meisten Kunden ein Grund a) eine schlechte Bewertung abzugeben oder b) sofort das Geld zurück zu verlangen. Alles schon passiert.

Wo kann man veröffentlichen?

Welches sind die bekanntesten Stores?

Nachdem ein Plugin das Licht der Welt erblickt hat, muss es verkauft werden. Die Frage ist nur wo? Den mit Abstand meisten Traffic hat CodeCanyon25, ein Ableger der zum Einstieg genannten Envato-Marktplätze. Dort werden unter anderem auch WordPress-Plugins gelistet.

Darüber hinaus gibt es noch den Mojo Marketplace26, WP Eden27 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 50%28. Will man sein Plugin neben CodeCanyon zusätzlich auch noch auf der eigenen Website verkaufen, so muss man standardmäßig 50% abdrücken. Wer mehr verdienen will, dem bleibt hier nur eine Option: Plugins 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 von Umsatz. Erst bei einem Umsatz von 75000 USD muss man nur noch 12,5% an die Betreiber abgeben.

Gebührentabelle von CodeCanyon
Abb 3: Gebührenstaffelung bei CodeCanyon29

Eher negativ ist, wie Envato mit neu eingereichten Produkten umgeht. Man bekommt nämlich nur eine kurze E-Mail die entweder signalisiert, dass das Plugin 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 30. Dort steht dann so etwas ähnliches wie „Your submission doesn’t meet our quality requirements“ (zu Deutsch etwa „Das eingereichte Produkt erfüllt nicht unsere Qualitätsvoraussetzungen“). Natürlich kann man das Plugin erneut einreichen. Jegliche Verbesserungsmaßnahme die man diesbezüglich macht geht allerdings 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 Plugin-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 eCommerce-Plugin WooCommerce31 lassen sich digitale Produkte (Downloads) verkaufen.
  • EasyDigitalDownloads32 ist ebenfalls ein Plugin für WordPress, welches sich als Shop-System auf den Vertrieb von digitalen Produkten spezialisiert hat. Der Hersteller geht da noch einen Schritt weiter als WooCommerce. So lässt sich das Plugin wiederum um weitere Plugins, zum Beispiel für das Software Licensing, erweitern.
  • Freemius33 betreibt ein Webportal, welches 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 der Zahlungsabwicklung fast nichts am Hut. Gleiches gilt für Freemius. Mit WooCommerce und EasyDigitalDownloads 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 kenn muss, wenn man internationalen Handel treibt. Hier hilft im Ernstfall nur der Gang zum Steuerberater.

Warum nicht kostenlos anbieten?

Natürlich gibt es immer noch die Möglichkeit, Plugins komplett kostenlos weiter zu geben. Vielleicht auch in der Hoffnung, dass die Benutzer bereit sind, einen gewissen Betrag freiwillig zu spenden. Ich persönlich würde aber die Finger davon lassen. Denn die Erfahrungen haben 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 Plugins zu erstellen: eine kostenloses Basisprodukt sowie eine kostenpflichtige Vollversion. Das nennt sich Freemium. Und wie man am Namen schon erkennen konnte, 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 Business-Vorhaben ab. Mit großer Wahrscheinlichkeit hat das offizielle WordPress-Plugin-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-Plugin ist das „Yoast SEO“ Plugin34. Es hilft WordPress im Bereich der Suchmaschinenoptimiemerung zu erweitern. Das Yoast-Team nutzt die kostenlose Version als Eintrittstor für weitere Produkte. Es bietet daher nicht nur ein Premium-Version, sondern auch Dienstleistungen zum Thema SEO an, die dann für das nötige Einkommen sorgen.

So ähnlich hat Pippin Williamson, Entwickler von EasyDigitalDownlaods, angefangen. Seine ersten Plugins 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 Plugin-Verzeichnis nutzt.

Zusammengefasst lässt sich also sagen:

  1. Keine Plugins kostenlos weitergeben, wenn man die Absicht hat, Geld damit zu verdienen.
  2. Freemium nur, wenn man schnell eine hoher Nutzerbasis aufbauen kann und es schafft, die Premium-Version an möglichst viele Nutzer zu verkaufen. Vielleicht auch erst dann, wenn man neben der Premium-Version 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öhnliche Produkte (wie SaaS-Services) 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 Plugin wurde dann auf zwischen fünf und ungefähr 50 US Dollar bewertet. Wie diese Preise entstanden sind habe ich nie so richtig verstanden. Das lag wohl im eigenen Ermessen des gerade verfügbaren Mitarbeiters. 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 Dollar für akzeptabel halten. Ähnlich wie ein Preis zwischen einem und fünf Euro in Apples AppStore 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 nieder35. Ende Dezember 2016 hat er durchwegs 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. Aber natürlich war es auch gar 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 sowie der viele Support-Aufwand machte ihm und seinem Team zu schaffen.

Summa summarum hat sich die Preisänderung für ihn mehr als gelohnt. Nicht nur gab es trotz fallender Käufe höhere Einnahmen. Auch die Moral des Teams ist gestiegen.

Man sollte sich also bereits am Anfang überlegen:

  • Wie viel Zeit habe ich in mein Plugin investiert?
  • Wie viel ist diese Zeit wert?
  • Mit wie viel Supportaufwand rechne ich?
  • Was sind die zusätzlichen Kostentreiber (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 hat Pippin eine Antwort auf seinem Blog parat36. Anfang 2016 stellte er sein System auf die automatische Abbuchung des jährlichen Plugin-Preises 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 Plugin-Versionen zu tun. Der Support-Aufwand verringert sich und es entsteht erneut eine Win-Win-Situation für alle beteiligten.

Auf was 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 Anfangs zusieht, dass man alle Probleme möglichst schnell behebt. Wenn nach ein paar Wochen die gröbsten Schnitzer entfernt wurden, verkauft sich das Plugin – im Falle von CodeCanyon – fast von selbst.

Während dieser Zeit wird man viel lernen. Man muss auf die wildesten Webserver-Konfigurationen und die wirrsten WordPress-Installation mit den unterschiedlichsten Plugin- 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 Stress-Level 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 Plugin 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, dass man viele Dinge alleine macht. Deswegen, so denke ich, ist das erste eigene Plugin zwar eine Herausforderung, aber kein unmögliches Ziel. Der Moment, an dem man den Veröffentlichungs-Button 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 Startup 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 Plugins, deren Grundidee man verbessert umsetzen kann. Immerhin belebt Konkurrenz das Geschäft. Nicht umsonst gibt es heute mehrere Formular-Plugins: ContactForm7, WPForms, NinjaForms, weForms, TorroForms, GravityForms, PirateForms, Formidable und so weiter. Und jeder macht sein Geschäft. Heutzutage unterscheiden sich diese Plugins nicht etwa im Funktionsumfang, sondern durch andere Dinge wie das Design. Und das fängt bei der Verkaufsseite an, geht über die Handhabung des Plugins und über den Kundensupport 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 Plugin!

  1. YouTube „Gespräch mit dem Investment Punk über Tesla, Bildung, Bücher und Investmentstrategien“ https://www.youtube.com/watch?v=Tsk48h7fOBY#t=14m10s ↩︎
  2. Buch: Der Stille Raub: Wie das Internet die Mittelschicht zerstört und was Gewinner der digitalen Revolution anders machen. Kindle eBook. Pos. 1807. ↩︎
  3. Quelle: http://www.internetlivestats.com/total-number-of-websites/; Stand: 14. Sept. 2017 ↩︎
  4. Quelle: https://w3techs.com/, Stand: 14. Sept. 2017 ↩︎
  5. XAMP: https://www.apachefriends.org/de/index.html ↩︎
  6. MAMP: https://www.mamp.info/de/ ↩︎
  7. WAMP: http://www.wampserver.com/ ↩︎
  8. Local by Flywheel: https://local.getflywheel.com/ ↩︎
  9. Chassis.io: http://beta.chassis.io/ ↩︎
  10. Laravel Homestead: https://laravel.com/docs/5.5/homestead ↩︎
  11. DesktopServer: https://serverpress.com/ ↩︎
  12. Laravel Valet: https://laravel.com/docs/5.5/valet ↩︎
  13. WordPress Coding Standards: https://codex.wordpress.org/WordPress_Coding_Standards ↩︎
  14. Quelle: https://tommcfarlin.com/using-psrs-in-wordpress-development/, Stand: 16. Sept. 2017 ↩︎
  15. http://www.php-fig.org ↩︎
  16. Kommentar von Alain Schlesser; https://tommcfarlin.com/psrs-wordpress-coding-standards/#comment-896376; Stand 16. Sept. 2017 ↩︎
  17. PHPStorm: https://www.jetbrains.com/phpstorm/ ↩︎
  18. Quelle:https://github.com/Automattic/PhpStorm-Resources, Stand 16. Sept. 2017 ↩︎
  19. Atom IDE: https://ide.atom.io/ ↩︎
  20. Atom Packages: https://atom.io/packages ↩︎
  21. https://wp-plugin-erstellen.de ↩︎
  22. https://developer.wordpress.org/plugins/intro/ ↩︎
  23. WordPress Requirements; https://wordpress.org/about/requirements/; Stand: 17. Sept. 2016 ↩︎
  24. Rich Snippets Plugin: https://rich-snippets.io ↩︎
  25. CodeCanyon: https://codecanyon.net/ ↩︎
  26. Mojo Marketplace: https://www.mojomarketplace.com/ ↩︎
  27. WP Eden: https://wpeden.com/ ↩︎
  28. Qulle: https://help.market.envato.com/hc/en-us/articles/214154443-Envato-Author-Fee-Schedule; Stand 17. Sept. 2017 ↩︎
  29. Quelle: https://help.market.envato.com/hc/en-us/articles/214154443-Envato-Author-Fee-Schedule; Stand: 17. Sept. 2017 ↩︎
  30. https://help.market.envato.com/hc/en-us/articles/202500934-Common-Rejection-Reasons-for-Envato-Market ↩︎
  31. WooCommerce Plugin: https://de.wordpress.org/plugins/woocommerce/ ↩︎
  32. EasyDigitalDownloads: https://easydigitaldownloads.com/ ↩︎
  33. Freemius: https://freemius.com/ ↩︎
  34. Yoast SEO Plugin: https://de.wordpress.org/plugins/wordpress-seo/ ↩︎
  35. https://pippinsplugins.com/reflection-on-a-price-increase/ ↩︎
  36. https://pippinsplugins.com/reflection-on-a-price-increase/ ↩︎