Guides Open Source: Lancement d'un projet Open Source



Préface du traducteur


Il y a quelques mois sur Github, je suis tombé sur le lien "Guides open source" et je n'ai pas pu me détacher. Quelque part en une semaine, j'ai lu attentivement les 10 sections. Bien sûr, je connaissais déjà l'open source: j'ai lu divers articles (par exemple, "Comprendre l'open source" ), utilisé de tels projets dans mon travail, adressé des questions aux communautés, signalé des bugs, résolu des problèmes et même fait des tentatives maladroites pour puis améliorez, au moins la documentation. Et bien sûr, j'étais au cœur de ces gars qui partagent des logiciels et des connaissances sur son utilisation. Cependant, le concept d'open source était plutôt vague et fragmentaire. Et cet article a ajouté de la clarté.

De plus, j'avais quelques projets que je prévoyais de lancer dans ce format, avec l'espoir du soutien de la communauté, et avec de nombreuses craintes et doutes, et encore cet article m'a aidé à établir mes intentions et à suggérer des mesures pratiques.

Quelle que soit votre attitude envers l'open source, je pense que vous trouverez dans cette série de 10 articles de nombreuses idées et faits intéressants: organisationnels, psychologiques, juridiques, éthiques et techniques.

J'ai laissé ce non-programmeur lire ce texte, ils ont dit qu'ils avaient tout compris. Et dans le titre de l'article, j'ai délibérément mis la «source» sans le «code», car ce sujet est pertinent non seulement pour les programmeurs, mais pour presque toutes les activités intellectuelles sous la forme d'un projet ouvert.

Ce manuel lui-même est également open source et a déjà été traduit en 14 langues. J'ai eu l'honneur d'ajouter un fil de discussion russe et une traduction du premier article. Je prévois de continuer à traduire l'article par semaine. Si quelqu'un veut se connecter, voici le référentiel: Guides Open Source .

Si tout à coup quelqu'un a besoin d'un économiseur d'écran du titre de l'article (illustrations + noms russes), alors c'est dans une mise en page sur codesandbox.io .

Sélection des termes


Je m'excuse à l'avance pour les défauts de la traduction. Certains termes apparemment banaux ne sont pas si faciles à saisir en russe. Par exemple, pour contribuer, extraire la demande, émettre, j'ai souvent traduit par "participer au projet, proposer des corrections et une question". Jusqu'à présent, j'ai laissé l'open source en anglais. J'ai déjà fait un commentaire et envoyé un lien vers le dictionnaire des termes de Github . Je n'ai pas aimé l'abondance de translittération là-bas. Si vous mettez dans l'article tous ces éléments, demande de tirage, push, pool, fork, cela deviendra incompréhensible pour tous ceux qui n'ont pas travaillé avec Github.

Oui, le problème peut être une question, une tâche, un rapport de bogue, une phrase, etc., et il est difficile de trouver un mot russe qui transmettrait toutes ces significations. Mais le problème du mot anglais est également sans signification particulièrement large, seuls les créateurs et les utilisateurs de Github l'ont doté d'une telle ampleur. Si nous entendons par les mots "ouvrir une question sur Github" que cette question peut être très différente (bug, question, demande d'aide, tâche, ...), alors le mot "question" remplacera harmonieusement le mot "issue". Aussi - pousser - envoyer, tirer - accepter, fourche - branche, etc. Ce n'est pas le mot lui-même qui compte, mais le sens que nous avons accepté d'y mettre. Les Britanniques, qui sont d'abord tombés sur le terme problème sur Github, doivent également d'abord lire une description de toutes ses significations possibles dans le cadre de ce système.En attendant, je considère la clarté comme une priorité pour le nombre maximum de personnes n'ayant pas travaillé avec Github. Dans tous les cas, la sélection des termes est en cours et la traduction entière, comme l'original, est open source, alors faites des requêtes et ouvrez-la avec ish.


: ?
«open source»?
?
Open source — ?

open source ?



open source

README






, ( ) !






: ?


Alors, pensez-vous lancer votre projet open source? Toutes nos félicitations! Le monde apprécie votre participation. Parlons de ce qu'est l'open source et pourquoi les gens le font.

Que signifie l'open source?


Lorsque le code du projet est ouvert, cela signifie que n'importe qui est libre d'utiliser, d'étudier, de modifier et de distribuer votre projet à n'importe quelle fin. Ces autorisations sont accordées via une licence open source .

L'avantage de l'open source est qu'il réduit les obstacles au choix de votre programme et de votre collaboration, permettant aux gens de distribuer et d'améliorer rapidement les projets. En outre, il donne aux utilisateurs la possibilité de contrôler le code, par opposition à fermé. Une société de logiciels open source (logiciel) peut embaucher quelqu'un pour apporter des améliorations au logiciel, plutôt que de se fier uniquement à la décision du fournisseur open source.

Le logiciel libre fait référence aux mêmes projets quelogiciel open source (l'open source) . Parfois, vous pouvez trouver des combinaisons de ces termes : «Logiciel libre et open source» (logiciel libre et open source FOSS ou logiciel libre, libre et open source FLOSS). Les mots libre et libre ici signifient «gratuit», pas «gratuit» .

Pourquoi les gens ouvrent-ils leur travail?


avatarL'une des plus grandes récompenses que j'ai reçues de l'open source est la relation qui a été établie avec d'autres développeurs qui sont confrontés aux mêmes problèmes que moi.
@ kentcdodds , «Comme c'était génial pour moi d' entrer en Open Source»

Il existe de nombreuses raisons pour lesquelles un individu ou une organisation ouvre la source de son projet. En voici quelques uns:

  • : Open source . , Exercism, 350 .
  • : Open source , . -. WordPress, , b2.
  • Transparence: tout le monde peut vérifier un projet open source pour les erreurs et les incohérences. La transparence est importante même au niveau de l'État. Par exemple, le gouvernement bulgare et les États-Unis ont légiféré sur la transparence pour des secteurs tels que les logiciels bancaires, de santé et de sécurité comme Let's Encrypt .

L'open source s'applique non seulement aux logiciels, mais à tout le reste: des ensembles de données aux livres. Dans la revue GitHub, vous pouvez obtenir plus d'idées sur ce qui peut être trop sensible.

L'open source est-il gratuit?


L'open source gratuite est l'un de ses plus grands avantages, mais pas son seul, mais plutôt un sous-produit de sa valeur combinée.

Puisqu'une licence ouverte implique que n'importe qui peut utiliser, modifier et distribuer votre projet pour presque n'importe quel but, dans la plupart des cas, cela implique gratuitement. Parce que si vous demandiez des frais, les gens téléchargeraient le projet et l'utiliseraient gratuitement, en toute légalité.

Par conséquent, la plupart des projets open source sont gratuits, mais cela n'est pas inclus dans la définition de l'open source. Il existe des moyens de facturer indirectement des projets open source via une double licence ou des fonctionnalités limitées, mais ils sont conformes à la définition officielle de l'open source.

Dois-je lancer mon projet open source?


La réponse courte est oui, car quel que soit le résultat, le lancement de votre projet est un bon moyen de comprendre comment fonctionne l'open source.

Si vous n'avez jamais dirigé de tels projets auparavant, vous pouvez être inquiet: «que diront les gens?», «Et si personne ne le remarquera du tout?» Si cela vous est familier, ne vous inquiétez pas, vous n'êtes pas le seul!

L'open source, comme tout travail créatif, qu'il s'agisse d'écrire ou de dessiner, suscite l'enthousiasme avant de le partager avec le monde. Mais la seule façon de l'améliorer est de pratiquer, même si vous n'avez pas d'audience.

Si vous n'avez pas encore décidé, prenez le temps de réfléchir à vos objectifs possibles.

Fixation d'objectifs


Les objectifs vous aideront à décider sur quoi travailler, sur quoi abandonner et où vous avez besoin d'aide de l'extérieur. Demandez-vous: "Pourquoi est-ce que j'ouvre ce projet?" .

Il n'y a pas de réponse unique à cette question. Vous pouvez avoir plusieurs objectifs pour un même projet, ou différents projets avec des objectifs différents.

Si votre objectif est simplement de montrer votre travail et qu'il n'y a pas besoin de coopération, vous pouvez écrire dans le fichier README. D'autre part, si vous êtes intéressé par les assistants, vous devriez investir votre temps dans la rédaction d'une documentation compréhensible et prendre soin des débutants.
avatar UIAlertView … open source. GitHub. , , . , - . .
mavris@mavris, « : Open Source »

À mesure que le projet se développe, votre communauté aura besoin de plus que du code. Réponses aux questions (problèmes), vérification du code, diffusion d'informations vous concernant - toutes ces tâches sont importantes pour un projet open source.

Bien que le temps passé sur des tâches non programmatiques dépend de la taille et de l'échelle de votre projet, vous devez être prêt à les résoudre vous-même ou à trouver un assistant pour cela.

Si vous faites partie d'une entreprise qui lance un projet open source, assurez-vous à l'avance de disposer de ressources internes pour son développement. Désignez un officier de soutien après le lancement et déterminez comment les tâches seront réparties au sein de la communauté.

Si vous avez besoin d'un budget ou d'un personnel dédié pour faire avancer, faire fonctionner et soutenir le projet, discutez-en dès que possible.
avatarLorsque vous démarrez un projet open source, il est important que les processus de gestion de l'organisation prennent en compte la contribution et les capacités de la communauté qui s'est formée autour du projet. N'ayez pas peur d'impliquer des étrangers, même dans les aspects clés, surtout s'ils sont activement impliqués.
@captainsafia , "Che, voulez-vous ouvrir le code du projet?"

Participation aux projets d'autrui


Si votre objectif est de comprendre comment interagir avec les autres et comment fonctionne l'open source, pensez à participer à un projet existant que vous utilisez et aimez. Votre participation peut être aussi simple que des fautes de frappe et des mises à jour de la documentation.

Si vous ne comprenez pas comment commencer à participer au projet de quelqu'un d'autre, consultez notre guide Comment participer à un projet open source .

Démarrer votre propre projet open source


Il n'y a pas de moment parfait pour ouvrir la source de votre travail. Vous pouvez les ouvrir au stade de l'idée, en cours de travail ou après plusieurs années de fermeture.

En général, vous pouvez ouvrir la source lorsque vous vous sentez suffisamment en confiance pour montrer votre travail à des étrangers et obtenir leurs commentaires.

Chaque projet, quelle que soit l'étape à laquelle vous avez décidé d'ouvrir la source, doit disposer de la documentation suivante:


Ils vous aideront à transmettre vos attentes, à accepter les changements des autres participants et à protéger les droits légitimes de tous les co-auteurs, y compris vous-même. Cela augmente considérablement la probabilité d'une expérience positive.

Si votre projet est sur un github et que vous placez ces fichiers dans la catégorie racine avec les noms recommandés, le github les reconnaîtra et les affichera automatiquement à vos lecteurs.

Choix de licence


Une licence open source garantit que d'autres personnes peuvent utiliser, copier, modifier et apporter des modifications à votre projet sans aucune conséquence. Il vous protège également des situations juridiques désagréables. Vous devez activer la licence lors du démarrage d'un projet open source.

Le travail juridique n'est pas facile. Mais il y a une bonne nouvelle: vous pouvez copier une licence existante et la placer dans votre référentiel, protégeant ainsi votre travail acharné en une minute.

MIT , Apache 2.0 et GPLv3 sont les licences les plus populaires, mais il existe d'autres options parmi lesquelles choisir.

Lorsque vous créez un nouveau projet sur Github, vous avez le choix entre plusieurs licences. En choisissant une licence open source, vous rendrez votre projet ouvert.

Choisissez une licence

Si vous avez d'autres questions ou préoccupations concernant les aspects juridiques de l'open source, nous les avons décrites ici .

Compilation de README


Le fichier README («lisez-moi») explique non seulement comment utiliser votre projet, mais aussi pourquoi il est important et ce que les utilisateurs peuvent en faire.

Essayez de répondre aux questions suivantes dans le fichier README:

  • Que fait ce projet?
  • En quoi ce projet est-il utile?
  • Comment puis-je commencer à travailler avec lui?
  • Où puis-je obtenir de l'aide si nécessaire?

Vous pouvez spécifier dans README: comment participer à votre projet, quels sont ses objectifs, parler de la licence et de la paternité. Si vous ne prévoyez pas d'accepter les améliorations d'autres personnes, ou s'il n'est pas encore prêt à s'exécuter, écrivez simplement à ce sujet.
avatarUne bonne documentation signifie plus d'utilisateurs, moins de demandes d'aide et plus de collaborateurs. (...) N'oubliez pas que vos utilisateurs ne sont pas vous. Il peut s'agir de personnes expérimentées - très différentes des vôtres.
@tracymakes , "Écrivez pour que vos mots soient lus (vidéo)"

Parfois, les gens reportent la rédaction de README parce qu'ils pensent que le projet n'est pas terminé ou ne veulent pas accepter les améliorations des autres. Mais c'est juste une bonne raison d'écrire à ce sujet.

Pour vous inspirer, vous pouvez lire le guide «Make README» ou le modèle README .

Lorsque vous ajoutez le fichier README au répertoire racine du projet, le github l'affiche automatiquement sur la page principale du référentiel.

Rédaction d'un guide pour les participants


Le fichier CONTRIBUTING indique à votre public comment devenir membre de votre projet. Par exemple:


Outre les détails techniques, le fichier CONTRIBUTING est un bon endroit pour exprimer vos attentes concernant la participation des autres. Par exemple:

  • Quel type de participation attendez-vous?
  • Vos plans et vision pour le développement du projet
  • Comment les participants peuvent (et ne peuvent pas) vous contacter

Votre ton chaleureux et amical et vos propositions spécifiques de participation, telles que la rédaction de documentation ou la création d'un site, peuvent être d'une grande importance pour attirer de nouveaux arrivants à travailler sur un projet.

Par exemple, Active Admin commence son guide de participation par ces mots:
Tout d'abord, nous tenons à vous remercier d'avoir envisagé de participer au développement d'Active Admin. Ce sont des gens comme vous qui font d'Active Admin un excellent outil.

Dans les premières étapes d'un projet, votre fichier CONTRIBUTING peut être simple. Vous devez toujours expliquer comment signaler les erreurs et remplir les questions, ainsi que décrire les exigences techniques pour l'édition des membres (par exemple, les tests).

Au fil du temps, vous pouvez le compléter avec des réponses aux questions fréquemment posées. Pour cette raison, moins de gens vous demanderont la même chose encore et encore.

Pour faciliter la compilation d'un fichier CONTRIBUTING, consultez le modèle de guide de collaboration de @ nayafia oumozilla's "Comment compiler le fichier CONTRIBUTING.md" .

Lien vers le fichier CONTRIBUTING dans le fichier README, pour que plus de gens le voient. Si vous placez le fichier CONTRIBUTING.md à la racine de votre projet , le github s'y référera automatiquement lorsque quelqu'un ouvre une nouvelle question (problème) ou ajoute une modification au projet (pull request).

guide de collaboration

Élaboration d'un code de conduite


avatarNous avons tous été confrontés à des situations désagréables lorsque le propriétaire du projet a expliqué grossièrement quelque chose ou que les utilisateurs ont posé des questions de base. (...) Un code de conduite devient un document facile à consulter et qui dit que votre équipe prend très au sérieux un dialogue constructif.
@mlynch , Faire de l'open source un endroit plus heureux

En conséquence, le code de conduite définit les règles de conduite de base pour les participants à votre projet. Ceci est particulièrement important si vous lancez un projet pour une entreprise ou une communauté. Un code de conduite aide à établir un comportement sain et constructif dans la communauté, ce qui réduit le stress pour vous en tant que personne responsable du projet.

Voir plus de détails: Code de conduite - Guide .

En plus de décrire comment vous voulez que les participants se comportent, le code de conduite explique également à qui et quand il s'applique, et ce qui se passera s'il est violé.

Par analogie avec la licence, vous n'avez pas besoin d'écrire le code vous-même, mais vous pouvez copier l'une des options existantes. L'accord des membres est utilisé dansPlus de 40 000 projets open source, dont Kubernetes, Rails et Swift. Quel que soit le code que vous utilisez, vous devez être prêt à l'appliquer si nécessaire.

Placez le fichier CODE_OF_CONDUCT.md à la racine de votre projet, afin qu'il soit plus facile de le rechercher et de le lier, par exemple, à partir de README.

Nommer et personnaliser votre projet


L'image de marque n'est pas seulement un logo accrocheur et un nom mémorable, mais aussi la façon dont vous parlez de votre projet et qui touche votre message.

Choisir le bon nom


Choisissez un nom facile à retenir et, idéalement, donne une idée de l'essence du projet. Par exemple:


Si votre projet est un ajout à un projet existant, utilisez son nom comme préfixe, cela vous aidera à comprendre ce que fait votre projet. Par exemple, node-fetch apporte `window.fetch` à Node.js).

Optez pour la clarté. Les jeux de mots peuvent être amusants, mais pensez à des gens d'autres cultures ou ayant des expériences différentes de la vôtre qui pourraient ne pas comprendre la blague. Vos utilisateurs potentiels peuvent être des employés d'entreprises qui parleront à vos supérieurs de votre projet. Ne les faites pas rougir en même temps.

Conflit de noms


Recherchez les projets open source du même nom , surtout si vous utilisez le même langage ou écosystème. Si votre nom correspond à un projet existant populaire, vous pouvez confondre votre public.

Si vous prévoyez de créer un site Web, Twitter ou toute autre plate-forme de publication, assurez-vous que le nom dont vous avez besoin y est libre. Et il vaut mieux réserver ces noms maintenant pour la tranquillité d'esprit, même si vous ne prévoyez pas encore de les utiliser.

Assurez-vous de ne pas enfreindre la marque de commerce d'une entreprise. À l'avenir, elle pourra vous demander de clore le projet ou même de poursuivre. Il s'agit d'un risque injustifié.

Vous pouvez vérifier le conflit de marque dans la base de données mondiale de l'OMPI sur les marques. Si vous réalisez le projet au nom de l'entreprise, le service juridique peut vous aider .

Enfin, faites une recherche rapide sur Google sur le nom de votre projet. Les gens pourront-ils y retrouver facilement votre projet? Ou peut-être que quelque chose d'indésirable apparaît sur cette demande?

La façon dont vous écrivez (et codez) affecte également votre marque!


Tout au long de la vie du projet, vous écrirez beaucoup: LISEZMOI, guides, documents communautaires, réponses aux questions, peut-être même des newsletters et des listes de diffusion.

Qu'il s'agisse de documentation officielle ou d'un message régulier, votre style d'écriture fait partie de la marque du projet. Pensez à la lumière sous laquelle vous regardez devant le public et si vous avez choisi le bon ton.
avatar , , . , , , , .
@janl, CouchDB, « Open Source»

Un langage gentil et poli créera une atmosphère agréable pour les nouveaux participants. Gardez également un œil sur la simplicité de la présentation, car pour de nombreux lecteurs, l'anglais peut ne pas être natif.

Non seulement les mots que vous écrivez, mais aussi le style du code peuvent faire partie de la marque de votre projet. Angular et jQuery sont deux exemples de projets avec des styles et des recommandations rigoureux.

Il n'est pas nécessaire d'écrire un guide de style lorsque vous débutez, et dans tous les cas, vous voudrez probablement inclure différents styles dans votre projet. Mais vous devez comprendre à l'avance que votre style d'écriture et de code attirera certaines personnes et en repoussera d'autres. Les premières étapes du projet sont l'occasion de créer un précédent à partir duquel le projet se développera sous la forme que vous souhaitez.

Liste de contrôle avant de commencer


Êtes-vous prêt à ouvrir votre projet? Voici une liste de contrôle pour vous aider. Lorsque vous avez vérifié tous les éléments, cliquez sur "publier" et félicitez-vous.

Documentation


  • Il y a un fichier LICENCE open source dans le projet
  • Le projet a une documentation de base (README, CONTRIBUTING, CODE_OF_CONDUCT)
  • Le nom est facile à retenir, donne une idée de l'essence du projet, n'entre pas en conflit avec les projets existants et n'empiète pas sur les marques.
  • La liste des problèmes est à jour, bien organisée et étiquetée.

Le code


  • Le projet utilise des conventions de code convenues et des noms conviviaux de fonctions / méthodes / variables
  • Le code est clairement commenté, les intentions et les cas particuliers sont documentés.
  • Nulle part il n'y a de données sensibles telles que des mots de passe ou d'autres informations non publiques - dans l'historique des révisions, des problèmes (problèmes) et des demandes de révisions (demandes d'extraction).

Gens


Si vous êtes un particulier:

  • Vous avez parlé au service juridique et / ou compris les règles de propriété intellectuelle et les politiques open source de votre entreprise (si vous êtes employé quelque part)

Si vous êtes une personne morale:

  • Vous avez parlé au service juridique
  • Avez-vous un plan marketing pour lancer et promouvoir un projet?
  • Quelqu'un a été nommé responsable de l'interaction avec la communauté: répondre aux questions, vérifier les demandes de tirage et les joindre au projet
  • Au moins deux personnes ont un accès administratif au projet.

Tu l'as fait!


Félicitations pour l'ouverture du code source de votre premier projet! Quel que soit le résultat, travailler à la vue des gens est un cadeau pour la communauté. Chaque demande de validation, de commentaire et de révision est une occasion d'apprendre et de progresser pour vous et les autres.

All Articles