Open Source ist ein steter Begleiter in der Entwicklung und Infrastrukturbetreuung bei uns im Team. Wie die Benutzung und Mitarbeit an Open Source Projekten die Motivation verbessern kann, möchte ich an dieser Stelle aufzeigen.
Kubernetes, Docker, Linux, Jenkins und viele andere Open Source Projekte sind aktuell omnipräsente Beispiele von Open Source in Unternehmen. Der Trend mehr Open Source zu verwenden ist laut Studie von Bitcom (1) stetig am Wachsen. Wir alle profitieren von gut gewarteter Software, schneller Implementierung von wichtigen Features oder geringen Kosten für Lizenzen und die häufig gewünschte Herstellerunabhängigkeit. Allerdings sollte ein Unternehmen immer in Betracht ziehen, auch etwas zurückzugeben, somit Teil der Community zu werden. Wissen, Code und Software mit der Gemeinschaft zu teilen, sollte nicht als Einbahnstraße gesehen werden, sondern auch ein Motivator für die Mitarbeiter sein.
Was motiviert Mitarbeiter an der Benutzung von Open Source?
Open Source entsteht zum Einen aus Unternehmungen heraus (Quellcode eines internen Projektes wird veröffentlicht), zum Anderen teilen ein paar Freiwillige ihren Code auf github und Co. Beide Ansätze bilden die Hauptgrundlage für das große Angebot von Open Source Software heute. Meist ist diese Software in der Verwendung thematisch eng umrissen und für einen spezifischen Zweck gedacht. Nicht jedes Open Source Software Projekt kommt in die Hall of Fame, wie es etwa bei Linux, Apache HttpServer, MediaWiki von WikiPedia und Co. der Fall ist – Ich grenze hier bewusst auf Software ab, da Open Source auch Bilder, Grafiken etc. sein können.
Mitarbeiter sind während der Arbeitszeit selten aktiv an einem Open Source Projekt beteiligt und wenige kennen die Organisation und Prozesse darin. Es ist für viele ein Buch mit sieben Siegeln und daher entsteht großer Respekt vor der Community und den dahinter stehenden Abläufen. Die Benutzung ist dagegen sehr verbreitet.
Story zum Erfolg
In diesem Blog möchte ich erzählen, wie wir mit dem Thema umgehen und wie sich die Perspektive im Team verändert hat.
Erste Kontakte zu Open Source Software werden vermutlich die meisten schon gehabt haben. Bei uns im Team ist das nicht anders. Der Einsatz von Open Source Software ist attraktiv, weil sie aus Anwendersicht einfach verfügbar und häufig gut dokumentiert ist. Benutze ich als Anwender die Software in dem korrekten Kontext, wird dies meist ein Erfolg. Gleichfalls bauen sich in einem Team selten ungewünschte Kopfmonopole auf, da das Wissen um die Verwendung und Einrichtung bereits ausreichend dokumentiert ist. Gesonderte Dokumentation ist kaum notwendig, dann geht es eher um die Konfiguration.
So sammeln die Mitarbeiter wiederkehrend positive Erfahrungen mit Open Source Software. Ähnlich ist es bei Wartungsaspekten oder Sicherheitsupdates. Ein regelmäßiges Updaten auf neuere Versionen ist bei großen Projekten einfach und gut dokumentiert. Probleme gibt es selten und wenn, werden diese sehr schnell gefixt. Die Attraktivität zum Einsatz von Open Source im Gegensatz zu ‚Wir schreiben uns unsere eigene Software selbst‘ oder ‚Software kaufen wir‘ steigt sukzessiv. Der entscheidende Punkt ist hier die Herangehensweise: Erkenne ich als Mitarbeiter den korrekten Anwendungsbereich und kann dies auf entsprechende Open Source Projekte mappen, wird der Einsatz schnell ein Treffer. Und die Open Source Nutzung steigt weiter.
Mitarbeit an einem Open Source Projekt ist eine andere Nummer
Neben der Nutzung von Open Source ist die Mitarbeit daran etwas ganz anderes. Anfänglich gab es großen Respekt vor der Open Source Community. In Diskussionen gab es immer wieder Fragen im Team:
- Kann ich als Entwickler eigentlich etwas beitragen?
- Sind wir qualifiziert genug?
- Müssen wir da etwas tun?
- Wie geht das eigentlich, wenn ich Code der Community zurückgeben möchte?
Viele Fragen wurden gestellt und alles war etwas nebulös und unkonkret. In meinen Augen ist Wagemut, mal etwas Neues auszuprobieren, der richtige Einstieg.
Gegenüber dem Arbeitgeber gab es ähnliche Fragestellungen:
- Darf ich in meiner Arbeitszeit an Open Source Projekten mitarbeiten?
- Darf ich den Code der Community zurückgeben?
Auch hier bedarf es einer gewissen Klarheit der Unternehmensleitung. In einem Gespräch ließ sich dies bei uns eingrenzen und kurz zusammenfassen: Wir sind kein Open Source Entwicklungsbetrieb, d. h. grundsätzlich entwickeln wir unsere eigenen Produkte für unsere Muttergesellschaft. Wir können aber im Rahmen der Open Source Benutzung etwas zurückgeben, dies ist nicht untersagt. Im Gegenteil, es ist eine gewünschte Anerkennung der Leistung der Community. Zusätzlich haben wir die Chance eigene Bedürfnisse bzw. Aspekte in der Community berücksichtigen zu lassen, wenn der Code denn angenommen wird. Wir vermeiden Eigenlösungen oder gesonderte Forks.
Zum Einstieg waren es genau diese Aspekte, die die Mitarbeit an einem Open Source Projekt ermöglichten und förderten.
Bild: Gemeldete Sicherheitslücke im Kubernetes/Jenkins-Umfeld
Beispiele: Ein Gradle-Plugin wurde entsprechend unseren Vorstellungen erweitert, sowie ganz aktuell eine Sicherheitslücke im Kubernetes/Jenkins geschlossen. Die Motivation und der Stolz bei der Annahme der jeweiligen Codeteile ist immens. Die Barriere Richtung Open Source Mitarbeit sinkt, der Respekt vor der Leistung der Community bleibt.
Interview mit einem Mitarbeiter
Über das Thema Sicherheit im Jenkins habe ich ein Interview mit meinem Kollegen Marcelo Castro geführt. Bei seiner täglichen Arbeit hat er eine Sicherheitslücke im Jenkins entdeckt und sich aktiv darum gekümmert, dass diese untersucht und behoben wird. Und auf einmal ging alles ganz schnell…
Marcelo, wie kam es zu der Situation?
Im Team beschäftigen wir uns stetig mit der Verbesserung und Optimierung unserer technischen Arbeitsabläufe. Ein wichtiges Thema zum Ende des Jahres war die Überführung unseres Jenkins in einen Kubernetes-Cluster. Das Thema Security spielte dabei einen wichtigen Faktor und war immer präsent. Dementsprechend wurde überprüft, wie die Sicherheitsaspekte im Jenkins am besten umgesetzt werden können. Im Zuge der Analyse und Umsetzung ist ein Security-Fehler aufgedeckt worden, durch den nicht autorisierte Prozesse Zugriff auf Zugangsdaten haben konnten, die eigentlich nur intern im Jenkins hätten sicherbar sein dürfen.
Im ersten Moment dachte ich, dass ich gegebenenfalls etwas falsch konfiguriert habe, aber nach erneuter Überprüfung und dem Aufbau von verschiedenen Testszenarien, wurde mir klar, dass der Fehler tatsächlich in einem Plugin vom Jenkins lag.
Nach kurzer Überlegung habe ich mich anschließend dazu entschlossen, den Fehler bei der Jenkins Community zu melden.
Was waren deine Bedenken bei deiner Einreichung?
Ich hab mich in der Tat ein wenig gewundert, dass so ein offensichtlicher Fehler bisher von niemandem entdeckt wurde. Dementsprechend war ich ganz gespannt, wie auf das Security-Ticket reagiert wird. Ob es angenommen wird und wie lange es dauert bis es letztlich auch gefixt wird.
Wie groß hast du deine Chance auf Annahme deines Requests gesehen?
Ich war mir ziemlich sicher, dass mein Request Beachtung finden wird. Immerhin handelt es sich hierbei um eine Sicherheitslücke, die alle Nutzer betrifft, die das entsprechende Plugin nutzen und damit systemseitige Zugangsdaten teilweise ungeschützt sind.
Hast du auf etwas geachtet bei der Einreichung?
Mir war es wichtig, den richtigen Weg einzuhalten und das Security-Ticket auch an der richtigen Stelle zu melden. Ich wollte ja nicht, dass ich die Sicherheitslücke einfach so irgendwo poste und dann jeder diese Schwachstelle ausnutzen könnte.
Daher hab ich mich an das offizielle Vorgehen gehalten. Natürlich musste man ebenfalls beachten, keine internen Daten zu veröffentlichen. Dementsprechend wurden nur für den Fehler relevante Informationen sowie Details zum Testszenario veröffentlicht.
Wie hast du auf die Annahme reagiert?
Obwohl es kurz vor Weihnachten war, erhielt ich bereits 30 Minuten nach der Einreichung eine Nachricht, dass dies eine interessante Thematik sei, aber eine genauere Überprüfung erst nach dem Jahreswechsel stattfinden könne.
Am 3. Januar wurde mir dann mitgeteilt, dass das Szenario überprüft wurde und der Fehler ebenfalls festgestellt werden konnte. In den darauffolgenden Tagen habe ich Einblicke in den Prozess der Fehlerbearbeitung sowie Einblicke in die falschen Code-Stellen bekommen.
Wie war es für dich, als der Fehler dann gelöst wurde und wie fühltest du dich dabei?
Am 24. Januar war es dann soweit und der Bugfix wurde endlich ausgerollt.
Ab dem Zeitpunkt zeigte jede Jenkins-Instanz, die aktualisierte Informationen über Security-Tickets bekommt, folgende Fehlermeldung an. Sprich weltweit und ich hab es ausgelöst
Bild: Warnmeldung in den Jenkins-Instanzen weltweit
Wie war das Feedback in deinem Team und der Firma?
Ich habe durchweg positives Feedback erhalten. Vor allem von meinen Teamkolleginnen und Teamkollegen, aber auch von anderen befreundeten Kollegen war das Feedback großartig. Es freut mich immer wieder mit so tollen Kolleginnen und Kollegen zusammen zu arbeiten.
Wie stolz bist du bei der Erwähnung deines Namens auf den Open Source Seiten?
Im Zuge der Veröffentlichung des Security-Tickets wurde ich in der Tat beim „Jenkins Security Advisory 2023-01-24“ (https://www.jenkins.io/security/advisory/2023-01-24/) namentlich erwähnt. Ich persönlich habe mich darüber sehr gefreut.
Würdest du in Zukunft wieder an einem Open Source Projekt mitarbeiten?
In der Tat habe ich nun ein wenig Blut geleckt und auch schon ein paar Ideen, was man vielleicht in diesem Bereich machen kann…
Danke Marcelo für das offene Gespräch
Open Source als Motivator
An diesem Beispiel ist gut zu sehen, wie etwas aus der täglichen Arbeit konkret in die Community überführt werden kann. Unsere Probleme wurden gelöst und andere Nutzer haben auch etwas davon. Das motiviert uns, speziell den einzelnen Mitarbeiter und ist für alle eine Win-Win-Situation. Es bedarf nur klarer Vorgaben, wie mit dem Thema Mitarbeit bei Open Source Projekten umgegangen werden soll. Der Rest entwickelt sich von allein.
Links
1: Bitcom – Open-Source-Monitor, Survey Report 2021, https://www.bitkom.org/sites/main/files/2022-04/220405_Bitkom_Studie_OpenMonitor_2021_ENG.pdf (Stand 02.02.2023)
2: Jenkins Security https://www.jenkins.io/security/advisory/2023-01-24/
