Hallo! Mein Name ist Dmitri Pawlow, ich arbeite bei , und bin auĂerdem Committer sowie Mitglied des PMC bei Apache Ignite und Contributor bei Apache Training. KĂŒrzlich habe ich auf einem Meetup von Sberbank ĂŒber die Rolle eines Committers im Open-Source-Bereich gesprochen. Mit der Entwicklung der Open-Source-Community haben viele hĂ€ufig Fragen: Wie wird man Committer, welche Aufgaben sollte man ĂŒbernehmen und wie viele Codezeilen muss man schreiben, um diese Rolle zu erhalten? Wenn wir an Committer denken, stellen wir uns sofort allmĂ€chtige und allwissende Personen vor, die eine Krone tragen und ein Buch ĂŒber âClean Codeâ statt eines Zepters haben. Ist das wirklich so? In meinem Beitrag werde ich versuchen, alle wichtigen Fragen zu Committern zu beantworten, damit Sie verstehen, ob dies wirklich etwas fĂŒr Sie ist.
Viele Neulinge in der Open-Source-Community haben Gedanken, dass sie niemals Committer werden können. FĂŒr viele ist dies eine prestigetrĂ€chtige Rolle, die man nur fĂŒr besondere Verdienste erlangen kann, indem man eine Menge Code schreibt. Aber so einfach ist es nicht. Lassen Sie uns Committer aus der Sicht der Community betrachten.
Wer ist ein Committer und wofĂŒr wird er benötigt?
Wenn wir ein neues Open-Source-Produkt entwickeln, erlauben wir den Nutzern stets, es zu verwenden und zu erkunden sowie modifizierte Versionen zu Àndern und zu verteilen. Wenn jedoch unkontrolliert geÀnderte Korpien der Software verbreitet werden, erhalten wir keine BeitrÀge zur Hauptcode-Basis, und das Projekt stagniert. Hier kommt der Committer ins Spiel, der das Recht hat, die BeitrÀge der Nutzer in das Projekt zu integrieren.
Warum Committer werden?
ZunĂ€chst einmal ist das Committern ein Pluspunkt fĂŒr den Lebenslauf, und fĂŒr Programmierneulinge ist es sogar noch vorteilhafter, da oft Beispiele fĂŒr Code bei Jobanfragen verlangt werden.
Ein weiteres unbestreitbares Vorteil des Committerns ist die Möglichkeit, mit fĂŒhrenden Spezialisten zu kommunizieren und innovative Ideen aus der Open-Source-Welt in Ihr Projekt zu integrieren. Zudem können Sie, wenn Sie ein Produkt mit offenem Code gut kennen, in einem Unternehmen arbeiten, das dieses unterstĂŒtzt oder verwendet. Es gibt sogar die Auffassung, dass man ohne Beteiligung an Open Source keine hohen Karrierepositionen erreichen kann.
Neben den Vorteilen fĂŒr die Karriere und BeschĂ€ftigung ist das Committen an sich eine angenehme Erfahrung. Das professionelle Umfeld erkennt dich an, und du siehst klar die Ergebnisse deiner Arbeit. Im Gegensatz zu manchen Corporate-Entwicklungen, wo man manchmal nicht einmal versteht, warum man Felder in XML hier und da verschiebt.
In Open-Source-Communities kann man mit Spitzenfachleuten wie Linus Torvalds in Kontakt treten. Aber auch wenn du nicht so einer bist, solltest du nicht denken, dass es dort nichts fĂŒr dich zu tun gibt â es gibt Aufgaben auf unterschiedlichen Niveaus.
AuĂerdem gibt es manchmal zusĂ€tzliche Boni: Committer bei Apache erhalten beispielsweise kostenlos eine Lizenz fĂŒr IntelliJ Idea Ultimate (wenn auch mit gewissen EinschrĂ€nkungen).
Was muss man tun, um Committer zu werden?
Es ist ganz einfach â man muss committen.
Wenn du denkst, dass es bei Projekten fĂŒr dich keine Aufgaben gibt â liegst du falsch. SchlieĂe dich einfach der Community an, die dich interessiert, und erledige das, was dort erforderlich ist. In der Apache Software Foundation gibt es einen speziellen mit Anforderungen an Committer.
Welche Aufgaben werden zu lösen sein?
Die verschiedenen Möglichkeiten reichen von der Entwicklung bis hin zum Schreiben von Tests und Dokumentationen. Ja, der Beitrag von Testern und Dokumentatoren wird in der Community genauso geschĂ€tzt wie der der Entwickler. Es gibt auch ungewöhnliche Aufgaben â zum Beispiel einen YouTube-Kanal zu fĂŒhren und anderen Nutzern zu zeigen, wie man ein Open-Source-Produkt verwendet. Zum Beispiel hat die Apache Software Foundation eine eigene , auf der angegeben ist, welche Hilfe benötigt wird. Â
Muss man eine groĂe Funktion schreiben, um Committer zu werden?
Nein. Das ist ĂŒberhaupt nicht notwendig. Ein Committer muss nicht tonnenweise Code schreiben. Wenn Sie jedoch eine groĂe Funktion entwickelt haben, wird es dem Projektmanagement-Komitee leichter fallen, Sie zu bewerten. Der Beitrag zur Community besteht nicht nur aus Funktionen, Programmierung und Tests. Wenn Sie ein Schreiben verfassen und ein Problem beschreiben, ein fundiertes Lösungsvorschlag unterbreiten â das ist ebenfalls ein wertvoller Beitrag.
Es ist wichtig zu verstehen, dass das Committer-Dasein auf Vertrauen basiert. Ob Sie Committer werden oder nicht, entscheiden Menschen wie Sie anhand ihres Eindrucks von Ihnen als Person, die dem Produkt Nutzen bringt. Daher mĂŒssen Sie durch Ihr Handeln und Ihre Taten in der Community dieses Vertrauen gewinnen.
Wie verhÀlt man sich?
Seien Sie konstruktiv, positiv, höflich und geduldig. Denken Sie daran, dass im Open Source alle freiwillig tÀtig sind und niemand jemandem etwas schuldet. Wenn Sie keine Antwort erhalten, warten Sie und erinnern Sie nach 3-4 Tagen an Ihre Frage. Wenn Sie weiterhin keine Antwort erhalten, naja, Open Source ist freiwillig.
Bitten Sie nicht darum, dass jemand etwas fĂŒr Sie oder an Ihrer Stelle tut. Erfahrene Mitglieder der Community haben ein GespĂŒr fĂŒr solche 'Bettler' und entwickeln sofort eine Abneigung gegen diejenigen, die ihre Arbeit abwĂ€lzen wollen.
Wenn Ihnen geholfen wird, ist das groĂartig, aber missbrauchen Sie das nicht. Schreiben Sie nicht: 'Leute, behebt das, sonst verliere ich meinen Jahresbonus.' Fragen Sie stattdessen, in welche Richtung Sie weitergehen sollen, und erzĂ€hlen Sie, was Sie zu diesem Bug bereits herausgefunden haben. Wenn Sie versprechen, die Wiki nach Lösung des Problems zu aktualisieren, erhöht sich die Wahrscheinlichkeit, dass Sie eine Antwort erhalten, erheblich.
Lesen Sie schlieĂlich und lernen Sie, .
Wie kann man beitragen, wenn man kein Committer ist?
In Projekten wird hĂ€ufig das RTC-Schema verwendet, bei dem zunĂ€chst alle eine ĂberprĂŒfung durchlaufen, bevor die Ănderungen in den Master-Branch zusammengefĂŒhrt werden. Bei diesem Schema werden absolut alle ĂŒberprĂŒft, selbst die Committer. Daher kann man erfolgreich zum Projekt beitragen, ohne Committer zu sein. Um die Chancen zu erhöhen, als neuer Committer ausgewĂ€hlt zu werden, kann man sich mit der Mentorship neuer Teilnehmer beschĂ€ftigen, Wissen teilen und neue Materialien erstellen.
DiversitĂ€t â Nutzen oder Schaden?
DiversitĂ€t â im VerstĂ€ndnis der Apache Software Foundation bedeutet dies unter anderem, dass die Teilnehmer eines Open-Source-Projekts mit mehreren Unternehmen verbunden sind. Wenn alle nur mit einer einzigen Organisation verbunden sind, verlassen alle Teilnehmer schnell das Projekt, sobald das Interesse dieser Organisation verloren geht. DiversitĂ€t sorgt fĂŒr Langfristigkeit, StabilitĂ€t des Projekts, vielfĂ€ltige Erfahrungen und ein breites Spektrum an Meinungen der Teilnehmer.
Aus Liebe oder aus Berechnung?
In Open-Source-Projekten gibt es zwei Arten von Menschen: die, die fĂŒr eine Organisation arbeiten, die zu diesem Produkt beitrĂ€gt, und die, die aus Leidenschaft hier sind, also die Freiwilligen. Wer von ihnen ist produktiver? In der Regel sind es die Teilnehmer, die das Produkt vonseiten der beitragenden Organisation unterstĂŒtzen. Sie haben einfach mehr Zeit und eine klare Motivation, der Wahrheit auf den Grund zu gehen. Sie sind auf die Aufgabe fokussiert und nĂ€her am Nutzer.
Diejenigen, die dies 'aus Liebe' tun, sind ebenfalls motiviert, jedoch anders â sie möchten das Projekt erkunden und die Welt verbessern. Genau solche Teilnehmer sind meist stabiler und langfristig orientiert, denn wer aus eigenem Antrieb in die Gemeinschaft kommt, wird sie vermutlich nicht so schnell wieder verlassen.
Wie findet man das Gleichgewicht zwischen ProduktivitĂ€t und StabilitĂ€t? Es gibt zwei Optionen. Die erste Option ist, wenn ein Mitglied in einem Unternehmen arbeitet, das offiziell an diesem Open-Source-Projekt beteiligt ist, und zusĂ€tzlich aus eigenem Interesse etwas beitrĂ€gt, beispielsweise indem es Neueinsteiger unterstĂŒtzt. Die zweite Option besteht darin, dass das Unternehmen eine Open-Source-Transformation durchlebt hat. Zum Beispiel, wenn Mitarbeiter vier Tage die Woche an dem HauptgeschĂ€ftsprojekt arbeiten und die restliche Zeit mit Open Source verbringen.
Committer â sein oder nicht sein?
Committer sein ist ein wichtiges und nĂŒtzliches Thema, aber man sollte nicht unbedingt danach streben, Committer zu werden. Diese Rolle kann man auch ohne Code erhalten, und sie beweist nicht zwangslĂ€ufig Ihr Wissen. Entscheidend ist allein die Expertise, also das Wissen und die Erfahrung, die Sie sammeln, indem Sie das Projekt studieren, darin arbeiten und anderen helfen, Probleme zu lösen.
Quelle: habr.com
