Beiträge zu Free/Libre Open Source Software, Teil 1 Wie nimmt man an FLOSS-Projekten teil?

Anbieter zum Thema

Vogel IT-Akademie

OutSystems

Wer Praxiserfahrung im Programmieren sammeln möchte, findet in freien und Open-Source-Projekten eine gute Anlaufstelle. Ob gelernter Software-Entwicklung oder blutiger Anfänger – es ist für jeden Skill-Level etwas dabei, aber mit ein paar Regeln.

Der Einstieg in die Karriere als Entwickler läuft auf vielfältigen Wegen immer in dieselbe Richtung: Das Interesse an Technik wird geweckt, der Wunsch nach Anpassung und Verständnis erwächst und wird irgendwann stark genug, um sich mit der sperrigen Materie rund um Code, Algorithmen und komplexe Tool-Welten zu beschäftigen.

Etwas später sitzen dann die ersten Programmier-Skills, sei es durch eine Ausbildung, nebenher im Informatikstudium oder schlicht privat als Hobby. Und genau dann ist der Schwenk in die Praxis oft nicht ganz einfach. Eigene Tools sind nicht trivial, wenn sie über Demo-Anwendungen hinaus gehen sollen, und zudem ist Entwicklung – vor allem als Beruf – ein Teamsport! Einer, der über das reine Coding hinaus geht.

Open-Source-Projekte eignen sich hervorragend, um einen Fuß in die Tür zu bekommen. Oder um es im Kontext zu sagen: Ein Contributor zu werden, der sich schwerlich zum Beitragenden übersetzen lässt. Im Folgenden zeigen wir einige Möglichkeiten für Beiträge – auch abseits des Codings –, Tipps zum Auffinden passender Projekte und Einstiege sowie letztlich zum technischen Ablauf.

Möglichkeiten für Beiträge

Es ist immer eine Frage, wie genau Projekte organisiert, wie groß und gereift sie sind. Grundsätzlich gibt es aber folgende Optionen für Beiträge:

Dokumentation

Okay, Entwickler hassen Dokumentation, sei es im Code oder als Benutzerhandbuch. Aber gerade deshalb ist es immer wieder ein guter Einstiegspunkt, gerade, wenn das Coding noch nicht so sicher sitzt. Und man sollte es auch nicht unterschätzen: Gute Doku zieht Nutzer an und größere Projekte ziehen immer mehr Entwickler an – zudem werden Coder entlastet.

Ein netter und nützlicher Nebeneffekt ist, dass man das Projekt wirklich gut kennenlernt. Das kommt auch eventuellen späteren Feature-Ideen und eigenen Code-Beiträgen zu Gute – manch ein Entwickler kennt nur seinen Teil der Software, einzelne Funktionen, aber nicht das große Ganze!

Übersetzung

Noch einfacher ist die Mitarbeit an Übersetzungen, hier genügen schon Fremdsprachenkenntnisse. Englisch ist in aller Regel die (Ausgangs-)Sprache einer Software, aber auch der Entwickler untereinander und natürlich die Basis für Übersetzungen.

Community

Community Manager sind traditionell überdurchschnittlich häufig weiblich, da hier – Vorsicht Klischee! – weniger technische als soziale Fähigkeiten benötigt werden, wie Kommunikation, Vermittlung, Organisation und so weiter. Die Arbeit als Foren-Admin oder dergleichen bringt eine Menge Einblicke in das Projekt, die Technik, die Nutzerschaft und eignet sich hervorragend, um sich einen Namen zu machen – und auch diesen Aspekt sollte man nicht unterschätzen, wenn das Ganze einer Karriere als Entwickler dienen soll.

Qualitätskontrolle

Das Stichwort hier ist „Issues”. Der erste Schritt in Richtung Code-Beiträge könnte die Sichtung des Codes sein, und natürlich auch des laufenden Programms selbst. Alles, was hier an Fehlern, verbesserungswürdigen Features und auch fehlenden Kleinigkeiten auffällt, lässt sich wunderbar simpel berichten und meist in Form eines Issues ans Projekt weiterleiten.

Das mag zunächst kontraproduktiv klingen, einfach „nur” mögliche Fehler aufzuzeigen. Aber genau das macht Open Source so erfolgreich: Dank offenem Code schauen möglichst viele Augen darüber und lassen auf Dauer, zumindest in der Theorie, keine Schwachstelle unentdeckt – festgehalten in Eric S. Raymonds berühmten Zitat „Given enough eyeballs, all bugs are shallow.”, auch bekannt als Linus' Law, benannt nach Linus Torvalds.

Fixes, Patches, Code

Für angehende Entwickler dürfte das die Königsdisziplin sein – endlich Programmieren! Anfangs kann das direkt an den obigen Punkt anschließen: Statt einfach „nur” Fehler zu berichten, können auch gleich Lösungen eingereicht werden. Und selbst hier können schon Einsteiger helfen.

Es muss nicht immer gleich ein kompletter Rewrite uneleganter Funktionen sein. Irgendwo fehlt ein Anführungszeichen? Oder eine Exception für eine möglicherweise falsche Nutzerinteraktion? Falsch formatierte Kommentare? Solche kleinen Bugfixes basieren nicht selten auf Fleißarbeit – sicherlich auch nicht die Lieblingsdisziplin erfahrener Entwickler.

Features, Vorschläge

Sehr projektabhängig sind weitergehende Möglichkeiten. Einige Projekte ermuntern potenzielle Contributors auch komplette Vorschläge für neue Features einzureichen. Das können ein paar nette Worte, detaillierte Konzepte oder gar ausprogrammierte Funktionen sein. Das ist für Außenstehende freilich nicht immer und überall möglich und gerade für Anfänger eher uninteressant.

„Mund“propaganda

Der Vollständigkeit halber: Der Open-Source-typische Aufruf „Spread the Word” ist natürlich die simpelste aller Möglichkeiten, etwas zur FLOSS-Szene beizutragen – vom simplen Teilen einer Social-Media-Nachricht bis hin zum eigenen Blog. Als Einstieg in Projekte und Szene ist das aber nur bedingt tauglich – andererseits kann ein guter Code-Blog der Karriere durchaus förderlich sein!

Wo anfangen?

Alles gute Ratschläge, aber wo fängt man an? Am besten ist es immer, mit einem Projekt anzufangen, an dem oder mit dem man sowieso arbeitet – und zum Beispiel irgendwann feststellt, dass einem diese oder jene Option fehlt. Wenn es aber gezielt darum geht Praxis zu sammeln und schlicht um der Entwicklung willen irgendwo mitzuarbeiten, wird es schwieriger.

Große, gereifte Projekte bieten oft mehr Einstiegsmöglichkeiten und auch geregelten Zugang. Andererseits sind die Ansprüche gerne mal hoch, die Communities uneins, Vorgehensweisen festgefahren und so weiter. Es ist einfach schwierig, zügig auch kleine Erfolge einzufahren. Auch bei Miniprojekten, die nur von einer einzigen Person oder vielleicht zwei, drei Freunden oder Kollegen betrieben werden, ist der Zugang nicht einfach, sofern überhaupt gewollt.

Es lohnt sich, hier ein wenig Zeit in Recherche zu investieren: Welches Projekt nutzt eine Programmiersprache, die ich halbwegs beherrsche? Wird um Mitarbeit geworben? Wie ist der Tonfall? Tonfall? Ja, das ist schon richtig: Schauen Sie bei relevanten Projekten ruhig mal in die Foren oder Issues- und Bug-Listen – wenn nett gemeinte Anregungen von Nutzern gleich mit „Lern erstmal C++” abgewatscht werden, muss man so ein Verhalten auch als Mitentwickler befürchten.

Versuchen Sie einmal, an der Übersetzung eines Programms ins Deutsche mitzuhelfen – die erste Diskussion und Rückgängigmachung Ihrer Änderungen wird kaum lange auf sich warten lassen. „Du oder Sie”, „klickte oder hat geklickt” – die eigene Erfahrung hat gezeigt: Man kann hier viel Zeit verschwenden.

Ähnlich wie bei Wikipedia-Artikeln haben viele Mitarbeiter (leider) ein arg persönliches Verhältnis zu Codezeilen, Features oder ganzen Repos. Einsteiger sollten sich ein freundliches Projekt suchen! Gutes Zeichen dafür: Einsteiger werden explizit aufgefordert mitzuarbeiten.

Vor dem ersten Beitrag

Wenn sich aber nicht ein generisches „freundliches” Projekt als persönliches Testobjekt anbietet, sondern eines, das den eigenen Fähigkeiten oder schlicht der eigenen Nutzung entgegenkommt, sollte man dennoch nicht einfach Issues und Bug-Fixes posten.

Viele Projekte haben einen „Code of Conduct” und Code-Richtlinien, die Verhalten, Workflows, Coding-Stil und so weiter umreißen oder auch detailliert festlegen. Und wie in Foren bei „dummen” Fragen häufig ein unfreundliches „RTFM!” statt einer Antwort folgt, folgt auf falsch formatierte Bug-Fixes auch gerne mal ein Hinweis auf irgendwelche Richtlinien.

Beschäftigen Sie sich vorab mit dem Code, der Community und den Entwicklern – das kann jede Menge Frust ersparen, auf beiden Seiten. Bedenken Sie: Ein neuer Arbeitgeber würde Ihnen vermutlich auch ein paar Tage Einarbeitung angedeihen lassen, um sich mit der Unternehmenskultur vertraut zu machen.

Technischer Ablauf

Gut, das Projekt ist gefunden und Sie wollen sich beteiligen – wie geht es weiter? In aller Regel sind Open-Source-Projekte heute bei GitHub organisiert. Oder bei sehr ähnlich funktionierender Konkurrenz wie GitLab oder BitBucket. Aber GitHub ist gewissermaßen der Standard.

Und hier sind zwei Tools wichtig: Pull Requests und Issues. Die Issues sind letztlich schlicht eine Liste mit Vorschlägen, gefundenen Fehlern, Aufgaben und so weiter. Wie genau die Issues genutzt werden sollen, legt ein Projekt bestenfalls irgendwo in einer Readme fest – meist bleibt das aber komplett offen. Im Grunde ist es nur ein typisches Kommentarformular, bestenfalls mit anschließender Diskussion.

Pull Requests sind aber der eigentliche Zugang zum Code. Es gibt hier viele Workflows, aber ganz grundsätzlich und standardmäßig kann man auf GitHub diesem Workflow folgen:

• Repository klonen

• Persönlichen Branch für eine (!) Änderung anlegen

• Änderung im Branch committen und pushen

• Pull Request für den Commit im Original-Repository anlegen

Auch die Pull Requests lassen sich über ein simples Formular im Browser erstellen, einfach über Angabe des Commit-Hashs. Pull Request ist dabei wörtlich zu nehmen: Sie stellen die Anfrage, einen Commit ins (Original-)Repository zu pullen (git pull). Die Repo-Admins können dann, gegebenenfalls nach internen Review-Workflows, Ihren Commit einfließen lassen/pullen, oder eben auch nicht.

Eben diese Pull Requests sind die übliche Art und Weise, mit eigenen Beiträgen in ein Projekt einzusteigen. Dokumentations- und vor allem Übersetzungsarbeiten werden allerdings auch gerne mal abseits von Git/GitHub mit spezialisierten Plattformen durchgeführt – das macht die Mitarbeit aber eher noch ein wenig einfacher.

Und wenn Sie jetzt Blut geleckt und möglichst sofort mit dem Beitragen anfangen wollen: GitHub selbst liefert mit Listen sehr gute Ansatzpunkte. Projekte, die Hilfe benötigen, Issues für Einsteiger oder Issues und Code, die mit „beginner-friendly” markiert sind – dafür bietet GitHub nämlich ein umfangreiches Flagging-System.

(ID:47043211)