Puissance, argent et open source. Expliquer comment la communauté fonctionne avec Apache Ignite

Lors de la dernière réunion de la communauté Apache Ignite à Moscou, j'ai parlé de:

• Communauté open source;
• Pouvoir et argent en open source;
• Comment devenir contributeur et contributeur, et pourquoi vous en avez besoin.

Le temps limité du rapport ne m'a pas permis de donner plus d'exemples, donc je poste la version étendue sur Habré. Tout ce qui précède est basé sur mon expérience personnelle et ne constitue pas une position officielle d'une entreprise ou d'une organisation.

Qu'est-ce qu'une communauté?

Cela peut sembler évident, mais clarifions quand même ce que nous entendons par communauté. Tout d'abord, nous parlons d'une communauté en ligne. Il s'agit d'une sorte de plateforme permettant aux gens d'interagir les uns avec les autres. Si une communauté se consacre, par exemple, à la santé, à la forme physique et à des activités similaires, sa tâche peut être de soutenir ses membres. Ou une communauté peut créer un bien public. C'est exactement le cas avec la communauté de développement de logiciels open source. En outre, si vous souhaitez développer une sorte de logiciel, il est peu probable que vous trouviez des personnes ayant des vues similaires, par exemple, sur votre palier ou dans l'entrée suivante. Il existe de tels projets, mais généralement des projets étudiants. Et la communauté en ligne efface les barrières entre les continents et les fuseaux horaires, vous permet de trouver plus de passionnés.

Fondation Apache

L'histoire d'Apache a commencé en 1999 avec le serveur Web HTTPD: un groupe de personnes a commencé à développer un serveur Web, les utilisateurs ont commencé à venir vers eux, dont certains ont commencé à envoyer des correctifs parce qu'ils voulaient améliorer quelque chose dans ce produit ou corriger des bogues. Les développeurs ont progressivement commencé à attribuer aux membres les plus actifs de cette communauté le droit de pousser vers le référentiel, qui s'appelle désormais des droits d'engagement.

Appliquant la même approche au développement de l'open source, Apache est devenue la plus grande organisation (fondation) qui développe des logiciels open source. L'organisation est divisée en 319 (jusqu'à présent) projets diversifiés, dont environ 200 sont de haut niveau. Il n'y a pas de processus unique pour tous les projets, tous les participants sont bénévoles, leur travail n'est jamais payé par l'organisation.

Apache sans échec nécessite que tous les projets aient:

• Politique juridique;
• Politiques d'utilisation de la marque;
• Vote sur l'adoption des communiqués;
• Utilisation de listes de diffusion;
• Sécurité de l'information.

Incubateur Apache

Pour créer une communauté, tous les projets Apache passent par l'incubateur Apache sans échec. Il s'agit d'une étape intermédiaire dans le développement, pas même du projet, mais de la communauté qui l'entoure. Personne dans Apache ne dictera quelle technologie utiliser. De plus, ils ne demanderont même pas quelle décision choisir. Le but d'Apache Incubator est de construire une communauté qui prend des décisions ensemble. Il est très important que les participants comprennent comment et qui prend la décision, où ils peuvent s'exprimer, où leur voix sera entendue. Organiser un ASF aide en attachant un mentor au projet.

Projet Apache de haut niveau

Si un projet quitte Apache Incubator, il peut devenir un projet de niveau supérieur. Apache aide le projet à participer à des conférences, fournit toute l'assistance possible dans la promotion de la marque et soutient l'infrastructure.

La communauté du projet de haut niveau garantit aux utilisateurs que:

• Le code peut être utilisé légalement;
• Code de haute qualité;
• La sécurité de l'information est respectée: par exemple, toutes les versions sont signées;
• Le projet sera toujours disponible pour les utilisateurs.

Open source et puissance

Parlons maintenant du pouvoir et de l'argent, et de la façon dont les décisions sont prises. Ce n'est pas toujours évident, même pour les membres de la communauté. Il existe plusieurs rôles dans le projet Apache et plusieurs listes de diffusion leur correspondent:

• Utilisateur (user@project.apache.org);
• Développeur (dev@project.apache.org);
• Committer (dev@project.apache.org);
• PMC (private@project.apache.org);
• Président du PMC (private@project.apache.org).

De plus, vous pouvez déjà grandir dans le cadre de l'Apache Software Foundation, devenir le mentor d'un projet, aider d'autres projets à construire une communauté.

Plus le rôle est élevé, moins il y a de personnes, c'est-à-dire une forme de pyramide inversée: le plus d'utilisateurs, le moins de PMC. Habituellement, tout le monde est intéressé par le fait que les participants grandissent et jouent un rôle plus important.

Contrairement aux sociétés commerciales, où le personnel et la croissance sont limités par le budget, l'open source ne l'a pas, rien ne limite le nombre de commissaires ou de PMC. Le groupe se régule indépendamment.

Utilisateur

Les utilisateurs sont nous tous. Chacun d'entre vous utilise sûrement une sorte de logiciel open source. Il est important pour la communauté que l'utilisateur non seulement utilise ou donne des commentaires sous la forme de rapports de bogues ou de demandes de fonctionnalités, mais aide également les autres. Autrement dit, du point de vue de la communauté, un participant ne devient un utilisateur que lorsqu'il s'abonne et répond à la liste des utilisateurs et aide les autres à maîtriser le produit, partage ses connaissances.

Développeur / Contributeur

Si l'utilisateur est prêt à contribuer au projet, avec la première contribution, il deviendra automatiquement un contributeur ou un développeur - ce sont des synonymes. Le contributeur participe à une newsletter destinée aux développeurs qui traite de tout ce qui concerne les contributions de la communauté. Tous les développeurs influencent la prise de décision communautaire, critiquent tous les décisions et proposent des alternatives.

Committer

Si la communauté estime que la personne a apporté une contribution suffisante, elle peut avoir le droit de pousser vers le référentiel, c'est-à-dire que le nombre minimum de réviseurs de son code est réduit à zéro (bien que dans Apache Ignite, les committers passent encore parfois par l'analyse de code). Les committers signent un ICLA ( Contrat de licence de contributeur individuel ). Cependant, il peut également être signé avant de recevoir des commissions. Le committer reçoit une boîte aux lettres sur apache.org et peut prendre des décisions concernant chaque contribution au projet.

Membre PMC

Membre PMC (Project Management Committee) - Membre du comité de gestion de projet. Ce membre de la communauté a déjà apporté une grande contribution au développement du produit et a le droit de prendre des décisions de développement à long terme, contrôle le projet, surveille de nombreux aspects, en particulier la prise de décision conjointe. Il aide les membres de la communauté à atteindre un consensus. PMC a beaucoup de responsabilités dans Apache, par exemple, il peut voter pour accepter la version. Le committer et le contributeur peuvent également, mais, contrairement à eux, PMC a une voix contraignante. PMC peut proposer des committers ou de nouveaux PMC.

Président PMC

La chaire PMC est le pont entre l'Apache Software Foundation. Peut-être que le président du PMC n'a pas beaucoup de pouvoir par rapport au membre du PMC. Mais il doit résoudre les problèmes et faire rapport au Conseil Apache sur l'état d'avancement du projet.

Prise de décision: Duocracy

Apache est dominé par le principe de la duocratie (do-ocracy, de do - "do"). Plus vous en faites, plus vous avez de possibilités, plus vous influencez le projet.
Si une décision requiert une position coordonnée de tous les participants, un vote est pris. Le vote dure au moins 72 heures.

Les électeurs ont déclaré:

+1: "pour la décision".
0: "Je m'en fiche."
-1: "contre la décision". Dans ce cas, vous devez proposer autre chose et expliquer en détail pourquoi vous votez contre.

Il existe d'autres types de votes:

0: "Je n'aime pas vraiment l'idée, mais ça me convient."
-0: "Je ne vais pas interférer, mais il vaut mieux ne pas le faire."
-0,5: "Je n'aime pas l'idée, mais je ne trouve pas d'arguments rationnels contre."
++ 1: "Super, faisons-le!"
-0,9: "Je n'aime pas ça, mais si tout le monde le veut, je ne mettrai pas de bâtons dans les roues, allez-y."
+0,9: "L'idée est cool, je l'aime bien, mais je n'ai pas le temps / les connaissances pour vous aider."

Consensus paresseux

Il existe une politique de prise de décision comme le consensus paresseux ou l'approbation par le silence. Cette procédure dure également au moins 72 heures. Si une personne a explicitement écrit: «Je veux passer cette décision par consensus paresseux», alors dans trois jours, même si personne n'a répondu, la décision est considérée comme acceptée par la communauté.

Approbation à la majorité et approbation par consensus

Le vote pour la libération est plus actif: dans ce cas, l'approbation de la majorité des membres de la communauté est nécessaire: trois votes contraignants (de PMC) «pour», et plus de votes «pour» que «contre».
Le consensus est la meilleure option: tous sont en faveur, avec au moins trois PMC.

Veto

Un contributeur qualifié, généralement membre du PMC, peut y opposer son veto. Il vote -1 pour avoir modifié le code et écrit une explication détaillée. Personne ne peut contourner une telle solution de membre PMC. Vous ne pouvez pas opposer votre veto à une version, mais si la modification est très médiocre, par exemple, cela crée une faille de sécurité ou dégrade considérablement les performances, alors PMC peut voter -1. Et tant qu'il ne retire pas son veto, il est impossible d'appliquer la modification.

Méritocratie

Un autre principe proche de la duocratie. Littéralement, «méritocratie» signifie «le pouvoir du digne». En open source, cela signifie que si l'utilisateur, comme le groupe le pense, a fait beaucoup pour la communauté, il est promu committer. Vous pouvez vous demander à quel point cette décision est juste, est-elle toujours absolument honnête et équilibrée? Il s'agit d'une décision extrêmement subjective de tous les PMC de cette communauté. Dans les grandes communautés, comme Apache Ignite, cette politique peut être plus ou moins formalisée. Certaines contributions humaines sont importantes, assurez-vous de participer activement à la newsletter pour les développeurs. Mais la «suffisance» est déterminée individuellement par chaque projet.

Un point important est les qualités humaines du participant. La politique Apache stipule explicitement que l'interaction de la personne avec les autres participants est évaluée, comment elle se comporte si elle n'est pas d'accord avec son opinion. Pour qu'un membre soit promu committer ou PMC, les autres PMC doivent voter sur la liste privée et il ne doit pas y avoir de «non».

Open source et argent

Cette rubrique importante apparaît d'une manière ou d'une autre: comment gagner de l'argent avec les produits Apache Software Foundation. L'organisation fournit la licence la plus conviviale de tout ce qui existe. Vous pouvez vendre des produits basés sur Apache ou une assistance pour les produits Apache, vous pouvez les utiliser dans des produits commerciaux.

Une exigence importante: il doit toujours y avoir une utilisation gratuite des produits Apache. Ils sont gérés indépendamment des intérêts commerciaux. Ceci est surveillé par PMC.

Le commissaire peut recevoir de l'argent d'une organisation tierce pour sa contribution au projet. Le commissaire peut être engagé par un tiers. Récemment, des membres de la communauté ont expliqué dans Habr comment ils travaillaient avec la communauté open source Apache Ignite de Sberbank Technologies. Mais la Fondation Apache ne paie jamais aux committers. Il s'agit d'une position de principe. Pour Apache, le committer est toujours un volontaire et un individu. Autrement dit, la société ne peut pas participer aux projets Apache, un seul développeur peut le faire.

Pourquoi et comment rejoindre l'open source

Pourquoi vaut-il la peine de commencer à contribuer à des projets open source?

C'est une bonne occasion d'améliorer vos compétences et d'acquérir une réputation professionnelle. Les entreprises commerciales apprécient de participer à l'open source. De nombreux développeurs célèbres participent à divers projets, deviennent commissaires et PMC.

Qu'est-ce qui empêche les gens de participer à l'open source?

• "Vous devez être Olympiade ou senior avec 20 ans d'expérience, sinon je ne peux pas le faire." En fait, non. Apache Ignite est un projet complexe, mais même ici, vous pouvez trouver des tâches simples. Par exemple, des tickets et des tâches simples pour rédiger une documentation conçue pour mieux décrire le projet. Nulle part dans Apache cela ne dit que pour devenir un committer, vous devez écrire du code.
• "J'ai besoin d'un anglais courant, sinon je ne peux pas le gérer." Ceux qui participent aux listes de développeurs le confirmeront: là, vous n'avez pas besoin de parler couramment l'anglais. De plus, la communication écrite n'est pas du tout en temps réel, il y a du temps pour réfléchir et écrire une réponse équilibrée.
• «Si j'envoie mon composant en open source, je ne pourrai plus jamais l'utiliser.» Dans Apache, ce n'est pas le cas. Vous pouvez continuer à utiliser votre composant dans un produit commercial, il existera simplement sous la Fondation Apache sous la licence Apache.
• "Tout le monde lira ce que j'écris sur Internet." Même dans la communauté Apache Ignite, tout le monde ne lit pas ce que nous écrivons. C'est comme dans une blague sur l'insaisissable Joe: personne ne peut l'attraper, car personne n'a besoin de lui. Je suis sûr que mes amis et parents ne lisent pas ce que j'écris dans la liste des développeurs, car ils s'en moquent.
• "Cela me prendra tout mon temps libre." C'est en partie vrai: la participation communautaire crée une dépendance. Si vous commencez à participer à la discussion, cela prendra un certain temps. Et à mesure que vous grandissez, il en faudra plus. Plus vous en savez, plus vous en savez, plus vous participez à l'utilisateur et à la liste de développement. Mais, encore une fois, il n'y a aucune obligation envers Apache. Chacun règle sa propre implication. Si vous pouvez créer un patch, créez-en un. Et pourtant, personne ne vous forcera. Même lorsqu'une personne est nommée commissaire, la lettre de proposition indique qu'elle n'est pas tenue d'être plus impliquée que ce qu'elle est prête à donner.

Comment commencer

Si vous souhaitez participer à des projets Apache, vous aurez besoin d'un compte sur Github, d'une boîte aux lettres, d'une inscription dans Apache JIRA et, éventuellement, sur le Wiki . Toute communauté a un article de contribution pour débutants dans Apache Ignite.

Il est bon d'écrire une lettre de salutations: « Bonjour! Je suis tel ou tel. Je veux faire un tel ticket, mon surnom dans JIRA est tel ou tel . " Cette lettre est importante pour attribuer à l'utilisateur le rôle de contributeur.

Listes de diffusion

Pour interagir avec d'autres membres, Apache nécessite l'utilisation de listes de diffusion. J'entends parfois du mécontentement: pourquoi si démodé? Il y a un tas de chats, des messagers instantanés. En effet, chaque membre des projets Apache est bénévole. Il peut avoir sa propre famille, un travail qui n'est pas lié à l'open source, ses hobbies. Il ne peut pas discuter en ligne. Il peut peut-être vérifier le courrier tous les trois jours. Et dans de telles situations, les listes de diffusion fonctionnent très bien.

N'oubliez pas non plus que les membres de la communauté sont dispersés à travers le monde. Et l'homme
à qui vous posez une question, peut-être sur un autre continent et ne répondra que demain.
Par conséquent, la patience et la courtoisie sont ces qualités qui sont très importantes dans la correspondance dans les listes de diffusion. Par exemple, dans la communauté Apache Ignite, les membres expérimentés n'écriront jamais qu'ils ne sont pas d'accord avec vous, ils écriront qu'ils ne sont pas sûrs d'être d'accord.

Exemple de lettre:

Salut, □ □ □ □ D con- sideriticientity, je ne suis pas sûr d'être d'accord, car…

La communauté est plus importante que le code

Un des principes d'Apache: la communauté est plus importante que le code. Cela signifie que la première chose que le projet Apache vise à créer est une communauté autour d'un projet open source. Et puis la magie commence et un bon code apparaît. Si vous n'êtes pas d'accord avec une lettre, reportez-la de 4 heures, relisez-la et remettez-la à nouveau. Il y a alors de grandes chances que vous répondiez avec retenue, sans pousser les autres membres de la communauté avec des mots insouciants. Nous sommes tous des volontaires, et si les gens ne sont pas à l'aise, ils commenceront à partir, et pour un projet open source c'est un risque très sérieux.

Recommandations de correspondance

Ils sont plus ou moins similaires à ceux utilisés dans la correspondance commerciale ordinaire. Si une phrase peut être interprétée de manière incorrecte, elle sera interprétée de manière incorrecte, en particulier compte tenu de la taille de la communauté. Toutes les recommandations se résument à trois principes de base: être positif, constructif et respectueux.

Un exemple d'une lettre pas si bonne:

Salut, □ □ □ □ sdicditez-vous.
Cette solution me semble un peu moche.

Un souhait de ma part en tant que membre de la liste des développeurs: écrire des lettres courtes - trois paragraphes ou 7 phrases. Nous sommes tous des techniciens et souhaitons donner le plus de détails possible. Mais s'il y en a trop, c'est peut-être l'occasion d'écrire un article séparé.

Que passer en contrebande?

Chaque communauté a une liste de ce dont elle a besoin en ce moment. Ignite a une liste de tickets simples. Si vous avez trouvé un bogue pendant l'utilisation et que vous l'avez corrigé dans votre fork, il est tout à fait possible de créer un problème JIRA pour cette entreprise, de faire une demande d'extraction et d'écrire dans la liste des développeurs.

Comment passer en revue le code

Bien que vous soyez nouveau dans la communauté, il est peu probable que vous puissiez déterminer quel ticket est une priorité. Il peut être judicieux de contacter la personne accompagnant le composant, votre aide sera très importante pour lui. Vous pouvez également demander dans la liste des développeurs quels billets sont les plus importants.

S'il n'y a pas de réponse, nous nous souvenons encore une fois que tout le monde est bénévole. Ce pourrait être une bonne idée de vous rappeler ce que vous proposiez de faire dans trois jours.

Dans les projets Apache, y compris Ignite, il n'y a pas de rôle de chef de projet qui surveillerait le backlog, donc des tickets non pertinents peuvent également y être trouvés. Il est recommandé d'écrire d'abord dans la liste des développeurs et de clarifier.

Autre caractéristique d'Apache: dans une entreprise commerciale, il peut exister une politique claire selon laquelle un employé d'un certain niveau peut accéder à la documentation et la modifier, mais pas un employé d'un niveau inférieur. Il n'y a rien de tel dans Apache. S'il y a quelque chose à prêter, pas de problème. Je pense que dans n'importe quel projet, vous n'aurez aucun problème à obtenir des droits d'accès, et peu importe si la personne n'est pas officiellement un committer.

Parlez du projet

La communauté est grandement aidée par les articles sur les produits. La fondation Apache Software elle-même aide aux conférences. Vous pouvez également décrire votre expérience, pas seulement avec Apache Ignite. Cela peut être un cas d'utilisation intéressant, un travail d'étudiant. Ils sont toujours publiés sur la liste des développeurs.