Le “quoi” et le “pourquoi” de l’open source

Donc, vous songez à commencer avec l’open source? Toutes nos félicitations! Le monde apprécie votre contribution. Parlons de ce qu’est l’open source et pourquoi les gens le font.

Que signifie “open source”?

Quand un projet est open source, cela signifie que tout le monde peut le voir, l’utiliser, le modifier et distribuer votre projet pour n’importe quel but. Ces autorisations sont appliquées via une licence open source.

L’open source est puissant parce qu’il baisse les barrières à l’adoption, permettant aux idées de se propager rapidement.

Pour comprendre comment cela fonctionne, Imaginez que votre ami a un repas-partage et vous apportez une tarte aux cerises.

  • Tout le monde essaie la tarte (utiliser)
  • La tarte est un succès! Ils vous demandent la recette, que vous transmettez (regarder)
  • Un ami, Alex, qui est un chef pâtissier, suggère de réduire le sucre (modifier)
  • Un autre amie, Lisa, demande de l’utiliser pour un dîner la semaine prochaine (distribuer)

Par comparaison, un processus de source fermer (close source) irait à un restaurant et pour commander une tranche de tarte aux cerises. Vous devez payer des frais pour manger la tarte et le restaurant ne vous donnera pas probablement leur recette. Si vous avez copié leur tarte exactement et l’avez vendu sous votre propre nom, le restaurant pourrait prendre des mesures contre vous.

Pourquoi les gens ouvrent-ils leur travail?

Il existe de nombreuses raisons pourquoi une personne ou une organisation voudrait ouvrir un projet. Certains exemples incluent:

  • Collaboration: Les projets open source peuvent accepter des changements de n’importe qui dans le monde. Exercism, par exemple, est une plateforme d’exercices de programmation avec plus de 350 contributeurs.

  • Adoption et personnalisation: Les projets open source peuvent être utilisés par n’importe qui pour presque n’importe quel but. Les gens peuvent même l’utiliser pour construire d’autres choses. WordPress, par exemple, commencé un fork d’un projet a existant et l’appelé b2.

  • transparence: N’importe qui peut inspecter un projet open source pour des erreurs ou des incohérences. La transparence est importante pour les gouvernements comme la Bulgarie ou les États Unis, réglementation des industries comme la banque ou la santé et des logiciels de sécurité comme Let’s Encrypt.

L’open source n’est pas seulement pour les logiciels. Vous pouvez tout ouvrir, des ensembles de données aux livres. Consultez GitHub Explore pour des idées sur quoi d’autre vous pouvez ouvrir le code.

Est-ce que l’open source signifie “gratuit”?

L’un des plus grands avantages de l’open source est qu’il ne coûte pas de l’argent. “gratuit”, toutefois, c’est une sous-évaluation de la valeur globale de l’open source.

Parce qu’une licence open source exige que n’importe qui puisse utiliser, modifier et partager votre projet pour presque n’importe quel but, les projets eux-mêmes ont tendance à être gratuits. Si le projet coût de l’argent pour l’utiliser, n’importe qui pourrait légalement faire une copie et utiliser la version gratuite à la place.

Par conséquent, la plupart des projets open source sont gratuits, mais “gratuit” ne fait pas partie de la définition de l’open source. Il existe des moyens de facturer les projets open source indirectement grâce à une double licence ou limitées les fonctionnalités, tout en respectant la définition officielle de l’open source.

Dois-je lancer mon propre projet open source?

La réponse courte est oui, parce qu’importe le résultat, lancer votre propre projet est un excellent moyen d’apprendre comment fonctionne l’open source.

Si vous n’avez jamais ouvert un projet auparavant, vous pourriez être inquiets au sujet de ce que les gens diront, ou de toute remarque de n’importe qui. Si cela vous ressemble, vous n’êtes pas seul!

Le travail open source est comme toute autre activité créative, que ce soit l’écriture ou la peinture. Cela peut être effrayant de partager votre travail avec le monde, mais la seule façon de s’améliorer est de pratiquer - même si vous n’avez pas d’audience.

Si vous n’êtes pas encore convaincu, prenez un moment pour penser à vos objectifs.

Définir vos objectifs

Les objectifs peuvent vous aider à déterminer ce sur quoi vous devez travailler, ce que vous devez dire non et où vous avez besoin de l’aide des autres. Commencer par vous demander, pourquoi je rends ce projet open source?

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

Si votre seul but est de mettre en valeur votre travail, vous ne voulez peut-être même pas de contributions et encore dites-le dans votre fichier README. D’un autre côté, si vous voulez vraiment des contributeurs, vous allez investir du temps dans une documentation claire et faire en sorte que les nouveaux arrivants se sentent les bienvenus.

Au fur et à mesure que votre projet grandit, votre communauté peut avoir besoin de plus que du code de votre part. Répondre aux problèmes, passer en revue le code et évangéliser sur votre projet, sont des tâches toutes aussi importantes dans un projet open source.

Bien que le temps que vous consacrez à des tâches de non-codage dépende de la taille et de la portée de votre projet, vous devez être préparé en tant que mainteneur (responsable) pour les résoudre vous-même ou trouver quelqu’un pour vous aider.

Si vous faites partie d’une entreprise qui ouvre un projet, assurez-vous que votre projet à des ressources internes dont il a besoin pour prospérer. Vous voudrez identifier qui est responsable de maintenir le projet après le lancement et comment vous partagerez ces tâches avec votre communauté.

Si vous avez besoin d’un budget ou d’un personnel dédié pour la promotion, les opérations et la maintenance du projet, commencez ces conversations plus tôt.

Contribuer à d’autres projets

Si votre objectif est d’apprendre à collaborer avec les autres ou à comprendre comment fonctionne l’open source, envisagez de contribuer à un projet existant. Commencez avec un projet que vous utilisez déjà et aimez. Contribuer à un projet peut être aussi simple que la correction de coquilles, des fautes de frappe ou la mise à jour de la documentation.

Si vous n’êtes pas sûrs de savoir comment commencer en tant que contributeur, consultez Comment contribuer à l’Open Source.

Lancer votre propre projet open source

Il n’y a pas de moment idéal pour ouvrir votre travail. Vous pouvez ouvrir une idée, un travail en cours, ou après des années une source fermée (close source).

En général, vous devriez ouvrir votre projet lorsque vous vous sentez à l’aise que d’autres voient et de donner leur avis sur votre travail.

Peu importe quelle étape vous décidez d’ouvrir votre projet, chaque projet devrait inclure la documentation suivante:

En tant que mainteneur, ces composants vous aideront à communiquer les attentes, à gérer les contributions et à protéger les droits légaux de chacun (y compris vous). Ils augmentent considérablement vos chances d’avoir une expérience positive.

Si votre projet est sur GitHub, placer ces fichiers dans votre répertoire racine avec les noms de fichiers recommandés aidera GitHub à les reconnaître et à les faire apparaître automatiquement à vos lecteurs.

Choisir une licence

Une licence open source garantit que d’autres peuvent utiliser, copier, modifier et contribuer à votre projet sans répercussions. Il vous protège aussi de situations légales gênantes. Vous devez inclure une licence quand vous lancez un projet open source.

Le travail légal n’est aucunement amusement. La bonne nouvelle est que vous pouvez copier et coller une licence existante dans votre dépôt.

MIT, Apache 2.0, et GPLv3 sont les licences open source les plus populaires, mais il y a d’autres options que vous pouvez choisir.

Lorsque vous créez un nouveau projet sur GitHub, vous avez la possibilité de sélectionner une licence. L’inclusion d’une licence open source rendra votre projet GitHub open source.

Choisissez une licence

Si vous avez d’autres questions ou préoccupations concernant les aspects juridiques de la gestion d’un projet open source, nous vous avons couvert le sujet ici.

Écriture d’un README

Le fichier README fait plus qu’expliquer comment utiliser votre projet. Ils expliquent également pourquoi votre projet est important et ce que vos utilisateurs peuvent en faire.

Dans votre README, essayez de répondre aux questions suivantes:

  • Que fait ce projet?
  • Pourquoi ce projet est-il utile?
  • Comment puis-je commencer?
  • Où puis-je obtenir plus d’aide, si j’en ai besoin?

You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don’t want to accept contributions, or your project is not yet ready for production, write this information down.

Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don’t want contributions. These are all very good reasons to write one.

For more inspiration, try using @18F’s “Making READMEs Readable” or @PurpleBooth’s README template to write a complete README.

When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.

Writing your contributing guidelines

A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:

In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:

  • The types of contributions you’re looking for
  • Your roadmap or vision for the project
  • How contributors should (or should not) get in touch with you

Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.

For example, Active Admin starts its contributing guide with:

First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.

In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.

Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.

For more help with writing your CONTRIBUTING file, check out @nayafia’s contributing guide template or @mozilla’s “How to Build a CONTRIBUTING.md”.

Link to your CONTRIBUTING file from your README, so more people see it. If you place the CONTRIBUTING file in your project’s repository, GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.

Contributing guidelines

Establishing a code of conduct

Finally, a code of conduct helps set ground rules for behavior for your project’s participants. This is especially valuable if you’re launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.

For more information, check out our Code of Conduct guide.

In addition to communicating how you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.

Much like open source licenses, there are also emerging standards for codes of conduct, so you don’t have to write your own. The Contributor Covenant is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.

Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project’s root directory so it’s easy to find, and link to it from your README.

Nommer et Branding de votre projet

Branding is more than a flashy logo or catchy project name. It’s about how you talk about your project, and who you reach with your message.

Choosing the right name

Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:

  • Sentry monitors apps for crash reporting
  • Thin is a fast and simple Ruby web server

If you’re building upon an existing project, using their name as a prefix can help clarify what your project does (for example, node-fetch brings window.fetch to Node.js).

Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don’t want to make them uncomfortable when they have to explain your project at work!

Avoiding name conflicts

Check for open source projects with a similar name, especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.

If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, reserve those names now for peace of mind, even if you don’t intend to use them just yet.

Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk.

You can check the WIPO Global Brand Database for trademark conflicts. If you’re at a company, this is one of the things your legal team can help you with.

Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn’t want them to see?

How you write (and code) affects your brand, too!

Throughout the life of your project, you’ll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.

Whether it’s official documentation or a casual email, your writing style is part of your project’s brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.

Using warm, inclusive language (such as “them”, even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.

Beyond how you write words, your coding style may also become part of your project’s brand. Angular and jQuery are two examples of projects with rigorous coding styles and guidelines.

It isn’t necessary to write a style guide for your project when you’re just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.

Votre check-list de pré-lancement

Ready to open source your project? Here’s a checklist to help. Check all the boxes? You’re ready to go! Click “publish” and pat yourself on the back.

Documentation

Code

People

If you’re an individual:

If you’re a company or organization:

You did it!

Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you’re creating opportunities for yourself and for others to learn and grow.