Erfahrungen mit Open-Source-Beiträgen

Dieser Artikel soll diejenigen ermutigen, die sich für "Open Source" interessieren, aber Angst haben, "Wie kann ich es wagen?" oder "Wo soll ich anfangen?".

Heute möchte ich meine Erfahrungen teilen, wie ich mich getraut habe, die Tür zu "Open Source" zu öffnen, und was ich dabei gelernt und gefühlt habe.

Open Source?

Wenn man sich mit dem Programmieren beschäftigt, stößt man oft auf den Begriff "Open Source". Wenn man sich auf GitHub umsieht, gibt es unzählige Projekte, die die Welt verändern und ihren Code offen zugänglich machen.

Projekte, die ihren Code öffentlich zugänglich machen, werden als "Open Source" bezeichnet.
Zum Beispiel gibt es große Open-Source-Projekte wie OpenJDK, Spring Framework, Redis und React.

Open-Source-Beiträge

Ich habe bisher insgesamt 4 Open-Source-Beiträge geleistet. Ich trage zu kleinen, "geringfügigen Verbesserungen" bei Open-Source-Projekten bei, anstatt Funktionen hinzuzufügen, die die Welt verändern.

Ich kenne den Code-Stil der obigen Projekte nicht und weiß auch nicht im Detail, wie sie funktionieren.

Man kann sehen, dass man "zum Community beitragen kann, auch wenn man den Code nicht vollständig versteht". Ich habe erst vor zwei Jahren mit der Entwicklung begonnen und hatte nicht das Gefühl, dass ich besonders talentiert bin.

Ich genieße es einfach, zu Open Source beizutragen und mich in der Entwickler-Community auszutauschen, deshalb setze ich diese Aktivitäten fort.

Warum wollte ich zu Open Source beitragen?

Um ehrlich zu sein, hatte ich anfangs auch den Gedanken: "Wäre es nicht gut, eine Zeile in meinen Lebenslauf aufzunehmen?" Der war ziemlich groß. Aber es gab einen noch größeren Anreiz. Es war der Wunsch, "tiefer zu lernen", und die Notwendigkeit, "das Problem, das ich hatte, zu lösen".

Ich hatte die Gelegenheit, Project Reactor, die zugrunde liegende Technologie von Spring WebFlux, in einem Teamprojekt intensiv zu studieren. Ich verstand die Konzepte durch Bücher und Dokumente, aber wie es in einem realen, komplexen System "funktioniert und optimiert wird", konnte man nur durch das Ansehen des Codes und das Ausprobieren verstehen. Außerdem fragte ich mich oft: "Wie kann ich beweisen, dass ich Reactor fleißig gelernt habe?" und hatte den Gedanken, "Ich sollte zu Open Source beitragen!".

Als ich mich schließlich entschloss, "beizutragen!", wusste ich nicht, wo ich anfangen sollte. Alles war beängstigend, von der Suche nach den Teilen, die ich in dem riesigen Code ändern sollte, bis zur Vorhersage, wie sich meine Änderungen auf das gesamte System auswirken würden.

Ich glaube, es hat lange gedauert, bis ich endlich einen PR registriert habe, weil ich mir viele Gedanken gemacht habe, wie z.B. "Was, wenn ich einen PR hochlade und beschimpft werde?"

Da Reactive Command, der Redis-Java-Client, den ich als Reactive Stack verwendete, auf Reactor basierte, wollte ich die Reactor-Chain auf der Grundlage des Reactor-Learnings direkt ändern und verbessern.

Ich habe einfach geforkt und alle Codes durchsucht, die mit den Zeichenketten 'Reactive' und 'reactor' übereinstimmten. Ich glaube, ich habe alle Codes mit Reactor Publishers wie Mono und Flux überprüft.

Als ich den Code gründlich durchsuchte, fand ich glücklicherweise einen Code, der die Reactor-Chain verwendet und bei dem die Lesbarkeit etwas geringer war und die Methodenverkettung nicht korrekt funktionierte. Es war keine Funktionsverbesserung oder Architekturänderung, die die Welt verändern würde, aber es war "ein kleines, klares Problem, das ich verstehen und beheben konnte". Ich dachte: "Oh, das ist etwas, zu dem ich auch beitragen kann!".

Auf der Grundlage dessen, was ich verstanden hatte, änderte ich den Code vorsichtig und überprüfte in einer lokalen Umgebung, ob er wie beabsichtigt funktionierte. Obwohl es sich um eine kleine Änderung handelte, näherte ich mich der Sache vorsichtig, indem ich mich so weit wie möglich an den Stil des bestehenden Codes hielt und mir Gedanken darüber machte, ob er sich auf andere Teile auswirken würde.

Ich committete die geänderten Inhalte und es war endlich Zeit, den PR zu erstellen. Um ehrlich zu sein, gab es viele Überlegungen und Zögern, bevor ich auf die Schaltfläche 'Senden' klickte. Ich war besorgt über Dinge wie: "Ist es in Ordnung, einen PR mit dieser Änderung zu senden?", "Werden sie sagen, dass ich etwas Selbstverständliches repariert habe?" und "Kann ich die Erklärung auf Englisch gut schreiben?".

Wie bereits erwähnt, hatte ich große Angst, dass ich aufgrund meiner Unzulänglichkeiten beschimpft werden würde. Aber mit dem Gedanken 'Der Anfang ist die Hälfte der Schlacht', 'Man kann nichts lernen, wenn man es nicht ausprobiert', fasste ich Mut und reichte den PR mit den von mir vorgenommenen Änderungen und den Gründen dafür ein.

redis/lettuce - #3061

Schließlich wurde mein PR 'Merged', und ich empfand ein großes Gefühl der Erfüllung und des Stolzes, als ich feststellte, dass der von mir geschriebene und geänderte Code Teil eines berühmten Open-Source-Projekts ist, das von unzähligen Entwicklern verwendet wird.

Vor allem aber war es die Gewissheit, dass "ich es auch kann!", was der größte Gewinn war.

Zögern Sie vielleicht gerade, einen Open-Source-Beitrag zu leisten?

Es ist in Ordnung, es nicht perfekt zu verstehen. Sie können, wie ich, mit kleinen Dingen beginnen. Es gibt viele Möglichkeiten, einen Beitrag zu leisten, z. B. die Korrektur von Tippfehlern in Dokumenten, die Teilnahme an der Übersetzung und die einfache Meldung von Fehlern. Wichtig ist der "Mut, die erste Stufe über die Angst hinaus zu tun".

Wenn Sie einen Fehler machen, ist dies auch eine "Gelegenheit, durch den Fehler Feedback von der Community zu erhalten und zu wachsen".

Es ist auch eine "wertvolle Gelegenheit, eine Zeile in Ihrem Lebenslauf hinzuzufügen", aber ein Open-Source-Beitrag auf der Grundlage von Lernen kann auch ein Mittel sein, um zu beweisen, dass Sie wirklich hart gelernt haben.