Open Source Resistance: Open Source während der Arbeitszeit verteidigen

 (ossresistance.com)
6 Punkte von GN⁺ 2026-05-15 | 2 Kommentare | Auf WhatsApp teilen
  • Open Source Resistance ist ein Manifest für direkte Aktion, das dazu aufruft, die Wartung der Open-Source-Software, von der Unternehmen abhängen, unauffällig und professionell während der Arbeitszeit zu erledigen
  • Obwohl kein Unternehmen ohne Open Source sein Geschäft betreiben kann, lehnt es die Struktur ab, in der Maintainer um gesonderte Genehmigung, einen Spenden-Button oder Freitagnachmittagszeit betteln müssen
  • Es gab bereits Alternativen wie Open Source Pledge (Forderung nach US$2.000 pro Jahr je Entwickler) oder Open Source Friday (mindestens 2 Stunden Beitrag jeden Freitag), doch hier wird eine direktere Umsetzung vertreten
  • Auf den Einwand des „Zeitdiebstahls“ kann geantwortet werden, dass Unternehmen bereits kostenlose OSS-Subventionen erhalten haben und die Wartung abhängiger OSS Arbeit an gemeinsamer Infrastruktur ist
  • Die IP-Übertragungsklauseln im Arbeitsvertrag müssen unbedingt geprüft und Open-Source-Carve-outs schriftlich ausgehandelt werden

Manifest: Nicht um Erlaubnis bitten, bereits notwendige Arbeit zu reparieren

  • Open Source Resistance schlägt als direkte Aktion vor, die Wartung von Open-Source-Software (OSS), von der die Firma abhängt, nicht in nächtliche oder Wochenend-Hobbys abzudrängen, sondern sie ruhig und professionell während der Arbeitszeit auszuführen
  • Open-Source-Software ist kein „Hobby“ für die Freizeit, und Unternehmen ziehen in jeder Stunde Wert aus Open Source, bieten Maintainers jedoch nur Dinge wie einen Freitagnachmittag, einen Spenden-Button oder ein Dankeschön im All-Hands-Meeting
  • Maintainer sollten innerhalb des Unternehmens an OSS-Code arbeiten, von dem die Firma bereits abhängt, ohne Papierkram, interne Programme oder Manager-Freigaben und zwar während der Arbeitszeit
  • Das ist keine neue Idee, sondern nur das öffentliche Aussprechen der Art und Weise, wie der Großteil von Open Source schon immer entstanden ist
  • Maintainer haben das Internet am Laufen gehalten, ohne auf Meetings, Sprints oder die Erlaubnis von Produktmanagern zu warten

Zentrale Handlungsprinzipien

  • Schützt euch selbst

    • Prüft euren Arbeitsvertrag, haltet vertrauliche Informationen im Unternehmen und stellt sicher, dass ihr Eigentum an der Open-Source-IP habt, die ihr veröffentlicht

  • Erledigt die Arbeit

    • Führt PR-Reviews, Dependency-Updates und Bugfixes an Teilen durch, die bereits OSS sind

  • Seid nicht leichtsinnig

    • Verwendet nicht 100 % der Arbeitszeit für OSS und gebt nach einer Kündigung anderen die Schuld; Balance ist entscheidend

Bestehende Alternativen

  • Open Source Pledge: fordert Unternehmen auf, Maintainer zu bezahlen (US$2.000 pro Jahr je Entwickler)
  • Open Source Friday: fordert Unternehmen auf, Zeit zu spenden (mindestens 2 Stunden jeden Freitag)
  • Es gibt auch den höflichen Weg, zuerst den Arbeitgeber zu überzeugen; all das ist positiv und unterstützenswert
  • Open Source Resistance ist der nächste Schritt in dieser Entwicklung und erklärt, dass die Wartung der Dependency Chain bereits Teil der Arbeit ist, auch wenn das Management sie nicht so benennt
  • Wie das Unternehmensbudget verteilt wird, liegt außerhalb eurer Kontrolle, aber wie ihr eure Arbeitszeit nutzt, könnt ihr kontrollieren

Erwartbare Einwände und Antworten

  • „Das ist Zeitdiebstahl / Diebstahl an den Aktionären“

    • Unternehmen ziehen bereits jeden Tag Wert aus Open-Source-Maintainern, und Aktionäre haben jahrzehntelang kostenlose Open-Source-Subventionen erhalten
    • Wenn ein Arbeitgeber von OSS abhängt, dann ist dessen Wartung Arbeit an öffentlicher Infrastruktur und kein Diebstahl

  • „Man muss um Erlaubnis fragen“

    • Um Erlaubnis zu bitten, erhält das Machtungleichgewicht aufrecht
    • Man braucht nicht den Segen eines Managers, um Infrastruktur zu warten, von der der Arbeitgeber bereits abhängt

  • „Das ist wie quiet quitting“

    • Quiet quitting reduziert die Arbeitsleistung, dies hier aber produziert die OSS-Infrastruktur, auf der das Internet aufgebaut ist
    • Das Problem ist nicht die Arbeit selbst, sondern dass Unternehmen sich weigern, sie als Arbeit einzustufen

  • „Auch gute Arbeitgeber werden dadurch getroffen“

    • Gute Arbeitgeber umgehen dieses Problem, indem sie Open-Source-Wartung während der Arbeitszeit erlauben, Maintainer finanzieren oder am Open Source Pledge teilnehmen

Die Erfahrungen von Mike McQuaid

  • Mitbegründer von Open Source Friday und GitHub Sponsors sowie Projektleiter von Homebrew (Maintainer seit 2009)
  • In keinem Job wurde ihm Arbeit an Open-Source-Projekten wie Homebrew als Hauptaufgabe bezahlt
  • Trotzdem hat er sie bei allen Arbeitgebern erledigt, die IP-Verträge ausgehandelt, um sie zu legalisieren, und seine Arbeitszusagen eingehalten
  • Seit er Kinder hat, werden mehr als 90 % seiner Open-Source-Arbeit während der Arbeitszeit erledigt
  • Wie in Open Source Maintainers Owe You Nothing vertritt er die Ansicht, dass niemand das Recht hat, unbezahlte Nächte, Wochenenden oder Familienzeit von Maintainers zu verlangen, nur weil das Geschäftsmodell eines Unternehmens von ihrem Code abhängt

Hinweise und rechtlicher Disclaimer

  • Keine Rechtsberatung

    • Es wird ausdrücklich klargestellt, dass dies keine Rechtsberatung ist und keine Beratung zu Verträgen, Arbeitgebern, Einwanderungsstatus, Lizenzpflichten oder individuellen Situationen darstellt
    • Wenn das Risiko hoch ist, sollte man sich vor dem Handeln mit qualifizierten Personen beraten
    • Wie die meisten Open-Source-Lizenzen wird dies ohne jegliche Gewährleistung und „wie gesehen“ bereitgestellt

  • Verträge, Richtlinien, Eigentum

    • Arbeitsverträge, Handbook-Richtlinien und Klauseln zur Übertragung von Erfindungen können Rechte an während der Beschäftigung geschaffener Arbeit, an Arbeit auf Geräten des Arbeitgebers oder an Arbeit im Aufgabenbereich beanspruchen
    • In einigen Bundesstaaten sind solche Ansprüche auf Arbeit, die in der eigenen Zeit und auf eigenen Geräten entsteht, eingeschränkt, aber die Details sind entscheidend
    • Vor der Umsetzung sollte der Arbeitsvertrag gelesen und geprüft werden, dass der Arbeitgeber nicht die Open-Source-IP besitzt, die man veröffentlichen will
    • Wenn Geräte, Netzwerk oder Accounts das Eigentumsrisiko verändern, sollten die eigenen genutzt werden

  • IP-Verträge verhandeln

    • Die Übertragung von IP ist oft verhandelbar; empfohlen wird, bei einem Jobangebot vor der Unterschrift schriftlich eine Open-Source-Ausnahmeklausel zu verlangen
    • Zuerst sollte man die Employee IP Agreements lesen, um zu verstehen, welchen Teilen man widersprechen sollte
    • Mike McQuaid sagt, dass er bei fast allen Arbeitgebern Änderungen gegenüber Standardverträgen ausgehandelt habe und meist deutlich weniger Gegenwehr kam als erwartet
    • Potenziellen Arbeitgebern kann GitHubs Balanced Employee IP Agreement gezeigt werden
    • Diese Vereinbarung wurde unter CC0 als Open Source veröffentlicht, von einem großen börsennotierten Unternehmen tatsächlich verwendet und so gestaltet, dass Arbeitgeber behalten, wofür sie zahlen, während Beschäftigte Open-Source-Arbeit behalten, die nicht mit dem Geschäft konkurriert

  • Vertraulichkeit und Sicherheit

    • Private Repositories, Zugangsdaten, Incidents, Kundendaten, Roadmaps, nicht veröffentlichte Schwachstellen und interne Diskussionen dürfen nicht offengelegt werden
    • Sicherheitskontrollen dürfen nicht umgangen und keine unzulässigen Zugriffsrechte genutzt werden
    • Direkte Aktion ist kein Vorwand, vertrauliche Unternehmensinformationen offenzulegen, sondern bedeutet, öffentliche Arbeit öffentlich zu halten und klar von Geschäftsgeheimnissen zu trennen

  • Still bedeutet nicht nachlässig

    • Wenn Richtlinien, Verträge, Kundenpflichten oder Sicherheitsregeln das Risiko verändern, ist eigenes Urteilsvermögen nötig
    • Möglicherweise muss auf eigenen Geräten, mit eigenen Accounts und im eigenen Netzwerk gearbeitet werden
    • Es geht nicht darum, das Unternehmen zu „bestehlen“, sondern die Balance zwischen dem, was das Unternehmen aus Open Source nimmt, und dem, was man zurückgeben kann, wiederherzustellen
    • Man kann schlechtere Leistungsbewertungen als Kollegen bekommen, aber eine nachhaltige B-Bewertung ist gesünder, als das eigene Leben für eine A-Bewertung in einem Unternehmen aufzubrauchen, das einen morgen entlassen kann

  • Grenzen der Anwendbarkeit

    • Dieses Argument ist am schwächsten, wenn Zeit auf bestimmte Kunden, Fördermittel, Behörden, Verteidigungsprojekte oder regulierte Umgebungen gebucht wird
    • Es ist auch am schwächsten für Junior- oder prekär beschäftigte Engineers, die nicht den Einfluss haben, Nachteile aufzufangen
    • Am stärksten ist es für erfahrene Maintainer, die öffentliche Abhängigkeiten reparieren, die der Arbeitgeber bereits nutzt
    • Die sauberste Form ist nicht „Mach während der Arbeitszeit, worauf du Lust hast“, sondern Open-Source-Wartung als Teil der Engineering-Arbeit zu behandeln
    • Wartet Projekte, die ihr bereits betreut, verbessert gemeinsam genutzte Tools, die eure Arbeit berühren, und vermeidet Irrelevantes, proprietären Code oder Dinge, die echte Verpflichtungen verfehlen lassen

Quelle und Projekt

Verwandte Beiträge

2 Kommentare

 
roxie 2026-05-22

Insgesamt ... scheint der Ausdruck „Résistance“ passend zu sein.
 
GN⁺ 2026-05-15
Hacker-News-Kommentare

  • Es war meist so, dass Unternehmen eine umfassende Erlaubnis dafür gaben, zu bestimmten Open-Source-Projekten beizutragen.
    Die Formulierung ist wichtig. Man sollte nicht sagen: „Darf ich ein bisschen Wohltätigkeitsarbeit machen, damit ich mich besser fühle?“, sondern: „Darf ich von Expert:innen in diesem Bereich kostenlos ein strenges Review bekommen und die Änderungen in das Upstream-Open-Source-Projekt einbringen, damit dem Unternehmen künftig Wartungskosten entfallen?“
    Genau das ist in Wirklichkeit der Kern der Sache, und wenn ich es so formuliert habe, hat noch kein Arbeitgeber abgelehnt. Es liegt vollständig im Interesse des Unternehmens; man muss nur helfen, das sichtbar zu machen.

    • Ich bedaure meine Entlassung aus meinem früheren Job aus vielen Gründen, und einer der großen war, dass wir gerade darüber diskutierten, ob wir eine ziemlich große Änderung, die ich an der Kafka Streams-Bibliothek gemacht hatte, als Open Source veröffentlichen sollten.
      Ich hatte große Teile neu geschrieben, dabei die API größtenteils kompatibel gehalten und den Schwerpunkt auf nicht blockierendes I/O gelegt, sodass man bei Bedarf Backpressure-Semantik nutzen konnte. Das ermöglichte interessante Dinge, weil man State Stores sowie blockierendes und nicht blockierendes I/O mischen konnte und trotzdem eine ordentliche Performance behielt; ich war besonders stolz darauf, weil das Projekt an vielen unauffälligen Stellen Performance herausgeholt hat.
      Ich habe darauf gedrängt, es auf GitHub zu veröffentlichen oder einen PR an das Upstream-Kafka-Streams-Projekt schicken zu dürfen, aber davor kam eine Entlassungswelle, und danach gab es keinen Champion mehr, der das intern vorangetrieben hätte, sodass es als proprietärer Code eingeschlossen blieb.
      Ich denke noch immer darüber nach, es von Grund auf neu zu bauen und als freie Open Source zu veröffentlichen. Es ist schon einige Zeit vergangen, daher dürfte es kein Problem sein, es neu zu schreiben und zu veröffentlichen, und es gab auch keine Patente oder Ähnliches; außerdem gibt es Dinge, die ich ändern würde, etwa die Vert.x-Abhängigkeit zu entfernen. Vielleicht mache ich das irgendwann, wenn ich mal eine Woche freihabe.
    • Ich vermisse die Zeit, als ich an Orten gearbeitet habe, die so etwas erlaubt haben.
      Manche Unternehmen verheddern sich schon allein in ihren Prozessen zur Prüfung durch die Rechtsabteilung.
      Einmal habe ich um Erlaubnis gebeten, einen Patch an ein Projekt schicken zu dürfen, und daraus entstand ein interessanter E-Mail-Thread. Am Ende lief die Frage auf eines hinaus: Wenn der Patch in gegenüber dem Kunden abrechenbarer Zeit geschrieben wurde, um einen Bug in einem ausgelieferten Produkt zu beheben, wenn die gepatchte Bibliothek neu kompiliert und zusammen mit dem Quellcode ausgeliefert werden muss und wenn im Vertrag steht, dass alle mit dem Produkt zusammenhängenden Arbeitsergebnisse und geistigen Eigentumsrechte auf den Kunden übergehen, haben wir dann überhaupt das Recht, diesen Patch als Public Domain zu veröffentlichen?
      Die Rechtsabteilung wollte darauf nicht antworten.
    • Insgesamt ist das ein guter Ansatz und ein hervorragendes Beispiel dafür, Arbeit professionell zu framen. Das eigentliche Kernproblem löst er aber nicht. Gerade bei technisch geprägten Unternehmen sollte die Führung diese Vorteile sofort verstehen; wenn nicht, ist das selbst schon ein Problem.
      Wie man überhaupt an die Sache herangehen kann, hängt auch stark vom Glück mit dem Arbeitgeber ab.
    • „Okay, ich gebe das mal an das Compliance-Team weiter. Wir wollen nur sicherstellen, dass keine Verletzung geistigen Eigentums vorliegt. Welches Repository und welches Issue genau sind das?“

  • Zu der Aussage „und stelle sicher, dass du das veröffentlichte Open-Source-geistige Eigentum auch wirklich besitzt“: In den Rechtsräumen, in denen ich gearbeitet habe, gehörte Code, der während der Arbeitszeit geschrieben und veröffentlicht wurde, nicht mir, sondern meinem Arbeitgeber.
    Ich konnte nicht allein entscheiden, in der Arbeitszeit beizutragen, und wenn ich an Open-Source-Code arbeiten wollte, brauchte ich eine formelle Vereinbarung. Jedes Mal dauerte der Weg durch die Rechtsabteilung Monate, sodass ich es am Ende aufgab oder in der Zwischenzeit schon ein anderer Beitragender den PR eingereicht hatte und ich gar nicht mehr fragte.

    • Gemeint war vermutlich eher: „Man sollte keine Arbeitsergebnisse spenden, die einem nicht gehören.“ Dazu gibt es weiter unten zwar einen eigenen Abschnitt, aber nur mit dem oberen Bulletpoint ist es verwirrend.
      Für erfahrene Entwickler ist das selbstverständlich, aber bei Junior-Entwicklern in manchen Unternehmen war das tatsächlich ein reales Problem. Wenn das Unternehmen in einem internen Projekt etwas Cooles macht, denken manche, es wäre doch toll, das zu einem Open-Source-Projekt beizusteuern, und berücksichtigen dabei nicht, dass sie mit Wissen aus proprietärem Code im Grunde sehr ähnlichen Code einreichen oder manchmal sogar Code kopieren und einfügen.
    • Ich habe es nicht selbst recherchiert, aber ich dachte immer, dass in Deutschland grundsätzlich aller Quellcode, der in der Arbeitszeit entsteht, dem Arbeitgeber gehört.
      Die meisten Arbeitgeber, die keinen IT-Schwerpunkt haben, verstehen vermutlich nicht einmal, was Open Source ist oder wie es funktioniert. Deshalb kann es hoffnungslos sein, sich von vielen Leuten eine Erlaubnis holen zu müssen.
      Die verlinkte Seite sollte sich besser zunächst darauf konzentrieren, Arbeitgebern die Vorteile von Open Source zu erklären und rechtliche Leitlinien für Arbeitgeber zu propagieren.
    • Wenn ein Unternehmen Dinge, die nicht in die Produktion gehen, nicht unter einer permissiven Lizenz veröffentlichen lässt, würde ich dort wohl nicht arbeiten wollen. Für mich wäre das demotivierend und würde mich mental an meine Grenzen bringen. Dann wäre ich lieber arm.

  • Gute Idee, sogar eine großartige Idee, aber ich weiß nicht, ob es gut ist, das als Widerstand zu positionieren.
    Der Zweck eines Jobs ist normalerweise, ein bestimmtes Ziel zu erreichen. Wie dieses Ziel erreicht wird, sollten die Entwickler als Fachleute entscheiden können. Wenn zu dieser Entscheidung Open-Source-Software gehört, dann sollte auch ihre Wartung Teil dieser Entscheidung sein.
    Das ist nichts Radikales, sondern einfach nur die eigene Arbeit zu machen und dabei die Zukunftssicherheit und Wartbarkeit dessen zu schützen, wovon die Arbeit abhängt.

    • Das ist einfach auch guter Geschäftssinn. Unternehmen, die Zusammenarbeit über Open Source fördern, stärken damit das Ökosystem, das ihr eigenes Geschäft trägt.
    • Ich stimme allem Gesagten zu, aber die Realität in den meisten Tech-Unternehmen heute sieht meiner Erfahrung nach anders aus. Sie investieren nicht einmal Zeit in die Wartung ihrer eigenen Infrastruktur und Bibliotheken, solange es nicht erzwungen wird, geschweige denn in Open Source.
      Nutzlose Features für Metrik-Spielchen, Enshittification, Dark Patterns und modische Integrationen, die fast an Malware grenzen, bekommen Vorrang vor Investitionen in Basisinfrastruktur oder Bibliotheken.
    • Stimme zu. So eine Beschreibung lässt es so wirken, als wolle jemand in sozialen Medien einfach mehr Aufmerksamkeit bekommen. Schade, dass wir an einem Punkt angekommen sind, an dem alles überzogen werden muss.

  • Im Allgemeinen stimme ich völlig zu, aber ich glaube, in der Praxis ist es schwer umzusetzen. Ich bin kein Anwalt, aber meines Wissens besitzt normalerweise der Arbeitgeber das geistige Eigentum, daher braucht man eine ausdrückliche Erlaubnis, um etwas als Open Source zu veröffentlichen.
    Und der Prozess, diese Erlaubnis zu bekommen, ist oft schwierig und führt durch endlose Verfahren und die Rechtsabteilung.
    „In den USA, im Vereinigten Königreich und in mehreren anderen Rechtsordnungen gilt: Wenn ein Arbeitnehmer im Rahmen seiner Tätigkeit ein Werk schafft, wird der Arbeitgeber als gesetzlicher Urheber oder erster Rechteinhaber angesehen.“
    https://en.wikipedia.org/wiki/Work_for_hire
    Trotzdem finde ich, dass Open-Source-Arbeit, also Wartung und Entwicklung, von bezahlten Fachleuten erledigt werden sollte und nicht von Freiwilligen, die um Spenden betteln. Die Kernfrage ist, wie man das umsetzt und wie man Unternehmen dazu bringt, Open-Source-Beiträge als Standardpraxis zu akzeptieren statt als Ausnahme, die individuell ausgehandelt werden muss.

    • Die beschriebenen Probleme sind weniger „praktische Probleme“ als eher theoretische.
      In der Praxis macht man es einfach. Es gibt im Computer keine Subroutine, die git push verhindert. Tatsächlich schreiben Arbeitgeber alle möglichen Dinge in Arbeitsverträge. Sie schreiben so viel wie möglich hinein, um sich in jede Richtung abzusichern. Wenn sie einfach hineinschreiben können, was sie wollen, warum sollten wir es dann nicht einfach tun können? Nichts davon ist wirklich wichtig.
      Tatsächlich gibt es fast null Open-Source-Projekte, die aus solchen technischen Gründen wegen geistigen Eigentums angegriffen wurden.
    • Es stimmt, dass der Arbeitgeber die Rechte am geistigen Eigentum hat, wenn die Arbeit mit deiner Tätigkeit zu tun hat.
      Wenn sie nichts mit deiner Tätigkeit zu tun hat, ist es je nach Bundesstaat unterschiedlich. In vielen Bundesstaaten gibt es Grenzen dafür, was ein Arbeitgeber als sein geistiges Eigentum beanspruchen kann. Standardverträge formulieren das oft sehr weit, um alles zu beanspruchen, aber das Gesetz sagt häufig, dass das Unternehmen sich freie Zeit-Arbeiten ohne Bezug zum Arbeitgeber nicht aneignen kann.
      Wenn man es während der Arbeitszeit macht oder den Firmenlaptop benutzt, schafft das für die Firma Spielraum, Ansprüche zu erheben. Die meisten Unternehmen wird es nicht kümmern, aber wenn es zum Streit kommt, sollte man nicht nachlässig sein, wenn man die Sache sauber halten will.
      Arbeite in deiner Freizeit und auf deiner eigenen Hardware, und achte darauf, dass es keine Überschneidungen mit deiner angestellten Tätigkeit oder Dingen gibt, mit denen du bei der Firma in Berührung gekommen bist.
    • Ich bin kein Anwalt, aber wenn du einem Kollegen eine Kopie gegeben hast, damit er es ausführen kann, hast du dann nicht schon dadurch eine Open-Source-Lizenz verwendet? Der Kollege hätte damit doch die rechtlichen Rechte, die ihm die Lizenz einräumt, und damit auch das Recht, Änderungen weiterzuverbreiten, oder nicht?
      Änderungen Upstream zu bringen ist die beste Methode, um Wartbarkeit sicherzustellen, und das Ganze wirkt sehr absurd. Dasselbe gilt für die rechtliche Unsicherheit, die mit der Pflege interner proprietärer Forks einhergeht.
    • Der Artikel scheint vorzuschlagen, dem Weg des geringsten Widerstands zu folgen. Also in der Arbeitszeit daran zu arbeiten und kein großes Aufheben darum zu machen. Wenn man erwischt wird, bittet man eben um Verzeihung. Aus Sicht des Unternehmens ist Verzeihen der einfachere Weg. Holt man Anwälte dazu, wird es sehr teuer und könnte zu einem PR-Albtraum werden.
    • Wenn der aktuelle Zustand des Programmierens eines gezeigt hat, dann dass geistiges Eigentum und Urheberrecht faktisch nicht mehr existieren.

  • Ich arbeite in einem ziemlich großen Unternehmen. Unsere Open-Source-Richtlinie lässt sich ungefähr so zusammenfassen: „Frag zuerst deinen Manager, tu es nicht im Namen des Unternehmens und gib keine vertraulichen Informationen preis.“
    Das war nie ein Problem, und im Großen und Ganzen wirkt es völlig vernünftig.

  • Ich finde es unproblematisch, in der Arbeitszeit zu einem Open-Source-Projekt eines Dritten beizutragen, etwa mit Bugfixes, aber bei eigenem Open Source weiß ich nicht, wie man damit umgehen sollte.
    Angenommen, man hat privat eine kleine Bibliothek gebaut, die dann in der Firma verwendet wird, und während der Arbeitszeit entdeckt man einen Bug darin. Wenn man dann in dieser Arbeitszeit dazu beiträgt, scheint das eine Grauzone zu sein.
    Hat jemand so etwas schon in Bewerbungsgesprächen verhandelt? Mich würde interessieren, wie das gelaufen ist.

    • Ich habe tatsächlich noch nie bei einer Firma gearbeitet, die sich darum geschert hätte. Ich habe einfach getan, was nötig war. Selbst wenn ich gefragt habe, wie man es „richtig“ machen soll, habe ich nie eine Antwort bekommen.

  • Als ich in einem Großkonzern gearbeitet habe, war es meistens so, dass auf Anfragen für Arbeiten außerhalb des direkten Schreibens von Code in der Firmen-Codebasis selbst mein direkter Vorgesetzter trotz Begründung nur mit „Mach das in deiner Freizeit“ geantwortet hat.
    In einer profitorientierten Umgebung gilt nur das als verfolgbar, was sofortigen Wert liefert. Diese Haltung ist ziemlich parasitär, und der Druck zu immer höherer Effizienz und Konkurrenz über Kennzahlen von oben erzeugt genau das.

  • Ich habe definitiv schon für die Lösung eines Problems im Job einen Fork angelegt, ihn repariert und das Ergebnis dann als PR Upstream geschickt.
    Das ist einer der guten Aspekte daran, Open Source zu nutzen und darauf zugreifen zu können. Genau deshalb ist git in package.json und cargo.toml fast eine erstklassige Option: weil man direkt auf den Fork zeigen kann, bis die Änderung Upstream angekommen ist.

  • Wenn man senior wird und im Bewerbungsgespräch an den Punkt kommt: „Haben Sie Fragen an uns?“, dann frage ich: „Wie steht dieses Unternehmen dazu, dass ich einen Teil meiner Zeit zu den Open-Source-Projekten beitrage, von denen es abhängt?“
    An der Antwort kann man dann entscheiden, ob man weitermachen will oder nicht.