Wie Software-Entwickler sich einbringen können

Open-Source-Engagement als Angestellter

Seite: 2/2

Firmen zum Thema

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)