Ein Beitrag zu einem Projekt, das Sie nicht selbst besitzen, liest sich im Lebenslauf dann als glaubwürdige Arbeit, wenn der Eintrag genau benennt, was Sie tatsächlich beigetragen haben: ein konkreter Pull Request, der gemerged wurde, ein Fehler, den Sie aufgespürt und behoben haben, ein Review, das die Änderung einer anderen Person mitgeprägt hat, oder eine Maintainer-Rolle, die Sie im Projekt innehaben, statt nur ein Repository-Name neben einem Link. Open-Source-Arbeit unterscheidet sich von einem selbst gebauten Projekt in einem wichtigen Punkt: Ihr Name steht in der Commit-Historie neben den Namen anderer Beitragender, in einem Projekt, das schon eigene Maintainer hatte, bevor Sie dazukamen, und das auch nach Ihrer Änderung weiterlief. Der Eintrag muss deshalb Ihren konkreten Anteil präzise benennen, statt den Eindruck zu erwecken, Sie hätten das gesamte Projekt verantwortet.
Warum ein Open-Source-Eintrag anders formuliert werden muss als ein eigenes Projekt
Für ein Projekt, das Sie selbst gebaut haben und vollständig kontrollieren, beschreibt Nebenprojekte im Lebenslauf eines Softwareentwicklers präsentieren, was es tut, womit Sie es gebaut haben und was sich dadurch verändert hat. Ein Open-Source-Beitrag stellt zunächst eine andere Frage, nicht was das Projekt tut, denn das lässt sich bei einem bekannten Projekt meist in Sekunden nachschlagen, sondern was Sie konkret innerhalb eines Projekts beigetragen haben, das bereits existierte und bereits eine eigene Richtung hatte. Eine vage Zeile neben dem Namen eines bekannten Projekts, ohne jede Beschreibung Ihrer tatsächlichen Beteiligung, kann wie der Versuch wirken, sich das Ansehen dieses Projekts zu leihen, statt echte Arbeit zu beschreiben, was genau das Gegenteil dessen ist, was der Eintrag erreichen soll.
Welche Beitragsarten sich konkret nennen lassen
Ein gemergter Pull Request ist die klarste Einheit eines Beitrags, und was er verändert hat, zu nennen ist wichtiger, als nur seine Existenz zu erwähnen: eine konkrete Fehlerbehebung, ein neues Feature, eine Performance-Verbesserung oder ein Stück fehlende Dokumentation. Code-Reviews sind echte, wertvolle Arbeit an einem aktiven Projekt und verdienen eine eigene Zeile, getrennt von den eigenen gemergten Änderungen, wenn Sie genug davon geleistet haben, damit es zählt, besonders bei einem Projekt, bei dem Review-Qualität Teil dessen ist, wie Maintainer das Ansehen eines Beitragenden beurteilen. Eine Maintainer- oder Triage-Rolle, bei der Sie Commit-Zugriff haben, die Pull Requests anderer reviewen oder Issues für ein Projekt verwalten, verdient eine eigene Zeile statt in einer allgemeinen Erwähnung als "Contributor" unterzugehen, denn sie sagt etwas aus, was ein einzelner gemergter Fix nicht sagt: dass andere Maintainer Ihrem Urteil dauerhaft vertrauen. Wiederkehrende Beiträge zum selben Projekt über mehrere Monate lohnt es sich ebenfalls als Muster zu beschreiben, statt nur die eindrucksvollste einzelne gemergte Änderung zu nennen, denn ein Muster wirkt als anhaltendes Engagement, nicht als einmalige Aktion.
Anschauliches Beispiel: eine Zeile für einen Open-Source-Beitrag
Anschauliches Beispiel, von vage zu konkret. Vage: "Contributor, Open-Source-Projekt (github.com/example/project)." Konkret: "Contributor, ein Open-Source-Kommandozeilen-Tool für lokale Entwicklungsumgebungen. Behob einen Fehler, der das Tool bei großen Konfigurationsdateien hängen ließ, und reviewte über sechs Monate mehrere Pull Requests anderer Beitragender im selben Repository." Die konkrete Version benennt in einer Klausel den Zweck des Projekts, sagt genau, was die gemergte Änderung tatsächlich behoben hat, und trennt die Review-Arbeit von der Fehlerbehebung, statt den Eindruck zu erwecken, die ganze Zeile beschreibe einen einzigen Beitrag.
Gemeinsame Arbeit würdigen, ohne sich mehr zuzuschreiben
Fast jede gemergte Änderung an einem aktiven Open-Source-Projekt hat üblicherweise ein Review durch jemand anderen durchlaufen, bevor sie eingespielt wurde, und ein Lebenslaufeintrag, der die alleinige Autorenschaft eines Features suggeriert, das tatsächlich mehrere Maintainer gemeinsam geprägt haben, wirkt in dem Moment übertrieben, in dem jemand die Commit-Historie prüft, was bei einem öffentlichen Repository nur Sekunden dauert. Den eigenen konkreten Beitrag zu benennen, einen Fix, ein Feature, einen Bereich, den Sie regelmäßig reviewen, statt die gesamte Funktionalität des Projekts so zu beschreiben, als hätten Sie es im Alleingang gebaut, hält den Eintrag sowohl ehrlich als auch, in den meisten Fällen, konkreter und glaubwürdiger als eine breitere Behauptung. Wo sich mehrere Ihrer Beiträge um einen Bereich eines Projekts konzentrieren, etwa dessen Build-Werkzeuge oder Testsuite, ist es für den Leser oft aussagekräftiger, diesen Bereich zu benennen, als mehrere kleine Pull Requests einzeln aufzulisten.
Worin sich das von einem eigenen Projekt unterscheidet
Ein selbst von Grund auf gebautes Nebenprojekt verdient eine Zeile, die seinen Zweck und sein Ergebnis beschreibt, weil Sie jede Entscheidung darüber getroffen haben, was es tut und wie. Ein Open-Source-Beitrag verdient eine Zeile, die Ihren konkreten Anteil innerhalb der Entscheidungen anderer beschreibt, denn die Gesamtausrichtung, die Architektur und der Umfang des Projekts wurden meist schon vor Ihrem Einstieg festgelegt. Beides ist legitime technische Arbeit, die einen Platz im Lebenslauf verdient, aber beides zu vermischen, einen Open-Source-Beitrag so zu beschreiben, wie Sie Ihr eigenes Projekt beschreiben würden, überzeichnet tendenziell entweder Ihre Rolle im gemeinsamen Projekt oder untertreibt die konkrete Arbeit, die Sie tatsächlich geleistet haben.
Wo er im Lebenslauf hingehört
Ein bedeutender einzelner Open-Source-Beitrag oder eine über die Zeit gehaltene Maintainer-Rolle verdient meist eine eigene Zeile innerhalb eines Projektabschnitts neben persönlichen Projekten, da beide technische Arbeit außerhalb einer bezahlten Stelle beschreiben. Mehrere kleinere Beiträge zu verschiedenen Projekten lassen sich oft besser unter einer Überschrift bündeln, etwa "Open-Source-Beiträge", wobei jedes Projekt kurz genannt wird, statt vier dünnen, fast identischen Zeilen dasselbe visuelle Gewicht wie einem einzelnen, gut beschriebenen Eintrag zu geben. Das Developer-Template ist mit einem Projektbereich neben dem Werdegang aufgebaut, was zu dieser Art Eintrag passt, egal ob er aus einer Stelle entstanden ist oder vollständig für sich steht.
Zum Lebenslauf hinzufügen
Ein konkret beschriebener und ehrlich zugeschriebener Open-Source-Beitrag ist ein echter Beleg für technisches Urteilsvermögen, den ein Leser oft direkt nachprüfen kann. Starten Sie mit einem für technische Arbeit gebauten Template und fügen Sie Ihre Beiträge im Editor hinzu, wo Sie die Formulierung immer weiter verfeinern können, sobald neue Beiträge dazukommen.