Open Source Code vs Source Code in the Open

Temps lecture : 5 min

Une crise silencieuse agite le monde de l'open source, et elle est pourtant sous nos yeux. Des millions de dépôts sont accessibles publiquement sur GitHub, GitLab et Bitbucket, assortis de licences permissives, leur code étant visible par tous. Mais visibilité ne rime pas avec collaboration. Transparence ne rime pas avec communauté. Et de plus en plus, ce que nous appelons « open source » n'est en réalité qu'un code source ouvert, une réalité fondamentalement différente.

Près des deux tiers des projets GitHub populaires n'ont qu'un ou deux responsables, et moins de 3 % comptent plus de 50 contributeurs. Réfléchissez-y un instant. L'infrastructure logicielle qui sous-tend une grande partie du monde moderne repose sur les épaules de développeurs solitaires ou de très petites équipes. Dans un monde de plus en plus polarisé et géopolitiquement tendu, cette situation est loin d'être confortable.

L'écosystème npm illustre parfaitement ce phénomène. Sur 28 millions de paquets npm publiés, 16 millions ne sont maintenus que par une seule personne, et il ne s'agit pas d'une erreur. Environ 7 millions de projets open source suivis par ecosyste.ms sont en réalité gérés par une seule personne. Et même parmi les paquets les plus téléchargés, la situation ne s'améliore guère : près de la moitié des 13 000 paquets npm les plus téléchargés sont maintenus par une seule personne.

60% des mainteneurs sont des bénévoles. Parmi eux, 61 % travaillent seuls. Certes, leur travail est public, certes, le code est visible. Mais ils ne contribuent pas à la création d'écosystèmes collaboratifs. Ils codent publiquement, devant un public, et non au sein d'une communauté.

Le véritable logiciel libre ne se définit pas par la présence d'un fichier de licence ou d'un dépôt public. Il se définit par une communauté, par la création d'un écosystème où chacun se sent habilité à contribuer, où la diversité des points de vue influence l'orientation du projet et où la maintenance devient une responsabilité partagée.

Pour SCANOSS, c'est un peu comme élever un enfant. Si on résout tous ses problèmes, il devient dépendant, passif et incapable. C'est la même chose dans l'open source. Si un mainteneur s'empresse d'implémenter chaque nouvelle fonctionnalité, corrige chaque bug seul et contrôle tout, il ne construit pas une communauté. Il se crée un public de consommateurs et s'expose à l'épuisement professionnel.

Le véritable open source exige de lâcher prise. Cela signifie créer un espace où d'autres peuvent s'impliquer, faire des erreurs, apprendre et devenir co-responsables.

Le code source ouvert se situe à la croisée de deux mondes. Il ne s'agit pas d'un logiciel propriétaire où tout est verrouillé, mais il ne s'agit pas non plus d'un logiciel véritablement libre. Le code est visible. La licence est ouverte. Les utilisateurs peuvent le dupliquer, l'auditer et l'adapter. Cette transparence est précieuse et ne doit pas être négligée.

Mais la transparence à elle seule ne suffit pas à créer un projet open source. Un véritable projet open source nécessite des voies de contribution claires, des responsables de la maintenance réactifs, des processus de décision documentés et, surtout, une véritable communauté qui partage la propriété du projet. Un code source accessible à tous vous permet d'observer son fonctionnement, mais un véritable projet open source vous ouvre la porte à la participation active.

Voici les erreurs les plus courantes qui transforment ce qui devrait être des projets open source collaboratifs en code source accessible à tous :

1. Suivre la feuille de route de l'entreprise plutôt que les besoins de la communauté
Lorsque le développement est entièrement dicté par des objectifs commerciaux internes, les contributeurs externes le ressentent immédiatement. Leurs demandes tombent dans l'oubli tandis que le responsable du développement travaille sur des fonctionnalités liées à un calendrier d'entreprise.

2. Se précipiter pour tout mettre en œuvre soi-même
Un utilisateur signale un bug ou demande une fonctionnalité, et le responsable du projet s'empresse de le corriger en quelques heures. Cela semble efficace, mais cela révèle autre chose : les contributions ne sont pas nécessaires ici.

3. Absence de lignes directrices sur les contributions
Dire aux gens de « simplement envoyer une pull request » n'est pas une méthode de contribution. Sans instructions de configuration, sans normes de codage, sans attentes en matière de relecture ni processus de contribution clair, les contributeurs potentiels abandonnent avant même d'avoir commencé.

4. Ignorer ou retarder les demandes de fusion externes
Rien n'est plus décourageant que le silence. Un contributeur consacre du temps à une proposition d'action réfléchie, qui reste ensuite sans réponse pendant des semaines, voire des mois, avant d'être fermée automatiquement par un robot.

5. Traiter le projet comme un terrain de jeu personnel
Les changements unilatéraux ou les brusques changements de direction indiquent aux contributeurs que leur contribution est purement décorative.

6. Absence de documentation des décisions ou des processus
Lorsque les décisions sont prises en privé, la communauté est exclue de la gouvernance du projet. Sans documentation accessible, les contributeurs ne peuvent tout simplement pas participer aux décisions qui façonnent le projet.

7. Choisir le mauvais permis
Les licences indiquent qui vous souhaitez voir dans votre écosystème. Une licence restrictive ou inhabituelle peut décourager les entreprises et les contributeurs individuels avant même qu'ils n'essaient.

Alors, à quoi ressemble concrètement la création d'un véritable logiciel libre ? Ce n'est pas une simple liste de contrôle, ni l'inverse de toutes les erreurs courantes. C'est quelque chose de bien plus subtil : un changement de mentalité quant à la place que le logiciel devrait occuper dans le monde.

Le véritable open source commence lorsqu'un responsable décide que le projet n'est plus une activité privée, mais un espace partagé. Cela commence par la reconnaissance que d'autres personnes arriveront avec leurs propres idées, leurs propres styles, leurs propres façons de résoudre les problèmes et que cette diversité n'est pas une perturbation, mais bien l'essence même du projet.

Cela implique aussi d'accepter un rythme plus lent. Le travail collaboratif avance rarement aussi vite qu'un développeur solitaire travaillant à toute vitesse, mais il a tendance à être plus résilient . Plus de regards voient les aspects que vous avez négligés. Plus d'esprits repèrent des schémas que vous n'aviez pas vus. Plus de bras se partagent la charge lorsque la vie vous accapare. L'open source se développe au mieux lorsque les gens comprennent non seulement vos décisions, mais aussi leurs raisons.

Avant tout, la création d'un véritable projet open source repose sur les relations humaines. Le code est important, certes, mais ce sont les personnes qui façonnent la vie d'un projet. La confiance, les petits gestes de générosité et la volonté d'enseigner et d'apprendre sont essentiels. Votre communauté open source est, à bien des égards, votre « guanxi » : le réseau de relations qui soutient votre travail bien au-delà de ce que vous pourriez accomplir seul.

Ce n'est pas toujours idyllique. Cela exige de la patience, de l'humilité et la volonté de lâcher prise sur un projet que l'on a façonné pendant des années. Mais lorsqu'il prend racine, le projet devient bien plus que la somme de ses contributions. Il se transforme en un écosystème vivant, façonné par de nombreuses mains plutôt que par une seule.

Tous les projets n'ont pas besoin de se transformer en une communauté collaborative dynamique. Il arrive qu'un développeur crée un outil pour résoudre un problème personnel, le partage publiquement dans l'espoir qu'il puisse être utile à d'autres, et le maintienne à sa guise. C'est parfaitement légitime. Il s'agit de code source ouvert, et il n'y a rien de mal à cela.

Il faut éviter de confondre cela avec l'open source au sens large. La création d'une communauté requiert des compétences totalement différentes : communication, mentorat, patience et la volonté de ralentir le rythme pendant que les autres apprennent.

Coder seul et publiquement est facile. Créer un logiciel libre, en revanche, est bien plus complexe. Cela implique d'accepter que d'autres prennent des décisions dans des directions différentes des vôtres et d'investir son temps dans les personnes plutôt que dans les fonctionnalités. Mais quand cela fonctionne, les bénéfices sont immenses.

Si vous gérez un projet open source, posez-vous honnêtement la question : encouragez-vous la collaboration ou vous contentez-vous de coder publiquement ? Il n’y a rien de honteux à faire du code publiquement, mais la collaboration recèle un potentiel énorme.

Et si vous utilisez des logiciels libres, sachez faire la différence. Soutenez les mainteneurs qui s'investissent réellement dans la construction de communautés. Contribuez selon vos possibilités. Sachez qu'un dépôt GitHub public sous licence MIT ne donne droit à personne à un travail gratuit illimité ni à un support garanti.

L'open source, dans sa forme la plus aboutie, est un acte de création collectif. C'est la différence entre une fenêtre et une porte : toutes deux offrent une certaine transparence, mais une seule invite à entrer.