Beim WordCamp Verona 2023 habe ich einen Vortrag darüber gehalten, was ich in den letzten 12 Jahren als Open Source Entwickler gelernt habe. Für die Präsentation ging ich nur auf die wichtigsten Punkte ein. Ich hatte nur 10 Minuten Zeit zur Verfügung. Zudem hatte ich mich für Englisch als Sprache entschieden. Deshalb wollte ich auch nicht zu sehr in technische Details abdriften und eher über die ganz allgemeinen Lektionen sprechen.
Alles beginnt mit einer Entscheidung
WordPress kann viele Sprachen. Allerdings gehören einige spezielle Funktionalitäten, welche man für mehrsprachige Websites braucht, eben – wie schon in 2011, wo diese Geschichte beginnt – noch immer nicht zur Standardausrüstung unseres bevorzugten CMS.
Es gab auch damals schon einige Plugins, die diese Lücke füllen wollten. WPML hatte damals die Nase vorn und war zudem (noch) frei erhältlich. Als sich das praktisch über Nacht änderte und WordPress 3.0 mit dem Multisite-Feature bereits in Sicht war, traf ich eine Entscheidung:
Ich werde eine Open Source Plugin erstellen, welches Mehrsprachigkeit durch die Nutzung von Multisites kostenlos zur Verfügung stellt.
Open Source, Premium, Freie Software, …
Meines Empfindens nach weditaren zum damaligen Zeitpunkt noch nicht so viele [so genannte] „Premium“-Plugins auf dem Markt. Es gab jedoch schon einige Debatten zum Thema. Die Annahme, dass Plugins und Themes gegen Bezahlung womöglich nicht zum WordPress Konzept des „democratising publishing“ passen, war faktisch für viele Nutzer – zumindest innerhalb meiner Blase – ein allgemein akzeptiertes Argument gegen solche Lösungen.
Heute gibt es keine so klare Grenze mehr. Ich bin durch die Entwicklung der letzten Jahre auch etwas entspannter bei diesem Thema. Anbieter von Bezahl-Plugins/Themes sind inzwischen ein wichtiger Teil der Community. Manchmal treten sie sogar als treibende Kraft von Initiativen auf, welche WordPress als CMS besser machen wollen oder sie helfen aktiv in der WordPress-Community mit.
Wo ich den Strich heute ziehe
Insofern gibt es eigentlich nur sehr wenige Sachen, die mich bei „Premium“-Plugins stören. In der Tat sind Dinge, wo ich persönlich die Grenze ziehe, auch bei kostenlosen Community Plugins zu beobachten. Ich vermeide den Begriff „Freie Plugins“ im Sinne von freier Software deshalb absichtlich.
Man kann nicht häufig genug über den „Lock-in Effekt“ sprechen. Wer seine aktiven Plugins mal eben abschalten kann, ohne das die Website irgendwo kaputt geht, ist auf der Gewinnerseite. Jeder sollte das tatsächlich einmal probiert haben. Einfach, um besser informiert zu sein.
Ein weiterer Punkt, der dringend angesprochen werden muss, sind permanent (nicht ausblendbare) Boxen mit Werbung im WordPress Admin Dashboard. Das ist so, als wenn man jemanden zu Besuch einlädt und der Gast bei seiner Ankunft in der Wohnung erst einmal seine Werbeplakate verklebt.
Ja, aber wovon lebt ein Open Source Entwickler?
Außenstehende gehen vielleicht davon aus, dass Programmierer im Besitz einer Gelddruckmaschine sind, die sie aus unerfindlichen Gründen nicht benutzen wollen. Noch fragwürdiger sind demnach Open Source Entwickler, welche Anwendungen „verschenken“, die offensichtlich von anderen gebraucht werden. Insofern wird das [oben bereits angeprangerte] penetrante Bewerben von Produkten möglicherweise als notwendiges Übel angesehen.
Zur Ehrenrettung aller Softwareentwickler weise ich darauf hin, dass das Betreiben von Unternehmen und der Verkauf von Software nicht trivial sind. Trotzdem kann das Veröffentlichen von Open Source durchaus lohnenswert sein. Oft genug ist die Motivation einfach nur der Spaß an der Sache oder gelenkt durch die Suche nach Anerkennung in der Community. Manchmal fließt auch Geld – selten direkt, öfter indirekt.
Sponsoring kann viele Gesichter haben
Sowohl das WordPress Plugin Directory als auch Plattformen für das Hosting von Open Source Projekten bieten zumindest einen Link zu Informationen für potenzielle Sponsoren an. Github Sponsors geht noch einen Schritt weiter und will Entwickler wann immer möglich von der zeitraubenden Suche nach und Verwaltung von potenziellen Sponsorenleistungen befreien.
Anwendungen, welche auf Open Source Bibliotheken setzen, können bei Github genau einsehen, welche ihrer Abhängigkeiten über die Plattform finanziert werden können. Dieser Ansatz löst das Problem häufig eingesetzter Software Pakete, aber nicht unbedingt das Problem von Entwicklern von Anwendungen wie zum Beispiel WordPress Plugins.
Open Source Entwickler sind Experten. Firmen können möglicherweise davon profitieren und sie an ihren Projekten arbeiten lassen. Ich sehe das als indirektes Sponsoring an, wenn die Rahmenbedingungen stimmen. Faire Entlohnung und Zeit für die Weiterentwicklung der Projekte, wenn es um Festanstellungen geht.
Spaß und Anerkennung für alle Beteiligten
Vorher habe ich ja schon erwähnt, dass Spaß am Programmieren und Anerkennung in der Community durchaus valide Motive sind. Fehlt jegliches Sponsoring, wird die Pflege und Wartung von Open Source Projekten automatisch nur in der Freizeit stattfinden können. Wer eine große Reichweite mit seiner Anwendung hat, wird schnell an mentale Grenzen stoßen.
Die geschäftigsten Tage für Supportanfragen sind Samstag und Sonntag. Aus eigener Erfahrung kann ich behaupten: Es ist nicht immer einfach, jede Anfrage gleichermaßen ernsthaft und höflich zu beantworten. Ich habe es mir inzwischen jedoch angewöhnt, Meldungen von Problemen – wenn möglich – mit einer Einladung zu einem Pull Request zu beantworten.
Das verändert nicht nur den Dialog mit Nutzern im Allgemeinen, sondern erzeugt auch das Gefühl von Verantwortlichkeit. Automatisch verteilt man die Last auf mehrere Schultern und schützt sich selbst vor dem mentalen Ausbrennen. Das klingt einedit bisschen, als würde man das Ruder Anderen überlassen, aber das ist eigentlich nie der Fall.
Problem entdeckt, neues Projekt gestartet
Möglicherweise ist dieser Ansatz nicht sehr weise. Inzwischen gibt es so viele Projekte, die von Open Source Entwicklern gepflegt werden, dass man die Kette am besten umschreibt: Problem entdeckt, nach Lösungen gesucht, Open Source Projekt gefunden, Mitarbeit angeboten. Tatsächlich gibt es einige WordPress Plugins, welche dringend nach Autoren suchen.
Diese Vorgehen bietet durchaus Chancen, die ihren Reiz haben. Die Arbeit wird auf mehrere Schultern verteilt. Benutzer profitieren automatisch davon. Manchmal kommt das Leben dazwischen und ein Entwickler bleibt seinem Projekt fern. Projekte mit mehreren Entwicklern sind viel resistenter gegen solche Lücken. Häufig gewinnen sie auch an Qualität.
Open Source Projekte, welche zu einen Großteil von Firmen gepflegt werden, sind nicht unbedingt selten. Hier ist ein starke Community wichtig, so bleiben Ethik und Business gut ausbalanciert. Kleinere Projekte, die von Open Source Entwicklern gepflegt werden, sind in dem Kontext auch wichtig. Sie tragen zur Diversifizierung bei und helfen mit Wettbewerb.
Persönliche Erkenntnisse als Open Source Entwickler
Die Erkenntnisse sind vielfältig. Natürlich wird man bei der Pflege von Open Source Projekten auch ein besserer Programmierer. Und natürlich ist ein gut laufendes Projekt auch eine Visitenkarte! Wer ist bei einem Vorstellungsgespräch noch nicht nach seinem veröffentlichtem Code gefragt worden?
Aber nach der Veröffentlichung eines Projekts tut sich oft ein enormer Berg an Arbeit auf, den man nur schwer allein bewältigen kann. Automatisierung, wann immer es möglich ist, kann den Druck etwas dämpfen (aber nicht herausnehmen).
Was sich vermutlich die meisten Open Source Entwickler wünschen: Mehr Zeit für Projekte, mehr Freizeit für Hobbys und Familie. Aktive Hilfe von Gleichgesinnten, die bei der Dokumentation, beim Support, beim Marketing und bei der Innovation helfen können, kann das möglich machen!