Open source

With TensorFlow, when we started to develop it, we kind of looked at ourselves and said: 'Hey, maybe we should open source this.'

Jeff Dean - Google AI Lead.

Master Expert Technologie de l'information EPITECH 2020.

Co-fondateur et CTO d'une startup dans l'Edtech 2019 - fin 2022. (+3 ans)

Formation PSPO-1 Agile Scrum 2022.

Co-fondateur et CTO d'une startup dans la Deeptech fin 2022 - aujourd'hui.

Valentin MONTAGNE

Déroulement du cours

Déroulement des journées

Qu'est-ce que la culture libre ?

La culture libre est un mouvement qui promeut la libre circulation des idées, des œuvres et des connaissances.

Tout le monde devrait pouvoir créer, utiliser, modifier et partager des contenus librement, tout en respectant certains droits d’auteur et de paternité.

Logo du Creative Commons

Les principes de la culture libre

• Accès libre : Les œuvres doivent être accessibles à tous, sans barrières financières ou techniques.
• Partage et collaboration : Les utilisateurs sont encouragés à partager les œuvres et à collaborer pour les améliorer ou les adapter.
• Réutilisation et modification : Les œuvres doivent pouvoir être modifiées, adaptées ou transformées pour créer de nouvelles œuvres.
• Reconnaissance de l'auteur : Les créateurs originaux doivent être crédités, même si leur œuvre est utilisée ou modifiée.

Qu'est-ce que l'Open Source ?

Un logiciel Open Source est un code conçu pour être accessible au public : n'importe qui peut voir, modifier et distribuer le code à sa convenance.

Une approche plus axée sur l'efficacité et l'adoption par les entreprises grâce à la mise en avant de la transparence du développement, collaboration et qualité technique.

Cela permet alors la création de grands projets comme Linux ou Kubernetes ou même VSCode.

Les différences avec le logiciel libre ?

Le logiciel libre est défini par les 4 libertés fondamentales, proposées par la Free Software Foundation (FSF) :

1. Liberté d'exécuter le programme pour n'importe quel usage.
2. Liberté d'étudier le fonctionnement du programme et de le modifier (nécessite l'accès au code source).
3. Liberté de redistribuer des copies.
4. Liberté de distribuer des versions modifiées pour en faire profiter la communauté.

Beaucoup de projets sont à la fois libres et open source (par exemple, Linux ou Firefox).

Les débuts de l'Open Source

Les débuts de l'Open Source se font à l'arrivée de l'ARPANET en 1950-60.

L'apparition des forums ont simplifié les discussions et ont abouti à l'élaboration de normes de collaboration et de communication ouvertes entre 1960 et 1990.

En 1990 à l'arrivée d'internet, la collaboration, l'examen par les pairs, la communication et l'ouverture constituaient déjà ses valeurs de base.

Intelligence collective

Rassurer les utilisateurs

Créer de la notoriété

Pourquoi réaliser un projet Open Source ?

L'Open Source comme stratégie d'entreprise ?

Open Source

Frontend-Only

Système de communauté

(Plugins)

L'Open Source financièrement viable ?

Freemium

SaaS

Formations

Sponsoring

Les responsabilités du mainteneur

Qualité du code et versioning

Merge requests

Roadmap

Différences entre Copyright et Copyleft

Open Source Initiative

L'OSI est une organisation à but non lucratif qui promeut et protège le concept de logiciel open source. Fondée en 1998 par Bruce Perens et Eric S. Raymond.

Se concentre sur la diffusion des logiciels open source au sein des entreprises et des gouvernements. Grâce à elle, des projets open source comme Linux, Apache, et Kubernetes sont devenus des piliers de l'industrie technologique.

La famille BSD

Les licences Berkeley Software Distribution privilégient la simplicité et la liberté maximale, permettant à quiconque d'utiliser, modifier et redistribuer le code, y compris dans des logiciels propriétaires. Elles imposent peu de contraintes.

Conditions minimales :

• Créditez les auteurs originaux.
• Ne pas utiliser le nom des contributeurs pour promouvoir des œuvres dérivées sans autorisation.
• Pas de viralité : Le code sous licence BSD peut être utilisé dans des projets fermés, sans obligation de publier les modifications ou les dérivés.

Exemple : Licence BSD 2 ou BSD 3 avec FreeBSD, OpenBSD, libcurl.

La famille GNU

Les licences GNU, développées par la Free Software Foundation (FSF), sont basées sur l'idée que le logiciel doit rester libre pour tous. Elles imposent des restrictions pour garantir que toutes les œuvres dérivées restent elles aussi libres.

Conditions minimales :

• Toute œuvre dérivée doit être distribuée sous la même licence (GNU GPL). Le code sous GPL ne peut pas être intégré dans des logiciels propriétaires sans violer la licence.
• Viralité : L'utilisation du code sous GPL "contamine" les projets dérivés, qui doivent respecter les mêmes principes avec obligation de fournir le code source des œuvres dérivées.

Exemple : Licence GNU/GPL-2.0 Linux ou encore WordPress.

La license GNU General Public

Les droits :

Utiliser, modifier, distribuer le logiciel.

Les obligations :

Citer les auteurs originaux.

Les contributions au projet sont obligatoirement sous la même license.

Le code source complet doit être partagé durant la distribution.

Responsable du bon suivi de la license à la distribution.

La license MIT

Les droits :

Utiliser, modifier, distribuer le logiciel.

Les modifications et les travaux dérivés ne sont pas obligés d'être sous la même license.

Les obligations :

Citer les auteurs originaux.

Les contributions au projet sont par défaut sous la même license.

Clause de non responsabilité, à l'utilisation l'utilisateur accepte tout risque d'utiliser le logiciel.

La license Apache

Les droits :

Utiliser, modifier, distribuer le logiciel.

Concession de brevets détenu par les contributeurs.

Les modifications et les travaux dérivés ne sont pas obligés d'être sous la même license.

Les obligations :

Citer les auteurs originaux.

Les contributions au projet sont par défaut sous la même license.

Clause de non responsabilité, à l'utilisation l'utilisateur accepte tout risque d'utiliser le logiciel.

Apache permet de fonctionner avec d'autres types de licenses.

La license Mozilla Public

Idem que GNU Public License.

Différences :

Plus souple sur la possibilité d'utiliser plusieurs licenses comparé à GPL, sur le fait de mixer du code propriétaire et lors de la distribution du code source où il n'est pas nécessaire d'y ajouter tous les dérivés.

La license Creative Commons

Les licences Creative Commons sont généralement utilisées pour les œuvres créatives telles que les écrits, les images, la musique, etc.

Les droits :

Utiliser, modifier, distribuer la ressource (ou le logiciel).

Les obligations :

Citer les auteurs originaux.

Linux

Linux ou GNU/Linux est une famille de systèmes d'exploitation Open Source de type Unix fondés sur le noyau Linux créé en 1991.

Très peu adopté pour l'utilisation personnel, c'est dans l'utilisation commercial pour les serveurs ou le système Android que GNU/Linux tire son plus haut taux d'adoption.

Linux

GNU/Linux est un pilier de l'Open Source.

Le projet possède une très grande communauté et ne fait que s'agrandir. Par exemple les récents travaux de Valve avec le Steam Deck pour rendre compatible Linux au monde du jeu vidéo.

Créateur

Linus Benedict Torvalds, né le 28 décembre 1969 à Helsinki en Finlande, est un informaticien américano-finlandais connu notamment pour avoir créé le noyau Linux en 1991 (à 21 ans).

Il continue d'en diriger le développement, étant considéré comme le « dictateur bienveillant à vie » (Benevolent Dictator for Life) de celui-ci. Il a également créé le logiciel de gestion de versions décentralisée Git.

Le but du projet

Indisposé par la faible disponibilité du serveur informatique UNIX de l'université d'Helsinki, Linus entreprend le développement d'un noyau de système d'exploitation, qui prendra le nom de « noyau Linux ».

Il était impossible d'utiliser UNIX directement pour des projets personnels car UNIX était détenu par AT&T sous license commercial, il fallait donc payer pour pouvoir l'utiliser.

C'est plus tard que le projet devient un réel système d'exploitation avec la fusion entre GNU et le noyau Linux.

Pourquoi en faire un projet Open Source ?

Pour compléter le système d'exploitation, Linus a donc passé Linux en license GNU GPL pour être compatible juridiquement avec le projet GNU.

L'ouverture du code source, l'un des quatre critères correspondant à la notion de logiciel libre, a des avantages théorisés entre autres par Eric Raymond, comme la correction rapide des bugs, et notamment la correction des failles de sécurité. C'est le refus du principe de sécurité par l'obscurité.

Les chiffres clés

Plus de 14,846 contributors visible sur le repository Linux.

Plus de 96 % du premier million de serveurs les plus actifs et les plus performants utilisent Linux.

Des 500 supercomputers les plus puissants dans le monde, deux seulement (fonctionnant sous Unix) font exception à cette règle pour l’année 2019.

De même, utilisé par près de 34 % des sites Web selon les chiffres de W3Techs.com.

Business model

• Vente de contrats d'assistance pour un support de qualité.
• Services de conseil et services professionnels liés au logiciel.
• Occasionnellement, mettre en œuvre des fonctionnalités spécifiques du logiciel à la demande et se faire payer pour cela.
• D'autres entreprises, comme IBM avec Linux, utilisent les logiciels "gratuits" pour vendre d'autres biens et services, comme le matériel et l'équipement IBM.
• Un "sponsor d'entreprise" apparaît pour assurer la maintenance et la gestion du logiciel

Pourquoi choisir Linux ?

Pour moi le projet Linux et ses dérivés ont énormément apporté à la communauté Dev et à l'Open Source. C'est obligatoire d'en parler.

En plus de ça, c'est un classique.

Petit bonus, je vous mets une liste awesome de projets Linux ici.

Présentez un projet Open Source important pour vous par groupe de 2 en 10 minutes avec la trame suivante :

• Créateur
• Historique du projet
• Pourquoi utiliser ce projet Open Source ?
• Qu'est-ce que ce projet Open Source ?
• Exemple ou démo.
• Statistiques du projet (Stars, Forks, Taille de la communauté)
• Type de license
• Business model
• Etc...

Sujet unique par groupe, liste d'idée à la prochaine slide.

• Backend : Prisma, Appwrite, Supabase, Insomnia...
• Analytics / Déploiement : OpenReplay, Unleash, Sentry...
• CMS : Strapi, Wordpress, Discourse...
• DevOps : Docker, Terraform ou OpenTofu, Kubernetes...
• Framework : Flutter, Astro, Qwik, Svelte, etc...
• Cloud : Nextcloud, Cloudron...
• Outils : Cal, Jitsi, Visual Studio Code...
• Game engine : Godot Engine

N'hésitez pas si vous avez une autre idée que sur cette liste !

Pourquoi contribuer à l'Open Source ?

Améliorer un projet que vous utilisez

Apprendre et devenir Senior

Rejoindre une communauté

Le cas

Kelsey Hightower

Hightower travaillait dans une petite startup de Portland appelée Monsoon Commerce, au sein de laquelle il a écrit confd, son premier projet open-source.

Il a rejoint CoreOS début 2014, et a commencé à contribuer de manière significative au projet Kubernetes.

Depuis novembre 2015, repéré par Google, il est recruté en tant qu'ingénieur et Developer Advocate dans leur division de cloud computing.

Tout le monde peut contribuer

1. Organiser les évènements de la communauté.
2. Apporter son expertise Design ou UX.
3. Rédiger pour le projet : de la documentation à des tutoriels ou newsletter.
4. Apporter son expertise de développeur ou DevOps.
5. Aider la communauté et review le travail effectué.

Comment s'orienter dans un projet Open Source ?

Chaque projet est différent, de même pour sa communauté. Vous devez vous adapter, comprendre les enjeux du projet. Cela est primordiale pour vous permettre de contribuer correctement au projet !

Certaines caractéristiques sont heureusement communes partout, voyons ensemble les éléments standards d'un projet Open Source.

Les rôles d'un projet Open Source

1. Author - Personne ou l'organisation à l'origine du projet.
2. Owner - Propriétaire administratif de l'organisation/du dépôt.
3. Maintainers - Responsables de la vision et de la gestion des aspects organisationnels du projet.
4. Contributors - Tous ceux qui ont contribué au projet.
5. Membres de la communauté - Les utilisateurs.

Les types de documentation du projet Open Source

1. LICENSE - Obligatoire pour être un projet Open Source.
2. README - Pourquoi le projet est utile et comment commencer.
3. CONTRIBUTING - Explique comment contribuer au projet.
4. CODE_OF_CONDUCT - Fixe des règles de base pour le comportement des membres.
5. Other - Des tutoriels, des guides ou des politiques.

Les outils d'un projet Open Source

1. Issue tracker
2. Pull requests
3. Discussion forums or mailing lists
4. Synchronous chat channel

Comment trouver un projet Open Source ?

GitHub Explore, Open Source Friday, First Timers Only, CodeTriage, 24 Pull Requests, Up For Grabs, First Contributions, SourceSort, OpenSauced

Attention : vérifiez que le projet Open Source est encore actif via la date des derniers commits.

Comment trouver les issues d'un projet Open Source ?

Chaque projet open source dispose d'une page /contribute qui met en évidence des problèmes faciles à résoudre pour les débutants.

Naviguez vers la page principale du dépôt sur GitHub, et ajoutez /contribute à la fin de l'URL.

(Par exemple https://github.com/facebook/react/contribute).

Gérer ou ouvrir une issue

En règle générale, vous devriez ouvrir une issue pour :

• Signaler une erreur que vous ne pouvez pas résoudre vous-même
• Discuter d'un sujet ou d'une idée de haut niveau (par exemple, la communauté, la vision ou les politiques)
• Proposer une nouvelle fonctionnalité ou une autre idée de projet

Si vous gérez une issue, commentez-la pour faire savoir que vous vous en occupez avec le lien de la PR en WIP. Pas de duplication d'effort.

Créer votre Pull Request

1. Clonez le dépôt localement et rester à jour et pour réduire les risques de conflits lorsque vous soumettrez votre PR.
2. Créez une branche pour vos modifications.
3. Faites référence à tous les problèmes pertinents ou à l'issue dans votre PR (par exemple, "Closes #37.")
4. Incluez des captures d'écran de l'avant et de l'après*.
5. Testez vos changements avec les tests existants s'ils existent et créez-en de nouveaux si nécessaire.
6. Respectez les conventions du projet (Coding style, commits, etc).

Vous pouvez même vous entraîner ici, merci Kent C. Dodds !

Github et l'Open Source

Github réalise un énorme travail pour évangéliser l'Open Source à tout type de profil.

Lien vers la documentation Open Source :

https://opensource.guide/

Définir l'objectif du projet

Pourquoi faire ce projet ?

Rendre le projet attractif

Guider les contributeurs

Définir un objectif avec une valeur ajoutée :

Réaliser une librairie de notifications. => Réaliser une librairie de notifications utilisable par tous dans le Web (No depencies, JS Vanilla, Framework agnostic, etc.).

Rappel : les documentations du projet Open Source

1. LICENSE - Obligatoire pour être un projet Open Source.
2. README - Pourquoi le projet est utile et comment commencer.
3. CONTRIBUTING - Explique comment contribuer au projet.
4. CODE_OF_CONDUCT - Fixe des règles de base pour le comportement des membres.

Pourquoi faut-il une license ?

Mettre son projet Github en public ne suffit pas.

Un projet Github en public est certes transparent et lisible par tous, mais est protégé par le droit d'auteur.

L'utilisation, la distribution et l'utilisation commerciale est interdite.

La license permet donc de renoncer sur certains droit de la propriété intellectuelle.

Choisir la license

Il est possible d'utiliser des outils comme choosealicense.com.

La license par défaut : MIT License (Babel, .NET, and Rails use the MIT License.) le plus simple pour être utilisé comme dépendance pour d'autres projets.

La license pour les grandes entreprises : Apache 2.0 qui permet d'avoir le droit pour une entreprise d'exploiter le code malgré les brevets des contributeurs.

La license pour obliger l'Open Source :  GPLv3 qui permet d'éviter à ce que du code privé soit créé depuis du code Open Source.

Écrire un bon README

Il faut répondre aux questions suivantes :

• Que fait ce projet ?
• Pourquoi ce projet est-il utile ?
• Comment puis-je l'installer ?
• Comment puis-je l'utiliser ?
• Où puis-je obtenir de l'aide supplémentaire, si j'en ai besoin ?

Bonus : Comment puis-je configurer / personnalisé le projet ? quelle est la roadmap ? Peut-on contribuer et où sont les indications pour le faire ? Qui sont les auteurs ? Sous quelle license est le projet ?

Écrire un bon CONTRIBUTING

Indiquer à votre public comment participer à votre projet :

• Comment ajouter une issue ou signaler un bug (Modèle pour les issues et bugs)
• Comment suggérer une nouvelle fonctionnalité
• Comment configurer l'environnement de Dev et lancer les tests.

En plus des détails techniques, c'est l'occasion de communiquer vos attentes en matière de contributions, telles que :

• Les types de contributions que vous recherchez
• Votre Roadmap et Vision
• La manière dont les contributeurs vous contactent.

Voici un exemple.

Écrire un CODE_OF_CONDUCT

Le but est de permettre à tous de travailler dans de bonne conditions. Pour cela il faut définir des règles, comme un cadre de travail.

Il faut rester simple et court.

Comme pour les licenses, des modèles de Code of Conduct sont connus comme Contributor Covenant qui est déjà utilisé par plus de 40 000 projets.

Définir le système d'issue

Pour que chaque nouvelle issue suive le même modèle, ajoutez le dossier ISSUE_TEMPLATE à la racine ou dans un dossier .github à la racine.

Créer un fichier .md contenant les propriétés name, about et labels pour permettre à Github de proposer ce choix à la création d'une nouvelle issue.

Créer un fichier config.yml pour personnaliser le choix avec des liens externes par exemple.

Cela donne le résultat suivant.

Définir le système d'issue - 2

Voici le système de labels par défaut de Github.

Mais nous pourrions ajouter les types de labels suivants :

• Par niveau de priorité (low, medium, high ou avec la méthode MOSCOW)
• Par feature (feature-messenger, feature-settings, etc.)
• Par version (v1.0.5, v1.2.4, etc)
• Par plateforme (Linux, Macos, Windows, etc.)

Définir le format des PRs

Pour que chaque nouvelle Pull Request suive le même modèle, ajoutez le fichier PULL_REQUEST_TEMPLATE.md à la racine ou dans un dossier .github à la racine.

Cela donne le résultat suivant.

Et pour la technique ?

Système de documentation

Workflows et versioning

Architecture, convention de commit et de code du repository

Choisir la bonne architecture de repository

Chaque livrable est un repository comme Nextcloud

Un repository contient chaque livrable comme floating-ui

Choisir une convention de commit et de code

Uniformiser

Automatiser

Communiquer

Des conventions pour les commits.

Des linters pour le code.

Choisir la méthode de documentation

Via le code

Via le site web

Via un outil

Il est possible d'utiliser plusieurs méthodes à la fois.

Définir le workflow et le versioning

Git flow comme le Github Flow ou le Trunk-based

Continuous Integration et/ou Continuous Delivery

Des outils pour le versioning

Naming et Branding

Choisissez un nom facile à retenir et qui, idéalement, donne une idée de ce que fait le projet.

• Sentry, un outil de monitoring pour les apps pour centraliser les erreurs.
• Thin, un serveur Ruby simple et rapide.

Il faut aussi vérifier que votre nom n'entre pas en conflit avec d'autres projets et qu'un nom de domaine soit disponible pour votre futur site. (instantdomains.com)

Enfin, n'oubliez pas la communication : les réseaux sociaux, le site internet, votre projet github, votre tone of voice, tout sert votre branding.

Définir la méthode de distribution

Votre projet doit être utilisé par la communauté, pour cela vous devez réfléchir à comment le distribuer :

• Pour une librairie JS on privilégie NPM.
• Pour un logiciel on privilégie le projet github et le site internet.
• Pour un SaaS on privilégie une web app en ligne.

Et pour notre librairie d'alert ?

Ne pas réinventer la roue.

Streaming video avec Jitsi

Réservation avec Cal

Création de site et de blog avec Astro

Comment intégrer un projet Open Source à mon projet ?

La license et la conformité

Qualité et sécurité du code

Vivant et maintenu

Les bonnes pratiques

Citer le projet Open Source dans votre documentation ou site internet.

Citer les parties du projet Open Source dans votre code.

Donner ou devenir sponsor régulier du projet.

Intégrer un projet Open Source à son architecture

CI / CD

Build

Unit and Integration Tests

Review & Staging

Gitlab and Github Actions

Le Workflow en CI / CD

Cloud as a service

AWS, Google Cloud, Azure, Heroku, Vercel...

Externaliser son infrastructure

Automatiser et monitorer le déploiement des applications

Infrastructure as code (IaC)
Terraform

Concentrons-nous sur Github Actions

Historiquement, l'outil qui avait évangélisé la CI / CD est Gitlab.

Créons notre propre pipeline CI / CD :

Validation et tests

Pour débuter, nous utilisons l'example NodeJS sur Github Actions.

Pyramide des tests

Build de l'image Docker

Déployer l'image Docker avec Terraform sur un Cloud Provider

TIPS : ajouter des hooks pour que chaque commit soit propre.

N'hésitez pas à utiliser Docker pour lancer sur votre machine l'outil Open Source.

N'hésitez pas à me donner votre avis.

Merci!