Wie Software-Entwickler sich einbringen können Open-Source-Engagement als Angestellter

Autor / Redakteur: Tom Hombergs * / Stephan Augsten

Open Source gehört zum Software-Development-Alltag dazu, fast alle denkbaren Probleme wurden schon einmal gelöst. Dieser Artikel geht auf den Reiz am Open-Source-Engagement ein, wie sich das mit dem Angestelltenverhältnis verträgt und was uns dabei im Wege steht.

Firmen zum Thema

Verdingt sich ein Entwickler als Open-Source-Kontributor, kann das auch für seinen Arbeitgeber nützlich sein.
Verdingt sich ein Entwickler als Open-Source-Kontributor, kann das auch für seinen Arbeitgeber nützlich sein.
(Bild: Lewis Ngugi - Unsplash.com)

Als angestellte Software-Entwickler arbeiten wir üblicherweise an Produkten für unseren Arbeitgeber oder dessen Kunden. Das Produkt beherrscht dabei unseren Alltag. Deadlines sind einzuhalten, Bugs wollen gefixt werden. Workarounds müssen gebaut werden, um fehlende Features in den genutzten Open-Source-Bibliotheken zu umgehen. Oft geht dabei unter, dass ein Beitrag zu den genutzten Open-Source-Projekten uns das Leben viel einfacher machen würde.

Open-Source-Software ist längst zu einer Lebensader in der Softwareindustrie geworden. Ohne sie wären Softwareprojekte heute viel teurer, als sie es sowieso schon sind. Man stelle sich nur vor, dass wir in jedem Projekt von Grund auf wieder anfangen müssten, eine Datenbankabstraktion oder einen Dependency-Injection-Mechanismus selbst zu programmieren. Wir würden aus den „Design-Sprints” oder „Sprints 0” gar nicht mehr herauskommen und keinen Mehrwert entwickeln.

Durch die Verfügbarkeit von Open-Source-Bibliotheken und anderer Open-Source-Software werden Ideen ausgetauscht. Eine Idee befruchtet woanders auf der Welt eine neue Idee, und die nächste Open-Source-Generation ist geboren. Das Ergebnis sind Innovationen, die die Softwareentwicklung maßgeblich beeinflussen.

Aber woher kommt diese Open-Source-Software eigentlich? Wer arbeitet daran? Es gibt viele Software-Entwickler, die in ihrer Freizeit an diesen Projekten arbeiten, weil sie einfach Spaß daran haben, Probleme zu lösen. Es gibt Firmen, die Open Source entwickeln und ihr Geschäft rund um ein Open-Source-Produkt aufstellen. Und es gibt Firmen, die Open-Source-Projekte mit Entwicklerkapazitäten unterstützen, um in der Community präsent zu sein und Einfluss zu nehmen.

Aber wo stehen wir als „einfache” Anwendungsentwickler in diesem Kontext? Wenn wir ehrlich sind, beschränkt sich unser Kontakt zu Open Source doch meist nur darauf, dass wir eine Open-Source-Bibliothek in unser kommerzielles Projekt einbinden und dankbar sind, dass wir es nicht selbst entwickeln müssen. Das muss aber gar nicht so sein. Wir können uns auch beteiligen!

Der Reiz von Open Source

Was macht eigentlich den Reiz aus, sich an der Entwicklung von Open-Source-Projekten zu beteiligen? Insbesondere Personen, für die „Open Source” nicht mehr als ein abstrakter Begriff ist, verstehen oft nicht, warum man Zeit investiert, um Software zu entwickeln, die andere Personen fast ohne Einschränkungen nutzen und verbreiten können. Und das auch noch umsonst!

Der vermutlich häufigste Grund für Open-Source-Engagement ist, dass ein Problem unsere Leidenschaft geweckt hat, es mit Software zu lösen. In diesem Fall sind wir durchaus auch mal bereit, uns in unserer Freizeit damit auseinanderzusetzen.

Es macht darüber hinaus aber auch einfach Spaß, außerhalb der Strukturen und des Drucks eines kommerziellen Projekts Software zu entwickeln. Man lässt sich Zeit für die Dinge, die einem selbst wichtig sind, und kann die eigenen Ideen verwirklichen anstatt die Ideen anderer in Software zu gießen. Diese Leidenschaft führt nicht selten zu besserer Code-Qualität und erhöhter Motivation und Zufriedenheit.

Das „Open” aus „Open Source” ist ein weiterer Reiz für viele Software-Entwickler. Man entwickelt nicht im dunklen Kämmerlein für sich und seinen Arbeitgeber allein, sondern in der Öffentlichkeit. Jeder kann sehen, was man bisher entwickelt hat. Und wenn noch niemand über unser Projekt gestolpert ist, so reicht häufig auch schon das Potenzial aus, dass es jemand finden könnte, um die Motivation hoch zu halten. Früher oder später findet ja letztlich auch jedes Open-Source-Projekt einige Nutzer – und sei es noch so klein.

In eigener Sache

Die Arbeit in der Öffentlichkeit reizt darüber hinaus auch dadurch, dass man sich damit ein Portfolio als Software-Entwickler aufbaut. In einem GitHub-Profil stecken viele Informationen darüber, was ein Entwickler so kann und wofür er sich interessiert.

Nicht umsonst besitzt GitHub auch Elemente einer Social-Media-Plattform. Man kann anderen Entwicklern folgen, seine liebsten Projekte in einem Showcase anzeigen und Sterne für die Projekte anderer vergeben. Auch Recruiter haben mittlerweile gemerkt, dass GitHub mehr als nur ein Spielplatz für Nerds ist und suchen dort fleißig nach Entwicklern für ihre Kunden. Für uns Entwickler ist es dann durchaus reizvoll, sein Profil auf GitHub zur Schau zu stellen.

Nicht jeder Entwickler hat Zeit und Lust, seine Freizeit für Open-Source-Engagement zu opfern. Ein Projekt muss schon unsere Leidenschaft am Entwickeln geweckt haben, damit wir abends noch Code, Dokumentation oder sonstige Beiträge leisten – und selbst dann lässt es nicht jede Lebenssituation zu.

Open-Source-Entwicklung im Arbeitsalltag

Im Entwickler-Alltag geht häufig unter, dass man im Rahmen eines „normalen” Softwareprojekts für einen Kunden oder für das eigene Unternehmen auch während seiner Arbeitszeit Beiträge für Open-Source-Projekte leisten kann.

Da wir Open-Source-Bibliotheken und -Frameworks in unserem Projekt selbst einsetzen, wissen wir oft ziemlich genau, was uns noch an Features fehlt oder welche Bugs besonders schmerzhaft sind. Was liegt dann näher, als ein Ticket bei den Entwicklern zu öffnen und das Problem zu beschreiben? Viele Entwickler reagieren sehr schnell und eine Diskussion ist geboren, an der man sich beteiligen kann, um das Open-Source-Produkt ein Stückchen besser und unsere Arbeit im Projekt etwas leichter zu machen.

Beschäftigt man sich während der Arbeitszeit mit solchen Diskussionen in der Open-Source-Community, verspürt man vielleicht das Gefühl, nichts zum eigenen Projekt beizutragen. Aber das ist nicht der Fall! Schließlich vertritt man ja die Interessen des Projekts.

Selbst wenn die Entwickler nur sehr langsam reagieren oder die gewünschte Änderung gerade nicht selbst angehen können oder wollen, kann man aktiv werden. Man kann Bugs selbst beheben oder Features selbst entwickeln und als Pull Request bereitstellen. Hier ist die Hemmschwelle höher, da man sich in das Open-Source-Projekt erst einarbeiten und somit mehr Zeit investieren muss. Aber auch hier ist es legitim, die eigene Arbeitszeit dafür zu nutzen. Diese Investition der eigenen Arbeitszeit sollte dann aber mit dem Arbeitgeber abgestimmt sein.

Neben dem Engagement in den selbst genutzten Open-Source-Bibliotheken kann man natürlich auch eigene Ideen als Open Source in die Welt setzen. Hat man im eigenen Projekt zum Beispiel ein Problem zum x-ten Mal gelöst, wird das Problem vermutlich auch in anderen Projekten bestehen. Erst recht, wenn man als Berater immer mal wieder das Projekt (und den Kunden) wechselt, ärgert man sich, wenn man den Quellcode aus dem letzten Projekt nicht einfach wiederverwenden darf.

Die Veröffentlichung von Quellcode aus dem Projekt muss natürlich mit den Projektverantwortlichen abgestimmt sein. Einige Argumentationshilfen werden weiter unten beschrieben. In jedem Fall sollten wir die Ergebnisse unseres Open-Source-Engagements feiern und im eigenen Arbeitsumfeld bewerben. Das ebnet den Weg für weiteres Open-Source-Engagement.

Überzeugungsarbeit

Manager reagieren häufig eher zurückhaltend, wenn man vorschlägt, Arbeitszeit in ein Open-Source-Projekt zu investieren. Warum sollte man auch in ein fremdes Projekt investieren? Oder gar Ideen aus den hauseigenen Projekten anderen zur Verfügung stellen? Was bringt uns das?

Hier schwingt natürlich die Angst vor Gewinneinbußen mit, weil wir uns mit einem fremden Projekt anstatt mit wertschöpfender Arbeit beschäftigen. Und es ist ja auch eine echte Investition, ein Open-Source-Projekt mit der eigenen Arbeitszeit zu unterstützen. Aber es gibt viele Gründe, die dafür sprechen, dass diese Investition sich letztendlich auszahlt.

Zunächst sammelt man sehr viel Erfahrung mit einem Open-Source-Projekt, wenn man mal unter dessen Haube schaut. Diese Erfahrung zahlt sich natürlich insbesondere dann aus, wenn man das Open-Source-Projekt in der „wertschöpfenden Arbeit” auch nutzt. Dann hat man den direkten Mehrwert, dass man die eigene Entwicklung schneller vorantreiben kann, da man sich besser mit dem Open-Source-Projekt auskennt. Diesen Mehrwert dem Management deutlich zu machen, kann schon ausreichen, um die Freigabe für Open-Source-Arbeit während der Arbeitszeit zu bekommen.

Die so gesammelte Expertise lässt sich natürlich auch vermarkten. Wer vergibt seine Aufträge nicht gerne an Firmen, die engagierte Entwickler haben, die sich in dem avisierten Open-Source-Technologie-Stack so gut auskennen, dass sie selbst Bugs beheben oder gar neue Features ergänzen können? Darüber hinaus kann mit Blog-Posts, Fachartikeln oder Talks auf Konferenzen auf diese Expertise gegenüber Kunden und dem Arbeitsmarkt aufmerksam gemacht werden, um die Attraktivität der Firma zu steigern.

Das richtige Maß finden

Geht es darum, eine Komponente aus dem eigenen Projekt als Open Source zu veröffentlichen, kommt häufig das Gegenargument, dass man damit ja Betriebsgeheimnisse veröffentlicht. Natürlich sollte man es sich gut überlegen, den Kern des eigenen Geschäfts als Open Source zu veröffentlichen (was viele Firmen aber durchaus erfolgreich tun). Allerdings gibt es häufig auch Komponenten, die einfach technische Grundlagen bilden und von Projekt zu Projekt wiederverwendet werden können. Damit hat man sogar einen Synergieeffekt für die eigenen Projekte geschaffen, die nicht jedes Mal bei null anfangen müssen.

Im besten Fall wird so eine Open-Source-Komponente dann ja auch von anderen Entwicklern da draußen genutzt und es bildet sich eine Community. Hier kommt das nächste Gegenargument: Man muss ja Zeit reinstecken, um das Open-Source-Projekt zu maintainen und die Community zu pflegen. Aber was kann eigentlich besser sein, als ein häufig genutztes Open-Source-Projekt in der eigenen Verantwortung zu haben? Damit kann man Werbung machen! Und außerdem gewinnen die eigenen Projekte, die das Open-Source-Produkt nutzen, denn es wird dann sicherlich Beiträge von Entwicklern aus der Community geben, die das Produkt weiterentwickeln.

Neben den Argumenten gegen Open-Source-Engagement aus dem Management kann es aber auch sein, dass man sich als Entwickler selbst gar nicht traut, Open-Source-Beiträge während der Arbeitszeit zu leisten. Mit gutem Grund, denn das Urheberrechtsgesetz §69b besagt:

„Wird ein Computerprogramm von einem Arbeitnehmer in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers geschaffen, so ist ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse an dem Computerprogramm berechtigt, sofern nichts anderes vereinbart ist.”

Das kann zumindest für Beiträge in fremden Open-Source-Projekten natürlich nicht funktionieren und sollte deshalb mit dem Arbeitgeber besprochen werden.

Fazit

Open-Source-Engagement hat für alle Vorteile: für angestellte Entwickler, für den Arbeitgeber und letztendlich natürlich auch für das unterstützte Open-Source-Projekt.

Für uns Entwickler ist es ein Weg, unsere Leidenschaft in der Öffentlichkeit der Open-Source-Community auszuüben. Der Arbeitgeber kann unser Engagement gewinnbringend im Arbeitsmarkt und gegenüber den Kunden einsetzen. Und das Open-Source-Projekt profitiert, da wir Bugs fixen und neue Features umsetzen.

Tom Hombergs
Tom Hombergs
(Bild: adesso AG)

Wenn Zweifel bestehen, ob man in der Arbeitszeit Open-Source-Projekte unterstützen darf, hilft es, einfach mal darüber zu reden. In vielen Fällen reicht das schon aus, um den Stein ins Rollen zu bringen.

* Tom Hombergs ist Softwarearchitekt und Teamleiter bei der adesso AG in Dortmund und dort als Entwickler, Coach und Architekt in Kundenprojekten tätig. Sein aktueller Schwerpunkt liegt in verteilten Architekturen mit dem Spring Stack. Auf seinem Blog Reflectoring.io schreibt er über Technologien und Konzepte, die ihn beschäftigen. Nebenher engagiert er sich als Redakteur auf Baeldung.com und Organisator der Java User Group Dortmund.

(ID:45377053)