Open Source: Es ist nicht so beängstigend!

Das Folgende wurde vor dem Start von Toptal-Stipendien für weibliche Entwickler veröffentlicht.

Als Entwickler ist es aufregend und herausfordernd, mit den neuesten Technologietrends Schritt zu halten. Jeden Tag ziehen neue Sprachen, Frameworks und Geräte unsere Aufmerksamkeit auf sich und regen Gespräche in Meetups, Foren und Chats an. Unsere Entwicklergemeinschaft besteht jedoch aus Menschen, nicht aus Werkzeugen, und es ist faszinierend, ihre gesellschaftspolitischen Aspekte zu untersuchen (in Ermangelung eines besseren Wortes; „sozial“ wird heutzutage eher mit sozialen Netzwerken in Verbindung gebracht).

Bei Toptal hatten wir kürzlich einige interessante Gespräche darüber, wie viel Frauen zu Open Source beitragen und was sie möglicherweise daran hindert, mehr beizutragen, also haben wir die Angelegenheit untersucht. Nachdem ich an diesem Gespräch mit Breanden Beneschott und Bozhidar Batsov teilgenommen hatte, fragte ich mich: Bozhidar ist einer der besten Open-Source-Beitragenden auf GitHub. Wo bin ich? Wenn Sie meinen öffentlichen GitHub-Account mit Stand heute überprüfen, sind es hauptsächlich kleine Testprojekte, die ich im Unterricht für meine Schüler verwendet habe. Sie sind unausgereift und definitiv nicht repräsentativ für meine Fähigkeiten oder mein Fachwissen. (Da müssen Sie sich auf mein Wort verlassen.) Wenn jemand erwägen würde, mich einzustellen, basierend auf dem, was er in diesem Konto findet, würde ich es wohl schwer haben, meinen Lebensunterhalt zu verdienen. Dennoch bin ich seit mehr als 20 Jahren professioneller Entwickler, und in meiner täglichen Arbeit verwende ich mehr Open-Source-Software, als ich mich erinnern möchte. Im Laufe der Zeit habe ich den Linux-Kernel gehackt, um ihn an bestimmte Bedürfnisse anzupassen, jeden Router und jedes NAS, das ich gekauft habe, optimiert, geduldig monatelang auf der Warteliste für den Raspberry Pi gewartet, um ihn in die Hände zu bekommen und meine selbstgebaute Domotik zu bekommen Ich mag das. Trotzdem hat es keine dieser Optimierungen und Tests jemals auf meinen GitHub geschafft, um Open Source zu werden. Außerdem habe ich, abgesehen von der Behebung eines Fehlers in einer der ersten Versionen von Tomcat, nie zu einem Open-Source-Projekt beigetragen. Neugierig, nicht wahr?

Man könnte meinen, es läge nur an Zeit oder Interesse, aber ich weiß, dass dem nicht so ist. Was meine persönlichen Projekte betrifft, so dachte ich vielleicht, niemand könnte sich wirklich dafür interessieren, was ich getan habe, aber meistens macht mir der Gedanke, meine Arbeit dort zu veröffentlichen, für alle sichtbar und für die Nachwelt, große Angst. Und während Sie ein persönliches Projekt jederzeit von GitHub herunterreißen können, gibt es an dem Tag, an dem Sie versuchen, zu einem weit verbreiteten Open-Source-Projekt beizutragen, kein Zurück mehr. Was ist, wenn mein Code nicht gut genug ist? Was ist, wenn ich das Problem nicht richtig verstanden habe? Was ist, wenn meine Pull-Anforderung abgelehnt wird? Was ist, wenn Leute mich trollen?

Eine kurze Runde von Anrufen mit befreundeten Entwicklern, meist weiblichen, überzeugte mich bald, dass ich nicht der Einzige mit diesem Problem bin, aber für einen Ingenieur gibt es keine Probleme, nur Lösungen, richtig?

Dies ist ein wichtiges Problem, das es zu lösen gilt, denn ein Beitrag zu einem Open-Source-Projekt kann einen dramatischen Unterschied machen:

• Während Ihrer Karriere : Viele Kunden werden sich mit Ihren sozialen Aspekten befassen, bevor sie sich entscheiden, Sie einzustellen; Ihr GitHub-Konto und Ihr LinkedIn-Lebenslauf stehen zusammen mit Ihren Facebook- und Twitter-Profilen ganz oben auf der Liste. Du solltest sie mit Bedacht einsetzen.
• Für Ihre technischen Fähigkeiten : Das Untersuchen einer Codebasis, die von anderen Entwicklern geschrieben wurde, und oft von sehr guten, bringt Ihnen viel bei. Die Fähigkeit, die Bedeutung aus einer schlecht geschriebenen Codebasis herauszulösen, wird Sie ebenso herausfordern und lehren.
• Für Ihre Soft Skills : Open-Source-Software ist ein kollaborativer Prozess, und fast alle interessanten Projekte da draußen werden von Teams entwickelt. Zu lernen, mit anderen Entwicklern durch die Tools zusammenzuarbeiten, die jeder verwendet, sich in das Team einzufügen und effizient zu kommunizieren, macht Sie zu einem großartigen Entwickler, nicht nur zu einem erfahrenen.
• Für die Community : Jeder einzelne Beitrag zu einem Open-Source-Projekt zählt. Je mehr Sie beitragen, desto besser, aber selbst das Beheben eines kleinen Tippfehlers in einer Übersetzung wird das Endprodukt besser machen.
• Für Ihr Netzwerk : Sie können Hunderte von Lebensläufen an Unternehmen senden, aber nichts funktioniert so gut wie Kollegen mit persönlichen Verbindungen. Sich aktiv an einem Open-Source-Projekt zu beteiligen, stellt sicher, dass Sie Menschen treffen und ihren Respekt gewinnen, und Ihr Ruf wird wachsen, was für jeden Fachmann von unschätzbarem Wert ist.

Dies ist meine kleine persönliche Reise im Kampf gegen diese Angst. Die Veröffentlichung dieses Artikels ist Teil der Reise selbst. Ich schreibe es in der Hoffnung, dass jeder, der daran gehindert ist, einen Blogbeitrag zu schreiben, oder Angst hat, auch nur einen kleinen Beitrag zu leisten, sehen wird, dass es am Ende nicht so beängstigend war. Außerdem soll es jedem helfen, der gerne zu Open Source beitragen würde, aber nicht wirklich weiß, wo er anfangen soll, also werde ich mit den Grundlagen beginnen.

Was ist eine Open-Source-Software und wo finde ich sie?

Open-Source-Software oder kurz OSS ist jede Software, die mit ihrem Quellcode veröffentlicht wird und eine Lizenz enthält, die es Ihnen erlaubt, sie zu ändern und weiterzuverbreiten. Es kann überall zugestellt werden: auf einer Website, über eine Mailingliste oder mit einer Eule. Das häufigste Szenario und dasjenige, an dem wir interessiert sind, ist, wenn die Codebasis in einem kollaborativen Repository verwaltet wird. Hier konzentrieren wir uns auf GitHub, aber es gibt auch andere Optionen wie SourceForge und Bitbucket. GitHub ist sehr benutzerfreundlich, hat eine riesige Benutzerbasis, kann für jede Art von Code und mit jeder von Ihnen verwendeten Entwicklungsumgebung verwendet werden. Wichtig ist, dass es auch häufig für Nicht-Open-Source-Projekte verwendet wird. Die Chancen stehen gut, dass Ihr nächstes Kundenprojekt dort gehostet wird, daher ist es eine nützliche Fähigkeit, zu wissen, wie man damit arbeitet.

Was ist, wenn ich nicht weiß, wie man codiert?

Wenn Sie dies lesen, möchten Sie wahrscheinlich lernen, wie man codiert. Sie können erstaunliche Kurse auf mehreren kostenlosen und kostenpflichtigen Websites finden. Sie sollten eine Sprache zum Lernen auswählen; Wenn Sie keine Präferenz haben, verwenden Sie JavaScript. Sie haben bereits alles, was Sie brauchen, um mit Ihrem Webbrowser zu beginnen, und es ist eine der am weitesten verbreiteten und marktfähigsten Fähigkeiten. Mein persönlicher Favorit ist Python, das sowohl in der Webentwicklung als auch in wissenschaftlichen Anwendungen eingesetzt wird. Ich habe auch einen persönlichen Lieblingskurs für Anfänger, „Einführung in die Informatik“ auf Udacity. Ich mag es, weil es ein praktischer Kurs ist, bei dem Sie während des Lernens an einem Projekt arbeiten. Sie können auch mehrere andere Kurse auf Coursera, Khan Academy und PluralSight finden.

Was ist, wenn ich Git nicht kenne?

Wie bereits erwähnt, ist es wichtig, Git zu kennen, also nehmen Sie an einem Git-Kurs teil. Tun Sie es auch dann, wenn Sie schon eine Weile mit Git arbeiten; Sie wissen nicht, wie viel Sie nicht über Git wissen, bis Sie es wirklich studieren. Tun Sie es, wenn Sie nicht sicher erklären können, was der rebase Befehl tut. Tun Sie es auch dann, wenn Ihnen ein falscher Rebase keine Angst macht. Ich habe den vollständigen Git-Pfad in Code School genommen, aber auch hier können Sie andere Websites nach weiteren Optionen durchsuchen.

Wie wähle ich ein Projekt auf GitHub aus?

Es ist wahrscheinlich, dass Sie OSS in Ihrer täglichen Entwicklung verwenden. Die Wahl eines vertrauten Frameworks ist ein guter Ausgangspunkt; Sie sind bereits mit den Funktionen und der Funktionsweise des Frameworks vertraut. Wenn Sie in den Quellcode eintauchen, werden Sie mehr erfahren und seine Logik noch klarer verstehen. Wenn Ihnen eine Technologie oder ein Tool besonders gefällt, suchen Sie nach Projekten, in denen es erwähnt wird, oder nach dem Projekt des Tools selbst. Als letzten Ausweg können Sie die Projekte auf GitHub Showcases überprüfen und zunächst eine Kategorie auswählen, die Sie interessiert.

Beispielsweise zeigt eine schnelle Suche nach „Raspberry“ in der GitHub-Suche mehr als 17.000 Repositories. Es ist leicht, sich zu verlaufen, also suchen Sie nach einem Projekt mit einer guten Community und einer guten Problemverfolgung. Überprüfen Sie bei der Auswahl eines Projekts die Anzahl der:

• Mitwirkende : Zielen Sie auf alles ab, was über zehn Mitwirkenden liegt. Dies sollte sicherstellen, dass das Projekt auf genügend Interesse stößt und nicht nur eine kleine Teamleistung ist. Wenn Sie neu bei OSS oder nicht sehr erfahren sind, beschränken Sie Ihre Suche auf Projekte mit höchstens fünfzig Mitwirkenden; Größere Communities implizieren größere Codebasen und kompliziertere Projekte.
• Commits : Entscheiden Sie sich für Projekte, die mindestens tausend Commits haben und bei denen die letzte Aktivität nicht älter als eine Woche ist. Ein Projekt, das einen Monat oder länger inaktiv war, ist in OSS-Begriffen alt und veraltet, und Sie werden wahrscheinlich keine schnellen Antworten erhalten. Tägliche Aktivität ist das Zeichen für ein gesundes Projekt.
• Probleme : Probleme sind offene Probleme, gemeldete Fehler oder angeforderte Funktionen zur Implementierung. Sie geben Ihnen einen Ausgangspunkt und sind ein guter Maßstab für das Interesse an dem Projekt.

Finden Sie auch heraus, was die Hauptsprache des Projekts ist; Sie können die Sprachstatistik in der oberen Leiste der Hauptprojektseite sehen. Nehmen Sie sich etwas Zeit, um den Ton der Diskussion zu lesen, sehen Sie, wie freundlich und gebildet die Kommentare sind. Einige Projekte sind berüchtigt für ihre aggressiven Communitys, daher sind sie möglicherweise nicht der richtige Ausgangspunkt.

Ich habe mich für ScyllaDB, ein spaltenweises Datenspeicherprojekt, entschieden, da ich eine Faszination für Daten habe – alles, was mit der Leistung zusammenhängt. Ich habe noch nie damit gearbeitet, aber ich gehe davon aus, dass ich in die Codebasis eintauchen kann. Es mag einfacher sein, mit Tools zu arbeiten, die ich kenne, aber ich nehme dies als Herausforderung und Anlass, etwas Neues zu lernen. Für den Rest passt es perfekt zur Rechnung; Es hat 18 Mitwirkende, 6,5.000 Commits (der letzte lag zum Zeitpunkt des Schreibens vor 23 Stunden), 178 offene Probleme und scheint aktiv zu sein.

Was mache ich jetzt?

Klonen Sie zunächst das Repository und installieren Sie die Software auf Ihrem Computer, um sich ein Bild von den beweglichen Teilen zu machen. Beginnen Sie dann, die Ausgaben durchzulesen. Wenn Sie sich bereit fühlen, prüfen Sie, ob Sie das Problem auf Ihrem Computer reproduzieren können, und beginnen Sie dann mit der Analyse, was zu einem Fehlverhalten der Software führt.

Ein anderer Ansatz wäre, etwas zu finden, das Sie selbst verbessern oder ändern können. Vielleicht haben Sie zum Beispiel einen Tippfehler oder eine falsch ausgerichtete Schriftart bemerkt. Ich habe mich entschieden, einen kleinen Fehler zu beheben, insbesondere einen falschen Variablennamen, der in der Dokumentation eines Skripts verwendet wird.

Es scheint winzig, aber eine falsche Dokumentation ist viel schlimmer als keine Dokumentation. Benutzer werden ScyllaDB installieren und die Installationsschritte befolgen, sie werden sich blind auf das verlassen, was in diesem Skript geschrieben steht, und am Ende in haufenweise Frustration enden. Das war perfekt für meine Fähigkeiten, und um es zu beheben, muss ich den gesamten Prozess verfolgen und mich ein wenig mit der Codebasis vertraut machen. Bugfixing ist langweilig, aber es ist ein guter Anfang, um sich in ein Projekt einzufinden.

Fork erstellen

Das mag trivial sein, aber im Moment bin ich für das ScyllaDB-Projekt Frau Nobody; Es wäre riskant, mir zu erlauben, ohne Aufsicht Änderungen an ihrem Code vorzunehmen. Was ich tun muss, ist eine „Verzweigung“ in meinem eigenen GitHub-Konto zu erstellen. Hier ist mein ScyllaDB-Fork. Es ist meine eigene Spielwiese, auf der ich Zugriff auf den gesamten Code habe und die Dateien nach Belieben ändern kann. Wenn ich meine eigene Version von ScyllaDB erstellen und sie so optimieren wollte, dass sie etwas völlig anderes als ihren ursprünglichen Zweck tut, könnte ich dies hier tun. Das Erstellen eines Forks ist einfach; Gehen Sie zur Hauptseite des Projekts und klicken Sie auf die Schaltfläche „Fork“. Überhaupt nicht beängstigend.

Zeit, den Fehler zu beheben

Jetzt ist es an der Zeit, den Code auf Ihrem Computer zu testen und die erforderlichen Änderungen vorzunehmen. Stellen Sie zunächst sicher, dass Sie den Git-Client auf Ihrem Computer installiert haben. Fügen Sie dann Ihren öffentlichen SSH-Schlüssel zu GitHub hinzu und stellen Sie sicher, dass er von Ihrem SSH-Agent geladen wird. Den Code lokal zu bekommen ist einfach; Verwenden Sie anstelle des Hauptzweigs einfach den Befehl git clone , der auf Ihren Fork zeigt:

 git clone [email protected]:acbellini/scylla.git

Inzwischen sollten Sie das Projekt auf dem Hauptzweig getestet haben, also werden Sie Ihren Code lokal erstellen und auf die gleiche Weise testen. Denken Sie daran, dass Sie alle anderen GitHub-Projekte forken müssen, auf die Ihr Projekt angewiesen ist, da Verweise relativ sind. In meinem Fall musste ich seastar, scylla-ami und scylla-swagger-ui forken.

Der Fehler, den ich beheben muss, ist relativ einfach; Die Dokumentation in conf/scylla.yaml erwähnt drei konfigurierbare Verzeichnisse: Eines für Datendateien, eines für Commit-Protokolle und eines, anscheinend unbenutzt, für Caches, die alle standardmäßig auf ein Unterverzeichnis von $CASSANDRA_HOME :

Beim Eintauchen in den Code zeigt sich, dass die Standardeinstellungen unterschiedlich sind und, wie in Ausgabe Nr. 372 erwähnt, von der ich ausgegangen bin, $CASSANDRA_HOME nicht verwendet werden sollte. Ich validiere meine Hypothese, indem ich den Code mit ein paar verschiedenen Einstellungen teste, indem ich die Einstellung aus der Konfigurationsdatei entferne und überprüfe, welche Verzeichnisse verwendet werden. Sobald ich sicher genug bin, dass alles korrekt ist, kann ich die geänderte Datei hinzufügen, committen und pushen:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

Beachten Sie, dass ich die Issue-Nummer mit vorangestelltem Hash in die Commit-Nachricht eingefügt habe. Dadurch wird GitHub angewiesen, meinen Code automatisch mit dem Problem selbst zu verknüpfen.

Eine weitere wichtige Sache, die zu beachten ist, ist, dass ich beim Durchsehen des Codes festgestellt habe, dass das dritte Verzeichnis, das für Caches, eigentlich nicht verwendet wird. Es ist verlockend, einen Schritt zu weit zu gehen und diese Einstellung selbst zu entfernen oder einen Kommentar hinzuzufügen, der nicht verwendet wird, aber das würde den Rahmen von Problem Nr. 372 sprengen, und es wäre falsch, etwas zu begehen, das nicht direkt damit zusammenhängt Ausgabe. Sie müssen Ihre Änderungen fokussiert und auf die anstehende Aufgabe beschränken.

An diesem Punkt ist der Code behoben und befindet sich auf GitHub, in meinem privaten Fork. Hier kommt der beängstigende Teil ins Spiel: Die ScyllaDB-Leute zu bitten, meinen Code zu akzeptieren. Dies wird als Pull-Request bezeichnet.

Der letzte Schritt: der Pull-Request

Ich erstelle gerne Pull-Requests direkt über die Weboberfläche auf GitHub. Ich finde es intuitiver und fehlersicherer, als es von der Befehlszeile aus zu versuchen. Alles, was ich tun muss, um meinen Pull-Request zu erstellen, ist auf den kleinen grünen Button neben meinem Branch-Namen zu klicken:

Beachten Sie, dass der Kommentar automatisch von GitHub berechnet wurde. Mein Zweig hat jetzt einen neuen Commit, aber seit ich meinen Fork erstellt habe, gibt es 14 weitere Commits im Haupt-Repository, also klicke ich auf das grüne Symbol auf der linken Seite.

Glücklicherweise kollidiert mein einzelner Commit nicht mit den 14 anderen, sodass GitHub mich darüber informiert, dass ich startklar bin. Ich brauche keinen weiteren Kommentar oder eine Nachricht hinzuzufügen. Die Commit-Nachricht ist zwar sehr kurz, sagt aber alles: Was meine Codeänderung bewirkt und womit sie zusammenhängt. Als ich auf den letzten Button klicke, um meine Anfrage zu bestätigen, frage ich mich, was ich vor ein paar Tagen so beängstigend fand. Im Moment brüllt mich kein Monster an, und die Flammen der Hölle scheinen nicht zu brennen. Ehrlich gesagt war es überhaupt nicht beängstigend. In dem unwahrscheinlichen Fall, dass ich mich geirrt habe, wird meine Lösung nicht akzeptiert und das war es dann.

Wenn Sie nun die Issue-Details überprüfen, können Sie sehen, dass GitHub automatisch einen Hinweis hinzugefügt hat, dass es einen Pull-Request gibt, der auf dieses Issue verweist. Das ist die Magie von #372 in der Commit-Nachricht. Dies hilft zu vermeiden, dass andere Leute Zeit verschwenden, um etwas zu reparieren, das bereits behoben wurde.

Schlussbemerkungen

Jetzt warte ich darauf, dass meine Pull-Anforderung akzeptiert wird. Wenn dies geschieht, erhalte ich eine Benachrichtigung. Beachten Sie, dass dies einige Tage oder sogar Wochen dauern kann. Jemand muss meinen Code überprüfen, testen, ob er wie beschrieben funktioniert, das Problem beheben und schließlich sicherstellen, dass die Funktionalität des restlichen Codes nicht beeinträchtigt wird (sprich: neue Fehler erzeugt). All dies braucht Zeit, also seien Sie geduldig. Am Ende, wenn meine Pull-Anforderung akzeptiert wird, wird ScyllaDB einen weiteren Mitwirkenden haben, ein Problem weniger und ich werde meinen ersten OSS-Beitrag haben. Jetzt ist es an der Zeit, dass auch Sie es versuchen. Schließlich ist es überhaupt nicht beängstigend.