Wie wir Kundenprobleme lösen und dabei Open Source-Software entwickeln
Als Softwareentwickler produzieren wir täglich neuen Code. Wann immer wir Dinge entwickeln, die in mehr als einem Projekt eingesetzt werden, stellen wir den Quelltext öffentlich zur Verfügung. Warum machen wir das? Und was bedeutet es für unsere Kunden und unsere Mitarbeiter?
In diesem Beitrag
Für manche Inhaber von Software-Agenturen ist der Code ihr ein und alles. Sie hüten ihren erschaffenen Quelltext als Betriebsgeheimnis. Der Gedanke dahinter: Sie verfügen über Wissen, das ihnen niemand nehmen kann – weder ihre Kunden noch eine andere Agentur.
Wir haben genau die gegenteilige Einstellung.
Wir teilen unseren Code, den wir für Symfony entwickeln, konsequent in der Open-Source-Gemeinde. Zum Beispiel unser webfactory/exceptions-bundle, das in der offiziellen Dokumentation empfohlen wurde und mittlerweile in den Core integriert ist. Es wurde schon 130.000 Mal heruntergeladen. In der Symfony-Code-Contributors-Liste steht Matthias Pigulla auf Platz 81 von weit über 1000 Entwicklern. Auch unsere Mitarbeiter halten wir an, den Code zu teilen.
Wir meinen es also ernst mit unserem Open Source-Engagement. Aber warum verschenken wir unser Wissen? Folgende Argumente sprechen dafür:
- Fairness: Weltweit treiben Programmierer die Entwicklung von Symfony und anderen Open-Source-Produkten voran. Davon haben wir in der Vergangenheit häufig profitiert. Ob Login-Formular, Registrierungsprozess oder Navigation: Es spart häufig viel Zeit, eine existierende Open-Source-Lösung für ein Feature zu integrieren und zu individualisieren statt es komplett neu zu entwickeln. Es entspricht unserem Verständnis von Fairness, wenn wir der Community etwas zurückgeben.
- Anerkennung: Jeder Softwareentwickler ist stolz auf das, was er erschaffen hat. Wir sind Programmierer aus Leidenschaft und identifizieren uns mit unseren Arbeitsergebnissen. Wir wollen zeigen, was wir können. Es macht Spaß, die Ergebnisse mit anderen Entwicklern zu teilen und zu sehen, wie sich unsere Arbeit verbreitet und weiterentwickelt wird.
- Weiterentwicklung: Wir haben einen hohen Qualitätsanspruch an unsere Arbeit. Auf GitHub diskutieren wir über den Code. Durch die Gespräche und Kritik erweitert sich unser Horizont und wir werden jeden Tag ein kleines Stück besser. Wir bleiben am Puls der Zeit. Das nützt uns und unseren Kunden, für die wir kontinuierlich gute Arbeit abliefern.
Und unsere Kunden?
Durch unser Open Source-Engagement begeben wir uns theoretisch in die Gefahr, unsere Kunden zu verlieren. Schließlich könnte jeder Kunde den Code herunterladen und sich damit an eine neue Agentur wenden, die vielleicht günstiger arbeitet.
Tatsächlich läuft es aber anders. Mit unseren aktiven Kunden arbeiten wir im Durchschnitt über zehn Jahre zusammen. Und zwar nicht, weil sie auf unseren Code angewiesen sind und damit von uns abhängig sind. Sondern weil sie es schätzen, dass wir immer wieder neue Probleme für sie lösen. Unsere Kunden arbeiten mit uns zusammen, weil sie es wollen – und nicht weil sie es müssen.
Dazu kommt: Durch unser Open Source-Engagement bekommen wir regelmäßig neue Aufträge. Entwicklungschefs werden auf unsere Arbeit aufmerksam. Wir müssen ihnen nicht beweisen, dass wir Symfony beherrschen. Man kann sich einfach unseren Code anschauen und sich ein Bild machen.
Ein Beispiel für ein Open Source-Projekt
Wir entwickeln Open Source-Software, in dem wir spezifische Kundenprobleme lösen. Ein Beispiel hierfür: Unser Kunde JUGEND für Europa führt jedes Jahr mehrere Konferenzen unterschiedlicher Größe durch, für die häufig eine eigene Website benötigt wird.
Statt jedes Mal eine Agentur mit der Neuentwicklung einer Konferenzwebsite zu beauftragen, wollte JFE ein Standardsystem schaffen, so dass jedes Mal eine Konferenzwebsite mit individuellem Design, aber einheitlicher Funktionalität eingerichtet werden kann.
Dabei entstand das Problem, dass manche Konferenzen eine mehrsprachige Website brauchten, die meisten aber mit einer Sprache auskamen. Wir mussten also eine Lösung entwickeln, die die Pflege von mehrsprachigen Inhalten ermöglicht, dabei aber die Pflege einsprachiger Websites nicht komplizierter macht.
Hierfür haben wir nach einer Open Source-Lösung gesucht, allerdings keine gefunden. Also haben wir ein eigenes System entwickelt, dass wir Polyglot genannt haben. Nachdem wir Polyglot in mehreren Projekten erfolgreich eingesetzt haben, haben wir den Library-Code geopensourct.
Das Fazit: Wir haben ein Kundenproblem gelöst und gleichzeitig Open Source-Software entwickelt.