Macht, Geld und Open Source. Erklären, wie die Community mit Apache Ignite funktioniert

Beim letzten Gemeindetreffen von Apache Ignite in Moskau sprach ich über:

• Open Source Community;
• Macht und Geld in Open Source;
• Wie man ein Mitwirkender und Committer wird und warum man es braucht.

Aufgrund der begrenzten Zeit des Berichts konnte ich keine weiteren Beispiele nennen, daher poste ich die erweiterte Version auf Habré. All dies basiert auf meiner persönlichen Erfahrung und ist keine offizielle Position eines Unternehmens oder einer Organisation.

Was ist eine Gemeinschaft?

Dies mag offensichtlich erscheinen, aber lassen Sie uns dennoch klarstellen, was wir unter Community verstehen. Zunächst sprechen wir über eine Online-Community. Dies ist eine Art Plattform, auf der Menschen miteinander interagieren können. Wenn sich eine Community beispielsweise der Gesundheit, Fitness und ähnlichen Aktivitäten widmet, besteht ihre Aufgabe möglicherweise darin, ihre Mitglieder zu unterstützen. Oder eine Gemeinschaft kann ein öffentliches Gut schaffen. Dies ist genau der Fall bei der Open Source Software Development Community. Wenn Sie eine Software entwickeln möchten, ist es außerdem unwahrscheinlich, dass Sie Personen mit ähnlichen Ansichten finden, z. B. bei Ihrer Landung oder am nächsten Eingang. Es gibt solche Projekte, aber normalerweise als Studentenprojekte. Und die Online-Community beseitigt die Barrieren zwischen Kontinenten und Zeitzonen und ermöglicht es Ihnen, mehr Enthusiasten zu finden.

Apache-Stiftung

Die Geschichte von Apache begann 1999 mit dem HTTPD-Webserver: Eine Gruppe von Menschen begann mit der Entwicklung eines Webservers, Benutzer kamen zu ihnen, von denen einige Patches sendeten, weil sie etwas an diesem Produkt verbessern oder Fehler beheben wollten. Die Entwickler begannen allmählich, den aktivsten Mitgliedern dieser Community das Recht zuzuweisen, auf das Repository zuzugreifen, das jetzt als Festschreibungsrechte bezeichnet wird.

Mit dem gleichen Ansatz bei der Entwicklung von Open Source ist Apache mittlerweile die größte Organisation (Stiftung), die Open Source-Software entwickelt. Die Organisation ist in 319 (bisher) diversifizierte Projekte unterteilt, von denen etwa 200 Top-Level-Projekte sind. Es gibt keinen einzigen Prozess für alle Projekte, alle Teilnehmer sind Freiwillige, ihre Arbeit wird niemals von der Organisation bezahlt.

Für Apache müssen alle Projekte Folgendes haben:

• Rechtspolitik;
• Markennutzungsrichtlinien;
• Abstimmung über die Annahme von Veröffentlichungen;
• Verwendung von Mailinglisten;
• Informationssicherheit.

Apache Inkubator

Um eine Community aufzubauen, durchlaufen alle Apache-Projekte unbedingt den Apache Incubator. Dies ist eine Zwischenstufe in der Entwicklung nicht einmal des Projekts, sondern der Gemeinschaft um es herum. Niemand in Apache wird vorschreiben, welche Technologie verwendet werden soll. Darüber hinaus werden sie nicht einmal zur Entscheidung auffordern. Das Ziel von Apache Incubator ist es, eine Community aufzubauen, die gemeinsam Entscheidungen trifft. Es ist sehr wichtig, dass die Teilnehmer verstehen, wie und wer die Entscheidung trifft, wo sie sprechen können, wo ihre Stimme gehört wird. Das Organisieren einer ASF hilft, indem ein Mentor an das Projekt angehängt wird.

Apache-Projekt der obersten Ebene

Wenn ein Projekt Apache Incubator verlässt, kann es zu einem Projekt der obersten Ebene werden. Apache unterstützt das Projekt bei der Teilnahme an Konferenzen, bietet alle möglichen Unterstützung bei der Werbung für die Marke und unterstützt die Infrastruktur.

Die Community des Top-Level-Projekts garantiert den Benutzern, dass:

• Der Code kann legal verwendet werden.
• Hochwertiger Code;
• Informationssicherheit wird beachtet: Beispielsweise sind alle Releases signiert;
• Das Projekt steht den Benutzern immer zur Verfügung.

Open Source und Strom

Lassen Sie uns nun über Macht und Geld sprechen und wie Entscheidungen getroffen werden. Dies ist selbst für Community-Mitglieder nicht immer offensichtlich. Das Apache-Projekt enthält mehrere Rollen, denen mehrere Mailinglisten entsprechen:

• Benutzer (user@project.apache.org);
• Entwickler (dev@project.apache.org);
• Committer (dev@project.apache.org);
• PMC (private@project.apache.org);
• PMC-Vorsitzender (private@project.apache.org).

Darüber hinaus können Sie bereits im Rahmen der Apache Software Foundation wachsen, Mentor eines Projekts werden und anderen Projekten beim Aufbau einer Community helfen.

Je höher die Rolle, desto weniger Personen führen sie aus, dh es bildet sich eine umgekehrte Pyramide: Je mehr Benutzer, desto weniger PMC. Normalerweise interessiert sich jeder dafür, dass die Teilnehmer erwachsen werden und eine höhere Rolle spielen.

Im Gegensatz zu kommerziellen Unternehmen, bei denen Personal und Wachstum durch das Budget begrenzt sind, hat Open Source dies nicht, nichts begrenzt die Anzahl der Kommissare oder PMCs. Die Gruppe reguliert sich selbständig.

Benutzer

Benutzer sind alle von uns. Sicherlich verwendet jeder von Ihnen eine Art Open-Source-Software. Für die Community ist es wichtig, dass der Benutzer nicht nur Fehlerberichte oder Funktionsanfragen verwendet oder Feedback gibt, sondern auch anderen hilft. Das heißt, aus Sicht der Community wird ein Teilnehmer nur dann zum Benutzer, wenn er die Benutzerliste abonniert und darauf reagiert und anderen hilft, das Produkt zu beherrschen, und sein Wissen teilt.

Entwickler / Mitwirkender

Wenn der Benutzer bereit ist, einen Beitrag zum Projekt zu leisten, wird er mit dem ersten Beitrag automatisch ein Mitwirkender oder Entwickler - dies sind Synonyme. Der Mitwirkende nimmt an einem Entwickler-Newsletter teil, in dem alles im Zusammenhang mit Community-Beiträgen besprochen wird. Alle Entwickler beeinflussen die Entscheidungsfindung in der Community, kritisieren Entscheidungen und bieten Alternativen an.

Committer

Wenn die Community der Ansicht ist, dass die Person einen ausreichenden Beitrag geleistet hat, kann sie berechtigt sein, auf das Repository zuzugreifen, dh die Mindestanzahl von Überprüfern ihres Codes wird auf Null reduziert (obwohl in Apache Ignite Committer manchmal noch Code-Parsing durchführen). Committer unterzeichnen eine ICLA ( Individual Contributor License Agreement ). Es kann jedoch auch vor Erhalt der Provisionen unterschrieben werden. Der Committer erhält eine Mailbox auf apache.org und kann Entscheidungen in Bezug auf jeden Beitrag zum Projekt treffen.

PMC-Mitglied

PMC-Mitglied (Project Management Committee) - Mitglied des Projektmanagementausschusses. Dieses Community-Mitglied hat bereits einen großen Beitrag zur Entwicklung des Produkts geleistet und ist berechtigt, langfristige Entwicklungsentscheidungen zu treffen, das Projekt zu kontrollieren, viele Aspekte zu überwachen, insbesondere die gemeinsame Entscheidungsfindung. Es hilft Community-Mitgliedern, einen Konsens zu erzielen. PMC hat eine Menge Verantwortlichkeiten in Apache, zum Beispiel kann es abstimmen, um die Veröffentlichung zu akzeptieren. Der Committer und der Mitwirkende können auch, aber im Gegensatz zu ihnen hat PMC eine verbindliche Stimme. PMC kann Committer oder neue PMCs vorschlagen.

PMC-Vorsitzender

Der PMC Chair ist die Brücke zwischen der Apache Software Foundation. Vielleicht hat der PMC-Vorsitzende im Vergleich zum PMC-Mitglied nicht viel Macht. Er muss jedoch die Probleme lösen und dem Apache Board über den Status des Projekts Bericht erstatten.

Entscheidungsfindung: Duokratie

Apache wird vom Prinzip der Duokratie dominiert (do-ocracy, from do - "do"). Je mehr Sie tun, desto mehr Möglichkeiten haben Sie, desto mehr beeinflussen Sie das Projekt.
Wenn eine Entscheidung eine koordinierte Position aller Teilnehmer erfordert, wird abgestimmt. Die Abstimmung dauert mindestens 72 Stunden.

Wähler setzen:

+1: "für die Entscheidung."
0: "Es ist mir egal."
-1: "gegen die Entscheidung." In diesem Fall müssen Sie etwas anderes vorschlagen und ausführlich erklären, warum Sie dagegen stimmen.

Es gibt andere Arten von Abstimmungen:

0: "Ich mag die Idee nicht wirklich, aber sie passt zu mir."
-0: "Ich werde mich nicht einmischen, aber es ist besser, dies nicht zu tun."
-0.5: "Ich mag die Idee nicht, aber ich kann keine rationalen Argumente dagegen finden."
++ 1: "Super, lass es uns tun!"
-0.9: "Ich mag es nicht, aber wenn jeder will, werde ich keine Stöcke in die Räder stecken, mach weiter."
+0.9: "Die Idee ist cool, ich mag sie, aber ich habe nicht die Zeit / das Wissen, um zu helfen."

Fauler Konsens

Es gibt eine Entscheidungspolitik wie einen trägen Konsens oder die Zustimmung durch Schweigen. Dieser Vorgang dauert ebenfalls mindestens 72 Stunden. Wenn eine Person ausdrücklich schrieb: „Ich möchte diese Entscheidung durch einen trägen Konsens führen“, gilt die Entscheidung in drei Tagen als von der Community akzeptiert, auch wenn niemand geantwortet hat.

Zustimmung durch Mehrheit und Zustimmung durch Konsens

Die Abstimmung für die Veröffentlichung ist aktiver: In diesem Fall ist die Zustimmung der Mehrheit der Community-Mitglieder erforderlich: drei verbindliche Stimmen (von PMC) „für“ und mehr Stimmen „für“ als „gegen“.
Konsens ist die beste Option: Alle sind dafür, mit mindestens drei PMCs.

Veto

Ein qualifizierter Mitarbeiter, normalerweise ein PMC-Mitglied, kann ein Veto einlegen. Er stimmt mit -1 für die Änderung des Codes und schreibt eine ausführliche Erklärung. Niemand kann eine solche PMC-Mitgliedslösung umgehen. Sie können kein Veto gegen eine Veröffentlichung einlegen, aber wenn die Bearbeitung beispielsweise sehr schlecht ist, eine Sicherheitslücke bildet oder die Leistung stark beeinträchtigt, kann PMC mit -1 stimmen. Und bis er das Veto zurückzieht, ist es unmöglich, die Bearbeitung anzuwenden.

Meritokratie

Ein weiteres Prinzip, das der Duokratie nahe steht. Wörtlich bedeutet "Meritokratie" "die Macht der Würdigen". In Open Source bedeutet dies, dass der Benutzer, wenn er, wie die Gruppe glaubt, ziemlich viel für die Community getan hat, zum Committer befördert wird. Sie fragen sich vielleicht, wie fair diese Entscheidung ist, ist sie immer absolut ehrlich und ausgewogen? Dies ist eine äußerst subjektive Entscheidung aller PMCs in dieser Community. In großen Communities wie Apache Ignite kann diese Richtlinie mehr oder weniger formalisiert werden. Bestimmte menschliche Beiträge sind wichtig. Nehmen Sie unbedingt aktiv am Newsletter für Entwickler teil. Die „Suffizienz“ wird jedoch von jedem Projekt individuell bestimmt.

Ein wichtiger Punkt sind die menschlichen Qualitäten des Teilnehmers. Die Apache-Richtlinie besagt ausdrücklich, dass die Interaktion der Person mit anderen Teilnehmern bewertet wird und wie sie sich verhält, wenn sie ihrer Meinung nicht zustimmt. Damit ein Mitglied zu einem Committer oder PMC befördert werden kann, müssen andere PMCs auf der privaten Liste abstimmen, und es darf keine Nein-Stimmen geben.

Open Source und Geld

Dieses wichtige Thema taucht auf die eine oder andere Weise auf: Wie man mit den Apache Software Foundation-Produkten Geld verdient. Die Organisation bietet die kommerziell freundlichste Lizenz von allen, die es gibt. Sie können Apache-basierte Produkte verkaufen oder Apache-Produkte unterstützen. Sie können sie in kommerziellen Produkten verwenden.

Eine wichtige Voraussetzung: Apache-Produkte sollten immer kostenlos genutzt werden können. Sie werden unabhängig von kommerziellen Interessen verwaltet. Dies wird von PMC überwacht.

Der Beauftragte kann von einer Drittorganisation Geld für einen Beitrag zum Projekt erhalten. Der Beauftragte kann von einem Dritten beauftragt werden. Kürzlich erzählten Community-Mitglieder in Habr, wie sie mit der Open-Source-Community Apache Ignite in Sberbank Technologies zusammenarbeiten. Aber die Apache Foundation zahlt niemals an Committer. Dies ist eine prinzipielle Position. Für Apache ist der Committer immer ein Freiwilliger und eine Einzelperson. Das heißt, das Unternehmen kann nicht an Apache-Projekten teilnehmen, sondern nur ein Entwickler.

Warum und wie man Open Source beitritt

Warum lohnt es sich, einen Beitrag zu Open Source-Projekten zu leisten?

Dies ist eine gute Gelegenheit, Ihre Fähigkeiten zu verbessern und sich einen professionellen Ruf zu verdienen. Handelsunternehmen schätzen die Teilnahme an Open Source. Viele berühmte Entwickler beteiligen sich an verschiedenen Projekten, werden Kommissare und PMC.

Was hindert Menschen daran, an Open Source teilzunehmen?

• "Du musst eine Olympiade oder ein Senior mit 20 Jahren Erfahrung sein, sonst kann ich das nicht." In der Tat nein. Apache Ignite ist ein komplexes Projekt, aber auch hier finden Sie einfache Aufgaben. Zum Beispiel einfache Tickets und Aufgaben zum Schreiben von Dokumentationen, die das Projekt besser beschreiben sollen. Nirgendwo in Apache heißt es, dass Sie Code schreiben müssen, um Committer zu werden.
• "Ich brauche fließendes Englisch, sonst kann ich nicht damit umgehen." Diejenigen, die an Entwicklerlisten teilnehmen, werden bestätigen: Dort müssen Sie kein fließendes Englisch sprechen. Darüber hinaus erfolgt die schriftliche Kommunikation überhaupt nicht in Echtzeit. Es bleibt Zeit, über eine ausgewogene Antwort nachzudenken und sie zu schreiben.
• "Wenn ich meine Komponente an Open Source sende, kann ich sie nie wieder verwenden." In Apache ist dies nicht so. Sie können Ihre Komponente weiterhin in einem kommerziellen Produkt verwenden. Sie existiert einfach unter der Apache Foundation unter der Apache-Lizenz.
• "Jeder wird lesen, was ich im Internet schreibe." Selbst in der Apache Ignite-Community liest nicht jeder, was wir schreiben. Es ist wie in einem Witz über den schwer fassbaren Joe: Niemand kann ihn fangen, weil ihn niemand braucht. Ich bin sicher, dass meine Freunde und Verwandten nicht lesen, was ich in die Entwicklerliste schreibe, weil es ihnen egal ist.
• "Es wird meine ganze Freizeit dauern." Dies ist teilweise richtig: Die Beteiligung der Gemeinschaft macht süchtig. Wenn Sie anfangen, an der Diskussion teilzunehmen, wird es einige Zeit dauern. Und wenn Sie wachsen, wird es mehr dauern. Je mehr Sie wissen, desto mehr können Sie sagen, desto mehr nehmen Sie an user und dev.list teil. Aber auch hier besteht keine Verpflichtung gegenüber Apache. Jeder regelt sein eigenes Engagement. Wenn Sie einen Patch erstellen können, erstellen Sie einen Patch. Und doch wird dich niemand zwingen. Selbst wenn eine Person zum Kommissar ernannt wird, heißt es im Vorschlagsschreiben, dass sie nicht mehr involviert sein muss, als sie bereit ist zu geben.

Wie fange ich an?

Wenn Sie an Apache-Projekten teilnehmen möchten, benötigen Sie ein Konto bei Github, ein Postfach, eine Registrierung in Apache JIRA und möglicherweise im Wiki . Jede Community hat einen Artikel über Anfängerbeiträge in Apache Ignite.

Es ist eine gute Form, einen Begrüßungsbrief zu schreiben: „Hallo! Ich bin so und so. Ich möchte ein solches Ticket machen, mein Spitzname in JIRA ist so und so . " Dieser Brief ist wichtig, um dem Benutzer die Rolle des Mitwirkenden zuzuweisen.

Mailinglisten

Für die Interaktion mit anderen Mitgliedern benötigt Apache die Verwendung von Mailinglisten. Ich höre manchmal Unzufriedenheit: Warum so altmodisch? Es gibt eine Reihe von Chats, Instant Messenger. Dies liegt daran, dass jedes Mitglied von Apache-Projekten ein Freiwilliger ist. Er kann seine eigene Familie haben, Arbeit, die nicht mit Open Source zu tun hat, seine Hobbys. Er kann nicht online chatten. Vielleicht kann er alle drei Tage Post checken. Und in solchen Situationen funktionieren Mailinglisten einwandfrei.

Vergessen Sie auch nicht, dass Community-Mitglieder auf der ganzen Welt verstreut sind. Und Mann
an wen Sie eine Frage stellen, möglicherweise auf einem anderen Kontinent sind und erst morgen antworten.
Geduld und Höflichkeit sind daher die Eigenschaften, die für die Korrespondenz in Mailinglisten sehr wichtig sind. In der Apache Ignite-Community schreiben erfahrene Mitglieder beispielsweise niemals, dass sie nicht mit Ihnen übereinstimmen. Sie schreiben, dass sie nicht sicher sind, ob sie zustimmen.

Beispielbrief:

Hallo, □□□□□□□, ich bin mir nicht sicher, ob ich damit einverstanden bin, weil ...

Community ist wichtiger als Code

Eines der Prinzipien von Apache: Community ist wichtiger als Code. Dies bedeutet, dass das Apache-Projekt als erstes eine Community rund um ein Open Source-Projekt erstellen soll. Und dann beginnt die Magie und ein guter Code erscheint. Wenn Sie mit einem Brief nicht einverstanden sind, verschieben Sie ihn um 4 Stunden, lesen Sie ihn erneut und verschieben Sie ihn erneut. Dann besteht eine große Chance, dass Sie mit Zurückhaltung reagieren, ohne die anderen Mitglieder der Community mit nachlässigen Worten zu drängen. Wir sind alle Freiwillige, und wenn sich die Menschen nicht wohl fühlen, werden sie anfangen zu gehen, und für ein Open-Source-Projekt ist dies ein sehr ernstes Risiko.

Korrespondenzempfehlungen

Sie ähneln mehr oder weniger denen, die in der normalen Geschäftskorrespondenz verwendet werden. Wenn ein Satz falsch interpretiert werden kann, wird er falsch interpretiert, insbesondere angesichts der Größe der Community. Alle Empfehlungen beruhen auf drei Grundprinzipien: positiv, konstruktiv und respektvoll zu sein.

Ein Beispiel für einen nicht so guten Brief:

Hallo, □□□□□.
Diese Lösung sieht für mich etwas hässlich aus.

Ein Wunsch von mir als Mitglied der Entwicklerliste: Schreibe kurze Buchstaben - drei Absätze oder 7 Sätze. Wir sind alle Technikfreaks und möchten so viele Details wie möglich angeben. Aber wenn es zu viele von ihnen gibt, ist dies vielleicht eine Gelegenheit, einen separaten Artikel zu schreiben.

Was zu schmuggeln?

Jede Community hat eine Liste der aktuellen Anforderungen. Ignite hat eine Liste einfacher Tickets. Wenn Sie während der Verwendung einen Fehler gefunden und diesen in Ihrer Gabelung behoben haben, ist es durchaus möglich, ein JIRA-Problem für dieses Unternehmen zu erstellen, eine Pull-Anfrage zu stellen und in die Entwicklerliste zu schreiben.

So kommen Sie durch die Codeüberprüfung

Während Sie neu in der Community sind, ist es unwahrscheinlich, dass Sie feststellen können, welches Ticket Priorität hat. Es kann sinnvoll sein, sich an die Person zu wenden, die die Komponente begleitet. Ihre Hilfe ist für sie sehr wichtig. Sie können auch in der Entwicklerliste fragen, welche Tickets wichtiger sind.

Wenn es keine Antwort gibt, erinnern wir uns erneut daran, dass jeder ein Freiwilliger ist. Es könnte eine gute Idee sein, Sie daran zu erinnern, was Sie in drei Tagen vorgeschlagen haben.

In Apache-Projekten, einschließlich Ignite, gibt es keine Rolle eines Projektmanagers, der den Rückstand überwacht. Daher können dort auch irrelevante Tickets gefunden werden. Es wird empfohlen, zuerst in die Entwicklerliste zu schreiben und zu klären.

Ein weiteres Merkmal von Apache: In einem kommerziellen Unternehmen gibt es möglicherweise eine klare Richtlinie, nach der ein Mitarbeiter einer bestimmten Ebene auf die Dokumentation zugreifen und diese bearbeiten kann, ein Mitarbeiter einer niedrigeren Ebene jedoch nicht. In Apache gibt es so etwas nicht. Wenn es etwas zu leihen gibt, kein Problem. Ich denke, dass Sie in keinem Projekt Probleme haben werden, Zugriffsrechte zu erhalten, und es spielt keine Rolle, ob die Person formell kein Committer ist.

Sprechen Sie über das Projekt

Die Community wird durch Produktartikel stark unterstützt. Die Apache Software Foundation selbst hilft bei Konferenzen. Sie können auch Ihre Erfahrungen beschreiben, nicht nur mit Apache Ignite. Es kann ein interessanter Anwendungsfall sein, studentische Arbeit. Sie werden immer auf der Entwicklerliste veröffentlicht.