Leadership et gouvernance

Comprendre la gouvernance pour votre projet en croissance

Votre projet prend de l’ampleur, les gens sont mobilisés et vous vous engagez à poursuivre dans cette voie. À ce stade, vous vous demandez peut-être comment incorporer les contributeurs réguliers du projet dans votre flux de travail, que ce soit en donnant à quelqu’un l’accès à la validation ou en résolvant les débats de la communauté. Si vous avez des questions, nous avons des réponses.

Quels sont les exemples de rôles formels utilisés dans les projets open source?

De nombreux projets suivent une structure similaire pour les rôles contributeurs et la reconnaissance.

Qu’est-ce que ces rôles signifient réellement, cependant, est entièrement à vous. Voici quelques types de rôles que vous pouvez reconnaître:

Mainteneur
Contributeur
Committer

pour certains projets, “les mainteneurs” sont les seules personnes dans un projet avec un accès de validation. Dans d’autres projets, il s’agit simplement des personnes répertoriées dans le fichier README en tant que mainteneurs..

Un responsable ne doit pas nécessairement être quelqu’un qui écrit du code pour votre projet. Ce pourrait être quelqu’un qui a fait beaucoup de travail pour votre projet, ou une documentation écrite qui a rendu le projet plus accessible aux autres. Peu importe ce qu’ils font au jour le jour, un responsable est probablement quelqu’un qui se sent responsable de la direction du projet et qui est déterminé à l’améliorer.

Un “contributeur” pourrait être n’importe qui qui commente un problème ou une demande d’extraction, les personnes qui ajoutent de la valeur au projet (qu’il s’agisse de problèmes de tri, d’écriture de code ou d’organisation d’événements) ou toute autre requête fusionnée (peut-être la définition la plus étroite).

Le terme “committer” pourrait être utilisé pour distinguer l’accès à la validation, qui est un type spécifique de responsabilité, d’autres formes de contribution.

Bien que vous puissiez définir vos rôles de projet comme vous le souhaitez, envisager d’utiliser des définitions plus larges encourager d’autres formes de contribution. Vous pouvez utiliser des rôles de leadership pour reconnaître formellement les personnes qui ont apporté des contributions exceptionnelles à votre projet, indépendamment de leurs compétences techniques.

Comment puis-je formuler ces rôles de leadership?

La formalisation de vos rôles de leadership aide les gens à se sentir concernés et indique aux autres membres de la communauté qui chercher de l’aide.

Pour un projet plus petit, la désignation des responsables peut être aussi simple que d’ajouter leurs noms à votre fichier texte README ou CONTRIBUTORS.

ou un plus gros projet, si vous avez un site web, créez une page d’équipe ou listez vos chefs de projet là-bas. Par exemple,Postgres has a comprehensive team page with short profiles for each contributor.

Si votre projet a une communauté de contributeurs très active, vous pouvez former une équipe de responsables, ou même des sous-comités de personnes qui s’approprient différents domaines (par exemple, la sécurité, le tri des problèmes ou la conduite de la communauté). Laissez les gens s’organiser et faire du bénévolat pour les rôles qui les intéressent le plus, plutôt que de les assigner.

Les équipes de direction peuvent vouloir créer une chaîne désignée (comme sur IRC) ou se rencontrer régulièrement pour discuter du projet (comme sur Gitter ou Google Hangout). Vous pouvez même rendre ces réunions publiques afin que les autres puissent les écouter. Cucumber-ruby, par exemple,hosts office hours every week.

Une fois que vous avez établi des rôles de leadership, n’oubliez pas de documenter comment les gens peuvent les atteindre! Établissez un processus clair pour que quelqu’un puisse devenir un responsable ou rejoindre un sous-comité dans votre projet, et l’écrire dans votre GOVERNANCE.md.

Des outils tels que [Vossibility] (https://github.com/icecrime/vossibility-stack) peuvent vous aider à savoir qui contribue (ou non) au projet. Documenter cette information évite la perception de la communauté que les mainteneurs sont une clique qui prend ses décisions en privé.

Enfin, si votre projet est sur GitHub, envisagez de transférer votre projet de votre compte personnel vers une organisation et d’ajouter au moins un administrateur de sauvegarde. GitHub Organizations facilite la gestion des autorisations et des référentiels multiples et protège l’héritage de votre projetshared ownership.

Quand dois-je donner à quelqu’un l’accès de validation?

Certaines personnes pensent que vous devriez donner un accès de commit à tous ceux qui apportent une contribution. Cela pourrait encourager plus de personnes à se sentir propriétaires de votre projet.

D’un autre côté, en particulier pour les projets plus volumineux et plus complexes, vous voudrez peut-être donner uniquement un accès commit aux personnes qui ont démontré leur engagement. Il n’y a pas une bonne façon de le faire - faites ce qui vous rend le plus confortable!

Si votre projet est sur GitHub, vous pouvez utiliser protected branches pour gérer qui peut pousser à une branche particulière, et dans quelles circonstances.

Quelles sont les structures de gouvernance communes pour les projets open source?

Il existe trois structures de gouvernance communes associées aux projets open source.

BDFL: BDFL signifie “Benevolent Dictator for Life”. Sous cette structure, une personne (généralement l’auteur initial du projet) a le dernier mot sur toutes les grandes décisions de projet. Python est un exemple classique. Les projets plus petits sont probablement BDFL par défaut, car il n’y a qu’un ou deux mainteneurs. Un projet qui provient d’une entreprise pourrait également tomber dans la catégorie BDFL.
Méritocratie: (Note: le terme «méritocratie» a des connotations négatives pour certaines communautés et a une histoire sociale et politique complexe.](http://geekfeminism.wikia.com/wiki/Meritocracy).) Dans le cadre d’une méritocratie, les contributeurs actifs du projet (ceux qui font preuve de «mérite») ont un rôle formel dans la prise de décision. Les décisions sont généralement prises sur la base d’un consensus de vote pur. Le concept de méritocratie a été lancé par le Apache Foundation; all Apache projects sont des méritocraties. Les contributions ne peuvent être faites que par des personnes qui se représentent elles-mêmes, et non par une entreprise.
Contribution libérale: Dans un modèle de contribution libérale, les personnes qui font le plus de travail sont reconnues comme les plus influentes, mais cela est basé sur le travail actuel et non sur les contributions historiques. Les grandes décisions de projet sont prises en fonction d’un processus de recherche de consensus (discuter des griefs majeurs) plutôt que d’un simple vote, et s’efforcent d’inclure autant de perspectives communautaires que possible. Exemples populaires de projets qui utilisent un modèle de contribution libérale Node.js est Rust.

Lequel devriez-vous utiliser? C’est à vous! Chaque modèle a des avantages et des compromis. Et bien qu’ils puissent sembler tout à fait différents au début, les trois modèles ont plus en commun qu’ils ne le semblent. Si vous souhaitez adopter l’un de ces modèles, consultez ces modèles:

Ai-je besoin de documents de gouvernance lorsque je lance mon projet?

Il n’y a pas de bon moment pour écrire la gouvernance de votre projet, mais c’est beaucoup plus facile à définir une fois que vous avez vu la dynamique de votre communauté se jouer. La meilleure partie (et la plus difficile) de la gouvernance open source est qu’elle est façonnée par la communauté!

Certaines documentations préliminaires contribueront inévitablement à la gouvernance de votre projet, alors commencez à écrire ce que vous pouvez. Par exemple, vous pouvez définir des attentes claires pour le comportement ou le fonctionnement de votre processus contributeur, même au lancement de votre projet.

Si vous faites partie d’une entreprise qui lance un projet open source, cela vaut la peine d’avoir une discussion interne avant le lancement sur la manière dont votre entreprise prévoit de maintenir et de prendre des décisions concernant le projet. Vous pouvez également expliquer publiquement quelque chose de particulier à la façon dont votre entreprise sera (ou ne sera pas!) Impliquée dans le projet.

Que se passe-t-il si les employés de l’entreprise commencent à soumettre des contributions?

Les projets open source réussis sont utilisés par de nombreuses personnes et entreprises, et certaines entreprises peuvent éventuellement avoir des sources de revenus liées au projet. Par exemple, une entreprise peut utiliser le code du projet comme un composant dans une offre de service commercial.

Comme le projet est de plus en plus utilisé, les personnes qui ont de l’expertise dans ce domaine deviennent de plus en plus demandées - vous pouvez être l’une d’entre elles! - et seront parfois payés pour le travail qu’ils font dans le projet.

Il est important de traiter l’activité commerciale comme normale et comme une autre source d’énergie de développement. Les développeurs payants ne devraient pas recevoir un traitement spécial par rapport aux non-payés, bien sûr; chaque contribution doit être évaluée sur ses mérites techniques. Cependant, les gens devraient se sentir à l’aise de s’engager dans une activité commerciale, et se sentir à l’aise d’énoncer leurs cas d’utilisation lorsqu’ils argumentent en faveur d’une amélioration ou d’une caractéristique particulière.

“Commercial” est complètement compatible avec “open source”. “Commercial” signifie simplement qu’il y a de l’argent impliqué quelque part - que le logiciel est utilisé dans le commerce, ce qui est de plus en plus probable au fur et à mesure qu’un projet est adopté. (Lorsque le logiciel open source est utilisé dans le cadre d’un produit non-open-source, le produit global est toujours un logiciel “propriétaire”, bien que, comme open source, il puisse être utilisé à des fins commerciales ou non-commerciales.)

Comme tout le monde, les développeurs motivés par le commerce acquièrent une influence sur le projet grâce à la qualité et à la quantité de leurs contributions. Évidemment, un développeur payé pour son temps peut être capable de faire plus que quelqu’un qui n’est pas payé, mais c’est bon: le paiement est juste l’un des nombreux facteurs possibles qui pourraient affecter combien quelqu’un fait. Gardez vos discussions de projet axées sur les contributions, pas sur les facteurs externes qui permettent aux gens de faire ces contributions.

Ai-je besoin d’une entité légale pour soutenir mon projet?

Vous n’avez pas besoin d’une entité légale pour soutenir votre projet open source à moins que vous ne manipuliez de l’argent.

Par exemple, si vous souhaitez créer une entreprise commerciale, vous devez créer un C Corp ou LLC (si vous êtes basé aux États-Unis). Si vous ne faites que du travail contractuel lié à votre projet open source, vous pouvez accepter de l’argent en tant que propriétaire unique ou créer une LLC (si vous êtes basé aux États-Unis).

Si vous souhaitez accepter des dons pour votre projet open source, vous pouvez configurer un bouton de don (PayPal ou Stripe, par exemple), mais l’argent ne sera pas déductible d’impôt, sauf si vous êtes un organisme à but non lucratif (501c3, si vous êtes aux États-Unis).

Beaucoup de projets ne souhaitent pas se lancer dans la création d’un but non lucratif, ils trouvent donc un sponsor fiscal à but non lucratif. Un sponsor fiscal accepte les dons en votre nom, généralement en échange d’un pourcentage du don. Software Freedom Conservancy, Apache Foundation, Eclipse Foundation, Linux Foundation et Open Collective sont des exemples d’organisations qui servent de sponsors financiers pour des projets open source.

Si votre projet est étroitement associé à une langue ou à un écosystème donné, il peut également exister une base de logiciel connexe avec laquelle vous pouvez travailler. Par exemple, le Python Software Foundation aide support PyPI, le gestionnaire de paquets Python, et le Node.js Foundation aide support Express.js, le Node-based framework.