Qu’est-ce que l’open source, et comment GitHub a-t-il grandi et gagné de l’argent ?

L’open source ne consiste pas simplement à rendre le code source public. C’est une manière d’accorder à d’autres personnes les droits d’utiliser, d’étudier, de modifier et de redistribuer un logiciel selon une licence définie. GitHub est devenu une plateforme commerciale en réunissant ce type de développement collaboratif dans un flux de travail unique pour les dépôts, la gestion de versions, la revue de code et l’automatisation.

Le modèle économique principal de GitHub ne consiste pas à vendre directement des projets open source publics. La plateforme attire une vaste base d’utilisateurs gratuits, puis facture la collaboration privée, les contrôles d’accès, la sécurité, la conformité, l’automatisation, les environnements de développement cloud et les fonctionnalités d’intelligence artificielle dont les entreprises ont besoin.

Table des matières

• La signification précise de l’open source
• Le contexte à l’origine du mouvement open source
• Le fonctionnement du développement open source
• Les différences entre l’open source, Git et GitHub
• Les origines et la croissance de GitHub
• Le modèle de revenus de GitHub
• Pourquoi l’open source gratuit crée de la valeur économique
• Limites et critères d’évaluation

Qu’est-ce que l’open source exactement ?

Un logiciel open source est un logiciel dont le titulaire des droits d’auteur accorde aux utilisateurs, par le biais d’une licence, les droits de l’exécuter, de l’étudier, de le modifier et de le redistribuer. La question essentielle n’est pas simplement de savoir si le code peut être consulté, mais quels droits sont légalement autorisés.

Selon la définition de l’Open Source Initiative (OSI), une licence open source doit permettre la libre redistribution, fournir le code source et autoriser la distribution des modifications et des œuvres dérivées. Elle ne doit discriminer aucune personne, aucun groupe ni aucun domaine d’utilisation. Par conséquent, si des restrictions telles que « utilisation non commerciale uniquement » ou « ne peut pas être utilisé dans des produits concurrents » s’appliquent, il est difficile de considérer le logiciel comme open source au sens habituel, même si son code source est public. OSI의 Open Source Definition↗

Cette distinction est particulièrement importante pour les dépôts publics sur GitHub. Même si un dépôt est visible publiquement par tous, le droit d’auteur s’applique par défaut s’il ne comporte aucune licence open source. D’autres personnes peuvent consulter ou forker le dépôt au sein du service GitHub, mais elles n’obtiennent pas automatiquement le droit de copier, modifier et distribuer librement le code. GitHub explique également qu’une licence énonçant les autorisations d’utilisation est nécessaire pour qu’un projet soit véritablement open source. GitHub의 저장소 라이선스 안내↗

Les trois affirmations suivantes ont donc des significations différentes :

• « Vous pouvez consulter le code » décrit le caractère public ou non du code source.
• « Vous pouvez l’utiliser gratuitement » décrit son prix.
• « C’est open source » décrit les droits accordés par sa licence.

Un logiciel gratuit n’est pas nécessairement open source, et un logiciel open source peut aussi être vendu.

Quel contexte a conduit au mouvement open source ?

La pratique consistant à partager le code logiciel et à l’améliorer de manière collaborative existait dans les premières communautés de recherche en informatique. Toutefois, à mesure que le logiciel est devenu un produit commercial indépendant et que les droits d’auteur et les restrictions d’utilisation se sont renforcés, les préoccupations concernant la capacité des utilisateurs à étudier et à corriger les logiciels se sont également accrues.

Dans les années 1980, Richard Stallman a lancé le projet GNU et le mouvement du logiciel libre. Dans « logiciel libre », « libre » ne renvoie pas au prix, mais à la liberté des utilisateurs d’exécuter, d’étudier, de modifier et de redistribuer un programme, sous sa forme originale ou modifiée. GNU의 자유 소프트웨어 정의↗

Le nom « open source » a été créé lors d’une réunion stratégique tenue peu après l’annonce par Netscape de son intention de publier le code source de son navigateur en 1998. La même année, Eric Raymond, Bruce Perens et d’autres ont fondé l’OSI et structuré l’Open Source Definition à partir des Debian Free Software Guidelines. L’objectif était d’expliquer plus clairement aux entreprises et au public les avantages pratiques du développement collaboratif. OSI 역사↗

Le logiciel libre et l’open source se recoupent largement dans les licences qu’ils acceptent, mais leur accent diffère.

Cette différence ne signifie pas que l’une des deux approches soit toujours supérieure. Elle signifie qu’un même programme peut être expliqué d’un point de vue en mettant l’accent sur les droits des utilisateurs, et d’un autre en soulignant l’efficacité d’un développement transparent et d’une collaboration distribuée.

Comment fonctionne le développement open source ?

L’open source ne signifie pas que « n’importe qui peut modifier le code comme il le souhaite ». La participation peut être ouverte, mais les mainteneurs du projet et les procédures établies déterminent ce qui est intégré dans une version officielle.

Un processus de développement typique se déroule comme suit :

1. Un mainteneur publie le code source, la licence, les instructions d’utilisation et les règles de contribution.
2. Un utilisateur clone ou fork le dépôt afin de créer un espace de travail indépendant.
3. Les corrections de bogues ou le développement de fonctionnalités sont effectués dans une branche distincte.
4. Le contributeur soumet une Pull Request contenant les modifications et leur justification.
5. Les mainteneurs examinent le code, les résultats des tests, l’orientation de conception et l’incidence sur la sécurité.
6. Seules les modifications qui répondent aux critères sont fusionnées dans le dépôt officiel.
7. Une nouvelle version est publiée, et les problèmes découverts par la suite sont de nouveau suivis.

Différents rôles existent dans ce processus. Les utilisateurs emploient le logiciel et signalent des problèmes. Les contributeurs soumettent du code ou de la documentation. Les mainteneurs gèrent les revues et les versions. Un comité de pilotage ou une fondation de projet peut également gérer les marques, les budgets et les règles de décision.

Autrement dit, l’« ouverture » de l’open source ne signifie pas l’absence d’autorité décisionnelle. Les possibilités de participation et les droits d’utiliser le code sont ouverts, tandis que les projets officiels disposent de structures de contrôle destinées à préserver la qualité.

En quoi les licences open source diffèrent-elles ?

Les licences open source peuvent être comprises, dans les grandes lignes, comme des licences permissives et des licences à copyleft.

Licences permissives

MIT, BSD et Apache License 2.0 sont des exemples courants. À condition de respecter certaines exigences, telles que la conservation des mentions de droit d’auteur et du texte de la licence, ces licences autorisent généralement l’intégration de code modifié dans des logiciels propriétaires.

Cela les rend faciles à intégrer par les entreprises dans des produits commerciaux, mais rien ne garantit que le code amélioré reviendra à la communauté d’origine. Apache License 2.0 comprend aussi des dispositions explicites relatives aux brevets ; ses conditions juridiques ne sont donc pas identiques à celles de la licence MIT.

Licences à copyleft

La GNU General Public License (GPL) en est un exemple représentatif. Lorsqu’un code modifié est distribué, ou qu’une œuvre dérivée combinée à ce code est distribuée, elle peut exiger que le code source soit fourni sous la même licence.

Le copyleft n’interdit pas l’usage commercial. Un logiciel peut être vendu commercialement, mais les obligations de divulgation du code source dans le périmètre défini par la licence doivent être respectées. Des variantes telles que la LGPL et l’AGPL sont conçues avec des conditions différentes pour la liaison de bibliothèques et les services réseau.

Lors du choix d’une licence, il ne faut pas la sélectionner simplement parce qu’un projet connu l’utilise. Il convient d’examiner le périmètre de divulgation des œuvres dérivées, les dispositions relatives aux brevets, la fourniture via des services réseau et la compatibilité avec les autres licences.

Quelle est la différence entre l’open source, Git et GitHub ?

Ces trois notions apparaissent souvent ensemble, mais elles interviennent à des niveaux différents.

• Open source est un concept qui décrit les droits d’utilisation d’un logiciel et une méthode de développement collaboratif.
• Git est un programme open source de gestion de versions qui gère de manière distribuée l’historique des modifications de fichiers.
• GitHub est un service commercial qui héberge des dépôts Git en ligne et fournit des fonctionnalités de revue de code, de gestion des problèmes, d’automatisation, de sécurité et de collaboration.

Git a été créé en 2005 après la fin de la relation entre la communauté de développement du noyau Linux et BitKeeper, l’outil propriétaire de gestion de versions distribué. Un outil capable de répondre aux exigences de rapidité, de travail distribué et de très nombreuses branches parallèles d’un projet aussi vaste que Linux était nécessaire. Git 공식 역사↗

Avec Git, chaque développeur peut conserver un dépôt contenant l’historique complet des modifications sans devoir être constamment connecté à un serveur central. Toutefois, Git en ligne de commande seul rendait peu pratique la gestion des personnes proposant une modification, des raisons qui la justifiaient, des personnes chargées de la revue et du moment de sa fusion. GitHub a précisément structuré ce processus collaboratif au moyen d’une interface web.

Git peut être utilisé sans GitHub, et les dépôts peuvent être exécutés sur GitLab, Bitbucket ou des serveurs auto-hébergés. Inversement, GitHub contient non seulement de l’open source, mais aussi du code d’entreprise privé et du code public sans licence. GitHub et l’open source ne sont pas synonymes.

Comment GitHub a-t-il commencé ?

GitHub a été développé autour de Tom Preston-Werner, Chris Wanstrath et PJ Hyett, puis a été lancé comme service public en 2008. Scott Chacon, expert Git devenu plus tard connu comme l’auteur de Pro Git, a également rejoint l’équipe initiale.

Le premier commit dans le dépôt interne de GitHub a été effectué en octobre 2007, et le service a été lancé en avril 2008. Vers son premier anniversaire, GitHub comptait plus de 20 000 dépôts publics et quatre employés à temps plein, sans avoir reçu d’investissement extérieur. GitHub의 첫해 기록↗

Le problème que GitHub visait à résoudre n’était pas simplement le stockage de fichiers. Il cherchait à créer un environnement collaboratif qui visualisait les modifications entre dépôts Git distribués, aidait les développeurs à découvrir le travail des uns et des autres et facilitait la revue des propositions de modification. Le graphe réseau publié par GitHub en 2008 visait également à montrer sur un seul écran les relations entre les branches et les commits de plusieurs utilisateurs. 초기 Network Graph 소개↗

Cette approche a ensuite été appelée « social coding ». Les profils des développeurs, les historiques d’activité, les abonnements, les forks, les étoiles, les problèmes et les pull requests se sont connectés aux dépôts de code, transformant le processus de développement lui-même en un réseau pouvant être recherché et observé.

Pourquoi GitHub a-t-il connu une croissance si rapide ?

La croissance de GitHub ne s’explique pas uniquement par l’offre d’un stockage Git gratuit. Le moment technologique, l’expérience utilisateur, les effets de réseau et un modèle économique d’entreprise ont agi ensemble.

GitHub a rendu compréhensible sur le web le processus de collaboration complexe de Git

Les branches, les commits et les fusions sont de puissantes fonctionnalités de Git, mais elles ne sont pas faciles à comprendre pour les débutants par les seules commandes. GitHub a réuni les différences de code, les discussions, les résultats de revue et l’état des tests dans l’interface des pull requests.

Au lieu de faire circuler des fichiers de correctifs par e-mail, les développeurs pouvaient partager des modifications à l’aide d’un seul lien. Les mainteneurs de projet pouvaient réduire les coûts de revue, car le code et le processus de discussion étaient conservés ensemble.

Les dépôts publics ont créé un réseau de développeurs

Lorsqu’un projet rejoint GitHub, ses utilisateurs et contributeurs sont également plus susceptibles de créer des comptes. Ces utilisateurs créent ensuite d’autres projets ou participent à des projets existants.

À mesure que le nombre de dépôts augmente, les développeurs consultent GitHub pour trouver du code. À mesure que le nombre de développeurs augmente, les mainteneurs de projets choisissent GitHub pour attirer des contributeurs. Il s’agit d’un effet de réseau biface.

Les historiques d’activité publics ont aussi servi de portfolios pour les développeurs. Les entreprises pouvaient examiner le code réel et l’expérience de collaboration des candidats, tandis que les développeurs avaient intérêt à construire un historique d’activité afin d’améliorer leurs opportunités d’emploi et leur réputation.

GitHub a développé simultanément l’open source et les produits d’entreprise

GitHub a abaissé la barrière à l’entrée pour les dépôts open source publics tout en facturant les dépôts privés dès ses débuts. En 2011, la plateforme a lancé GitHub Enterprise, qui pouvait fonctionner sur les serveurs internes des entreprises et répondait aux besoins de celles-ci en matière d’authentification, de sauvegardes et de gestion d’équipe. GitHub Enterprise 출시 기록↗

Cette structure a permis aux développeurs individuels d’apprendre à utiliser GitHub au moyen de projets open source, puis d’utiliser une version d’entreprise du même flux de travail après avoir rejoint une entreprise. Elle a rendu possible une adoption ascendante, les développeurs introduisant le produit dans leurs organisations sans effort commercial distinct auprès des particuliers.

GitHub a déclaré avoir atteint la rentabilité et assuré sa croissance grâce à des services payants sans investissement extérieur, puis avoir levé son premier investissement extérieur en 2012. GitHub의 2012년 투자 발표↗

GitHub a étendu l’offre gratuite et réduit les raisons de migrer vers des services concurrents

En 2019, GitHub a commencé à proposer des dépôts privés aux comptes personnels gratuits. En 2020, la plateforme a aussi supprimé les limites de collaborateurs pour les dépôts privés gratuits et rendu gratuites les principales fonctionnalités d’équipe. Les fonctions avancées de gestion des autorisations, de sécurité et de support requises par les entreprises sont restées payantes. GitHub Free 확대 발표↗

Étendre l’offre gratuite revient à abandonner une partie des revenus d’abonnement à court terme. Toutefois, cela maintient davantage de particuliers et de petites équipes sur la plateforme et crée des occasions de les convertir vers les produits Team, Enterprise, de sécurité et d’IA à mesure que leurs organisations se développent.

Comment l’acquisition par Microsoft a-t-elle influencé la croissance de GitHub ?

Microsoft a convenu d’acquérir GitHub en 2018 pour 7,5 milliards de dollars en actions Microsoft. À l’époque, GitHub déclarait compter plus de 28 millions d’utilisateurs. Microsoft a affirmé que GitHub conserverait des activités indépendantes et son caractère centré sur les développeurs. Microsoft의 GitHub 인수 발표↗

L’acquisition répondait aux besoins stratégiques des deux parties. GitHub pouvait s’appuyer sur une infrastructure cloud mondiale, un réseau de vente aux entreprises et des capacités de sécurité et de conformité. Microsoft pouvait dépasser son ancienne image d’entreprise centrée sur Windows et les logiciels propriétaires, et établir des points de contact avec les développeurs indépendamment du système d’exploitation ou du langage de programmation. L’entreprise a également obtenu des occasions de relier Azure, Visual Studio, VS Code et GitHub.

Après l’acquisition, GitHub s’est étendu au-delà de l’hébergement de dépôts pour devenir une plateforme couvrant l’ensemble du cycle de développement. GitHub Actions automatise les builds, les tests et les déploiements ; Codespaces fournit des environnements de développement cloud ; les produits Advanced Security analysent le code, les dépendances et les secrets ; et Copilot offre des fonctions d’écriture et de revue de code assistées par l’IA.

En octobre 2022, Microsoft a annoncé que GitHub avait atteint 1 milliard de dollars de revenus annuels récurrents (ARR) et dépassé 90 millions d’utilisateurs, soit trois fois plus qu’au moment de l’acquisition. Microsoft FY2023 1분기 실적 발표↗

GitHub a annoncé que plus de 100 millions de développeurs utilisaient la plateforme en 2023 et plus de 180 millions en 2025. En 2025, le nombre total de projets a atteint 630 millions, et GitHub a comptabilisé environ 81,5 % de l’ensemble des contributions comme ayant eu lieu dans des dépôts privés. Cela montre que GitHub est devenu à la fois un espace open source et une infrastructure de développement d’entreprise à grande échelle. GitHub Octoverse 2025↗

Toutefois, ces chiffres sont des indicateurs de plateforme comptabilisés selon les critères propres à GitHub. Le nombre de développeurs inscrits ne doit pas être interprété comme équivalent au nombre d’utilisateurs actifs mensuels ou de clients payants. Microsoft ne divulgue pas non plus chaque année de façon détaillée les revenus et le résultat opérationnel actuels de GitHub en tant qu’unité commerciale autonome ; les 1 milliard de dollars d’ARR annoncés en 2022 doivent donc être considérés comme un indicateur représentatif de taille communiqué à cette date, et non comme le chiffre d’affaires actuel.

Où GitHub gagne-t-il précisément de l’argent ?

Le modèle de revenus de GitHub peut être résumé comme un modèle freemium : il acquiert des utilisateurs grâce à une plateforme publique gratuite, puis facture le contrôle et la productivité dont les organisations ont besoin pour fonctionner.

Abonnements par utilisateur

L’offre gratuite permet aux particuliers et aux petites équipes d’utiliser les fonctionnalités essentielles de dépôt. L’offre Team fournit des fonctions de collaboration avancées, tandis que l’offre Enterprise propose des options de sécurité, de conformité, d’administration centralisée et de déploiement.

Selon la page officielle des tarifs consultée en septembre 2026, Team commence à 4 $par utilisateur et par mois et Enterprise à 21$ par utilisateur et par mois. Les montants réels peuvent varier selon la durée du contrat, la région, les taxes et les conditions applicables aux contrats importants. GitHub 공식 가격표↗

La facturation par utilisateur présente l’avantage que les revenus récurrents peuvent croître avec les effectifs d’une entreprise. Lorsque le code et les processus de travail sont établis sur la plateforme, les coûts de changement augmentent également, ce qui rend les contrats plus susceptibles d’être conservés.

Abonnements aux produits d’IA et facturation selon l’utilisation

GitHub Copilot propose des offres payantes pour les particuliers et les organisations. Les entreprises achètent des licences par utilisateur, et des frais d’utilisation supplémentaires peuvent s’appliquer lorsque l’utilisation de l’IA incluse dans une offre est dépassée. Copilot évolue donc vers un modèle combinant les abonnements logiciels traditionnels et la facturation de l’utilisation des capacités de calcul d’IA. GitHub Copilot 조직 청구 안내↗

Copilot n’ajoute pas seulement une nouvelle source de revenus pour GitHub ; il conduit aussi à consommer l’IA au sein de flux de travail établis impliquant les dépôts, les problèmes, les pull requests et la revue de code. Il est ainsi plus facile de vendre des produits supplémentaires aux clients existants de la plateforme que de vendre un outil d’IA distinct.

Produits de sécurité et de conformité

Les grandes entreprises ne paient pas simplement pour un endroit où stocker du code. Elles ont besoin de contrôles des comptes, de journaux d’audit, d’authentification unique, de détection des secrets, d’analyse des vulnérabilités du code, de gestion de la chaîne logistique et de conformité réglementaire.

À mesure que la dépendance aux composants open source augmente, les organisations doivent analyser en continu les paquets vulnérables et les identifiants divulgués. L’expansion de l’écosystème gratuit accroît paradoxalement également le besoin de produits de sécurité d’entreprise.

Utilisation du calcul, du stockage et de l’automatisation

Des services tels que GitHub Actions, Codespaces et Packages comprennent un certain volume d’utilisation dans une offre et facturent les dépassements. La facture d’une entreprise peut inclure non seulement les licences Enterprise, mais aussi l’utilisation excédentaire d’Actions ou de Codespaces ainsi que des licences supplémentaires pour des produits comme Copilot et les outils de sécurité. GitHub Enterprise 청구 구조↗

Ce modèle permet aux revenus de GitHub de croître à mesure que l’activité de développement augmente. En revanche, GitHub supporte également les coûts des serveurs d’exécution, des dispositifs de stockage, des réseaux et des modèles d’IA ; tous les revenus liés à l’utilisation ne constituent donc pas un bénéfice.

Frais de transaction de la Marketplace

Les développeurs tiers peuvent vendre des applications payantes via GitHub Marketplace. GitHub fournit la gestion des paiements et des abonnements et conserve une part de la valeur des transactions en tant que frais d’exploitation. Selon la documentation officielle, la part conservée appliquée aux transactions d’applications depuis 2021 est de 5 %. GitHub Marketplace 판매 대금 안내↗

Au-delà des frais directs de la Marketplace, le fait que les outils externes se concentrent sur GitHub est également important. À mesure que davantage d’applications sont utilisées, davantage d’outils de développement doivent être remplacés lorsqu’une organisation quitte GitHub, ce qui renforce la capacité de rétention de la plateforme.

Pourquoi l’open source gratuit a-t-il une valeur économique pour GitHub ?

Pour GitHub, les dépôts publics gratuits ne sont pas simplement un poste de coûts. Ils constituent un actif central pour l’acquisition d’utilisateurs et la formation d’un écosystème.

Premièrement, les projets open source attirent de nouveaux utilisateurs. Les développeurs qui veulent utiliser une bibliothèque spécifique, signaler un problème ou soumettre un correctif créent des comptes GitHub. GitHub peut acquérir ces utilisateurs sans dépenses publicitaires.

Deuxièmement, l’activité open source fait de la manière de travailler de GitHub une norme de fait du secteur. Les développeurs apprennent les forks, les problèmes et les pull requests à l’école ou à travers des projets personnels, puis préfèrent la même approche au travail.

Troisièmement, l’écosystème public et le développement privé des entreprises dépendent l’un de l’autre. Les produits privés des entreprises utilisent aussi d’innombrables bibliothèques et outils publics. Dans les données de GitHub pour 2025, la majeure partie de l’activité de contribution s’est produite dans des dépôts privés, tandis que les projets publics étaient majoritaires en nombre de dépôts. L’écosystème public gratuit fournit la base du travail d’entreprise payant.

Quatrièmement, des projets publics plus actifs font augmenter la demande de sécurité et d’automatisation. Les mises à jour de dépendances, la détection de paquets malveillants, la gestion des licences et les tests et déploiements à grande échelle deviennent tous nécessaires.

Le soutien de GitHub à l’open source gratuit est donc difficile à expliquer comme relevant uniquement de la philanthropie ou uniquement de l’activité commerciale. Il apporte une valeur réelle à la communauté des développeurs tout en constituant une stratégie de distribution à long terme menant au marché payant des entreprises.

Comment les entreprises open source gagnent-elles généralement de l’argent ?

Le modèle économique de GitHub est l’un des nombreux modèles de revenus qui exploitent l’open source. Les entreprises open source facturent souvent non pas le code reproductible lui-même, mais la commodité opérationnelle, la responsabilité, la sécurité et l’expertise.

• Support et conseil : elles fournissent le logiciel gratuitement et facturent l’installation, la réponse aux incidents, la formation et le support à long terme.
• Cloud managé : parallèlement à l’open source que les clients peuvent installer eux-mêmes, elles vendent un SaaS qui l’exploite pour le compte du client.
• Open core : elles rendent les fonctionnalités de base publiques tout en proposant sous licences propriétaires des fonctionnalités de gestion d’entreprise, de sécurité et d’analyse.
• Double licence : elles proposent le même code à la fois sous licence open source et sous licence commerciale, permettant aux utilisateurs de choisir selon leur situation.
• Hébergement et utilisation : elles facturent selon l’utilisation du stockage, du réseau, du calcul et de l’exécution de l’automatisation.
• Parrainages et dons : des particuliers, des entreprises et des fondations soutiennent les mainteneurs ou le fonctionnement des projets.
• Certification et formation : elles génèrent des revenus grâce à des formations officielles, des examens, des certifications techniques ou des programmes partenaires.

Ces modèles fonctionnent parce que les coûts logiciels ne se limitent pas au prix de la licence. Les entreprises tiennent compte du coût total de possession, notamment du temps d’installation, du risque d’interruption, des incidents de sécurité, des mises à jour, de la conformité réglementaire et du manque de personnel spécialisé. Même si elles peuvent obtenir le code gratuitement, elles peuvent être disposées à payer pour une responsabilité opérationnelle fiable.

Quelles sont les limites de l’open source et de GitHub ?

L’open source ne devient pas automatiquement un logiciel sûr et durable simplement parce qu’il compte de nombreux participants.

Les charges de maintenance peuvent se concentrer sur quelques personnes

Même une bibliothèque très utilisée peut dépendre de seulement quelques mainteneurs pour les revues et les versions réelles. À mesure que l’utilisation augmente, la charge liée aux signalements de problèmes et à la réponse en matière de sécurité s’accroît, tandis que la rémunération des mainteneurs peut ne pas suivre.

La revue publique ne garantit pas la qualité

Le fait que le code source soit public est différent du fait qu’il ait été suffisamment examiné. Les risques liés à la chaîne logistique incluent les vulnérabilités, les contributions malveillantes, les comptes de mainteneurs compromis et les dépendances contaminées.

Les obligations de licence peuvent être négligées

L’open source n’est pas un bien public libre de droits d’auteur. Les conditions de chaque licence doivent être respectées, y compris la conservation des mentions de droit d’auteur, la fourniture du code source, l’indication des modifications et l’application de la même licence. La compatibilité des licences doit être examinée en particulier dans les produits commerciaux combinant de nombreuses dépendances.

La concentration des plateformes crée de nouvelles dépendances

Parce que Git est distribué, les dépôts peuvent être transférés vers d’autres serveurs. Cependant, migrer intégralement les problèmes, les discussions de pull requests, les workflows Actions, les politiques d’accès, les applications Marketplace et les enregistrements de sécurité est beaucoup plus difficile.

Plus GitHub devient pratique, plus les communautés de développement peuvent dépendre de la tarification, des politiques, de la réponse aux incidents et des changements de fonctionnalités d’une seule entreprise. Il est nécessaire de cloner le code localement, de sauvegarder les versions et la documentation, et de comprendre les dépendances aux fonctionnalités spécifiques de la plateforme.

Quelles sont les idées reçues fréquentes ?

« C’est public sur GitHub, donc c’est open source »

Sans licence, les droits d’utilisation open source ordinaires ne naissent pas. La visibilité et la licence sont des paramètres distincts.

« Tout l’open source est gratuit »

Il peut n’y avoir aucun coût de copie, mais l’exploitation, le support, les services cloud, la formation et les fonctionnalités de sécurité peuvent avoir un coût. Les licences open source n’interdisent pas les ventes payantes.

« N’importe qui peut modifier le code officiel comme il le souhaite »

Le droit pour chacun de modifier sa propre copie est différent de l’autorité permettant d’intégrer des modifications au projet officiel. Les mainteneurs et les règles de gouvernance décident si les modifications sont officiellement incluses.

« GitHub est lui-même open source »

GitHub héberge des projets open source à grande échelle et publie divers outils open source, mais l’ensemble du service GitHub n’est pas un produit open source unique. GitHub est une plateforme commerciale détenue par Microsoft.

« Puisque GitHub a beaucoup d’utilisateurs, la plupart sont des utilisateurs payants »

Les chiffres de développeurs communiqués par GitHub incluent les comptes gratuits. Le total des développeurs inscrits, les développeurs actifs, les clients d’entreprise et les licences payantes sont des indicateurs différents.

« Microsoft exploite GitHub gratuitement »

Bien que les dépôts gratuits soient largement disponibles, GitHub génère des revenus à partir des licences d’entreprise, de l’IA, de la sécurité, de l’automatisation, du calcul, du stockage et de la Marketplace. Les utilisateurs gratuits représentent à la fois un potentiel de conversion en clients payants et une valeur de réseau.

Comment évaluer un projet open source ?

Lors de l’adoption de l’open source dans un projet réel, ne vous limitez pas au nombre d’étoiles ou aux classements GitHub. Examinez ensemble les éléments suivants :

• Le fichier LICENSE et la compatibilité juridique avec l’utilisation prévue
• La fréquence des versions récentes et des mises à jour de sécurité
• Le nombre de mainteneurs principaux et la dépendance à des personnes spécifiques
• La rapidité de revue des problèmes et des pull requests
• L’existence de procédures de test, d’automatisation et de signalement des vulnérabilités
• L’exhaustivité de la documentation et des guides de mise à niveau
• Le personnel et les coûts nécessaires à l’auto-hébergement
• La dépendance à GitHub ou à un service cloud particulier
• Les alternatives disponibles et la faisabilité de migration si le projet est abandonné

Les mêmes principes s’appliquent au choix de GitHub comme plateforme de travail. Plutôt que de comparer uniquement les prix des offres gratuites, évaluez ensemble la gestion des autorisations requise, l’audit, la sécurité, l’utilisation de l’automatisation, l’utilisation de l’IA, l’emplacement des données, la réponse aux incidents et les coûts de migration.

Comment comprendre la relation entre l’open source et GitHub ?

L’open source est un ensemble de règles qui répartit les droits d’utiliser et d’améliorer les logiciels de manière collaborative. Git est un outil de gestion distribuée de l’historique de ces modifications, et GitHub est une plateforme qui sert d’intermédiaire à grande échelle pour la collaboration fondée sur Git.

GitHub n’a pas inventé l’open source. La plateforme a plutôt simplifié, dans un flux de travail web unifié, les processus de découverte, de copie, de discussion, de revue et de fusion nécessaires aux communautés open source. Les projets publics ont créé un réseau de développeurs, et ce réseau a également attiré le développement privé des entreprises vers GitHub.

Par conséquent, au lieu de faire payer un droit d’entrée pour le code public, GitHub a construit un modèle qui facture le contrôle, la sécurité, l’automatisation, le calcul et l’IA dont les entreprises ont besoin pour collaborer à grande échelle. Il a commencé avec un modèle initial où « le public est gratuit et le privé est payant », mais peut désormais être compris comme une entreprise de plateforme de développement dans laquelle « la collaboration de base est gratuite et les fonctionnalités qui résolvent la complexité organisationnelle sont payantes ».