L’open source ne signifie pas une communauté publique
(blog.feld.me)- Les logiciels open source pouvaient être distribués avant même les (D)VCS via une page HTML, un fichier txt, une archive tarball sur FTP et une simple adresse e-mail de contact, et restaient open source même sans communauté publique
- Avoir une mailing list ou un canal IRC relevait déjà de la chance, mais les pull requests, les issues, les wikis, une core team ou un Code of Conduct n’ont jamais été des conditions indispensables de l’open source
- Sourceforge a facilité le développement public en proposant presque gratuitement CVS/SVN et des mailing lists, puis git a remporté la compétition des DVCS, ce qui a conduit le monde à converger vers GitHub
- Après GitHub, la maintenance de l’open source s’est transformée en travail non rémunéré avec la gestion des issues, des pull requests hors périmètre, des plaintes, des demandes et même de groupes de discussion, ce qui peut mener au burn-out et à une perte de contrôle
- Un projet n’a pas besoin d’être développé publiquement : on peut désactiver l’issue tracker et les pull requests, utiliser un serveur git bare, et gérer un projet open source seul ou avec un petit groupe de confiance
Le poids de la maintenance après GitHub
- GitHub a donné aux mainteneurs l’impression que l’open source était un travail non rémunéré
- Après avoir géré au travail les tickets, les réunions avec les parties prenantes, la roadmap, la politique interne, les distractions, les échéances, les métriques, les KPI, les changements de besoins, les stand-up, les one-on-one, l’Agile et le Waterfall, on rentre chez soi pour retrouver encore des notifications liées à l’open source
- Les issues s’accumulent, des pull requests arrivent pour repenser le logiciel dans une direction hors du périmètre du projet, et les plaintes comme les exigences augmentent
- Dès qu’apparaissent des groupes de discussion et une « communauté », le mainteneur se retrouve aussi responsable de gérer des personnes impatientes et de répondre individuellement
- Au final, l’open source se transforme en deuxième travail, et le mainteneur peut finir en burn-out tout en perdant le contrôle et la direction de son propre projet
Revenir à un fonctionnement plus simple
- Certains projets sont si vastes et complexes qu’ils exigent une gestion d’équipe, mais ce sont des exceptions, pas le cas général
- Si l’arrivée de nouvelles personnes et de bots d’IA qui captent l’attention vous agace, il est possible de revenir à l’ancienne manière de faire
- On peut désactiver l’issue tracker et les pull requests, ou exploiter un serveur git bare pour publier le code
- Il est aussi possible de travailler avec un petit groupe de personnes que l’on connaît et en qui l’on a confiance, ou même de mener entièrement le projet seul
- Il n’est pas nécessaire de laisser des inconnus envahir son espace, ni d’adopter un Code of Conduct d’apparat ou une politique LLM pour la forme
- Pour être de l’« open source », l’open source n’a pas besoin d’être développé publiquement
- Utilisez les outils que vous voulez, créez ce que vous aimez, faites même un code drop à 2 heures du matin le jour de Noël, sans vous laisser entraîner dans un mode de fonctionnement qui ressemble à un mélange d’incubateur technologique et de garderie
2 commentaires
Avis sur Lobste.rs
C’est pour ce genre de réflexion que https://casuallymaintained.tech/ a été créé, et j’aime beaucoup
L’exemple le plus célèbre est probablement SQLite, qui refuse les contributions externes
C’est une politique raisonnable quand on pense au fait qu’il est utilisé jusque dans des applications critiques comme les avions d’Airbus
SQLite est open source, donc on peut le copier autant qu’on veut et l’utiliser sans restriction, mais ce n’est pas un projet à contributions publiques (open-contribution)
Pour maintenir SQLite dans le domaine public et éviter tout mélange avec du code propriétaire ou sous licence, ils n’acceptent pas les patches de personnes qui n’ont pas soumis une déclaration cédant leur contribution au domaine public
C’est un point de vue assez rafraîchissant
Peut-être que l’auteur a raison, et que nous demandons trop aux mainteneurs
Ce qui est cassé, ce n’est peut-être pas l’open source dans son ensemble, mais l’inflation des attentes quant à ce que l’open source est censé fournir
La dimension sociale de GitHub y contribue peut-être aussi. Plus il y a d’étoiles et d’utilisateurs ordinaires, plus la pression augmente pour satisfaire les nouveaux venus qui regardent le projet
Cela devient particulièrement risqué quand l’intérêt et les demandes de la communauté ne correspondent pas à la vision initiale de la personne qui l’a créé
Article lié : Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
C’est une approche solide, et j’aimerais que davantage de gens l’adoptent par défaut
Construire une communauté ou assumer certaines responsabilités devrait être un acte exceptionnel et intentionnel
Le passage qui qualifie les codes de conduite et les politiques LLM de posture symbolique me paraît un peu à côté de la plaque, mais vu la sensibilité du sujet, je peux comprendre
En revanche, quand on colle ça sur un dépôt tenu par une seule personne, sans utilisateurs, sans communauté et sans intention d’en créer une, là oui, ça devient de l’affichage
Je n’ai pas besoin d’un code de conduite pour moi-même dans un dépôt que j’utilise seul
J’aimerais vraiment que cette discussion prenne de l’ampleur et débouche sur un consensus utile dans la pratique
Il existe de nombreuses façons de créer du logiciel et de contribuer sainement
Elles ne sont simplement pas toujours compatibles entre elles, ni avec les standards élevés de l’open source ; elles impliquent aussi des coûts liés à la visibilité et à la popularité, ou le recours à différents mécanismes comme la licence, l’auto-hébergement ou le refus des contributions de code
J’aimerais qu’on trouve ensemble une bonne voie qui remette le plaisir et l’équité au premier plan dans le logiciel communautaire
L’état décrit dans l’article est la situation naturelle de pratiquement tous les projets open source personnels nouvellement créés par des gens qui ne sont pas célèbres
Nous avons tous un bon nombre de projets qui fonctionnent comme ça
Le problème, c’est que les gens ne savent pas ce qu’ils veulent tirer de leur projet, ou pensent que gérer un projet populaire serait cool sans vraiment mesurer son coût
C’est là que commence la quête d’attention, consciemment ou non
Dire que « GitHub a transformé tout l’open source en emploi non rémunéré pour les mainteneurs » n’est vrai que si on l’autorise
Si l’on retire la vague promesse de notoriété, GitHub a dans la plupart des cas très peu de leviers pour vous faire faire des choses que vous n’aviez pas envie de faire au départ
C’est vrai
J’ai eu autrefois un projet un peu populaire, et ça m’a stressé de devoir gérer des bug reports et des pull requests pour des fonctionnalités que je ne voulais pas
J’aurais aimé pouvoir lire un texte comme celui-ci à l’époque
À voir aussi : https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9
Pour les petits projets, je suis tout à fait d’accord avec cet article
Même pour les projets plus importants, les plus réussis ne commencent souvent pas comme des communautés ouvertes dès le départ
Beaucoup de projets que j’apprécie ont commencé à être développés dans de grandes organisations, et le point clé, c’est que ce logiciel était réellement utilisé activement en interne
Les mainteneurs étaient donc déjà rémunérés
Qu’il s’agisse d’un projet personnel ou d’une équipe interne, le logiciel créé pour résoudre les problèmes quotidiens des développeurs eux-mêmes me paraît plus réussi et moins exploitant que celui conçu avant tout pour la notoriété ou la commercialisation
Réactions sur Hacker News
Même dans les communautés les plus fermées, on peut souvent faire accepter une contribution en envoyant un e-mail poli
Un développeur open source, épuisé par le harcèlement, avait un temps désactivé les pull requests sur son dépôt ainsi que plusieurs fonctionnalités, et s’était forgé à cette période une réputation de personne très difficile
Sans connaître le contexte, j’ai simplement supposé que le projet fonctionnait comme ça à l’origine ; j’ai trouvé son adresse e-mail après quelques recherches et lui ai envoyé un patch officieux dans un message courtois et sans pression, en précisant clairement qu’il pouvait l’utiliser ou l’ignorer
Le développeur m’a répondu pour me remercier, m’a expliqué la situation, est même allé jusqu’à s’excuser pour la gêne occasionnée, en disant qu’il ne savait pas quoi faire d’autre que tout verrouiller, puis il a évidemment intégré la correction
Je pensais que cet article allait parler du problème très répandu des projets de logiciel libre qui imposent Discord pour les discussions ou les signalements de bugs
Pendant une ou deux semaines, il y a eu un certain intérêt pour migrer vers d’autres outils, mais cela semble déjà retombé, et au final tout le monde a l’air d’avoir abandonné pour revenir sur Discord
Discord n’est pas totalement affreux, mais c’est éphémère et ça exige une énorme web app boursouflée
Du point de vue d’un vieux de la vieille, j’aime bien l’attitude de l’auteur
Je suis assez vieux pour me souvenir de l’époque où l’on s’asseyait devant les vétérans d’ARPANET, quand il n’y avait que des 1 et qu’il fallait en tailler la moitié à la main pour en faire des 0
Dans l’ancienne manière de développer des logiciels, les projets étaient en général écrits ou maintenus par une ou deux personnes, et tout Internet connaissait leur adresse e-mail et leur envoyait directement des rapports de bugs
Certains projets se discutaient sur IRC ou sur des mailing lists ; en règle générale, les gens se comportaient de manière professionnelle, sinon ils étaient éjectés de la mailing list ou ajoutés aux fichiers de blocage de iirc et pine
Le point essentiel, c’est qu’à n’importe quel moment, le groupe de développeurs actifs était très réduit
Je parle surtout de petits utilitaires comme make, Sendmail, sed, awk, et jusqu’en 1990 Perl donnait aussi l’impression d’être essentiellement Larry Wall et tchrist
gcc était le contre-exemple complètement fou où des milliers de personnes envoyaient des patchs et où il fallait aussi bien se coordonner avec RMS pour qu’ils remontent upstream
Les nouveaux outils ont de vrais avantages pour permettre à de plus grandes équipes d’interagir en continu, tout comme il y a de grands avantages à rester en petite équipe et à ne pas prêter attention à n’importe qui sur Internet sauf s’il mise un rein sur son patch
Mais cette méthode n’est pas avantageuse pour attirer des gens vers ce qu’on fait ; on peut donc revenir à l’ancienne façon de faire, mais l’équipe sera petite et il sera plus difficile d’attirer des utilisateurs
Cela dit, les utilisateurs n’ont pas leur mot à dire : j’utilise un logiciel pour mon propre cas d’usage, et je le publie en open source juste au cas où cela puisse servir à d’autres
Plus concrètement, l’open source ne promet que quatre libertés fondamentales (https://en.wikipedia.org/wiki/The_Free_Software_Definition)
À part cela, il ne promet littéralement rien, y compris pas la gratuité
Les logiciels libres et open source peuvent être payants et devraient l’être ; ici, “free” ne parle pas d’argent
Je vois plutôt d’un bon œil les récentes attaques sur la “chaîne d’approvisionnement” open source dans diverses communautés, car j’espère, avec optimisme, qu’elles feront comprendre aux gens que l’open source n’est pas une supply chain
Plus de détails ici : https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
Si vous ne payez pas un fournisseur, ou si vous n’avez pas un contrat avec des garanties de calendrier, alors vous n’avez pas de supply chain
Presque toutes les licences FOSS comportent une clause disant que « ce logiciel est fourni sans garantie », et comme une supply chain implique des garanties, le FOSS n’est pas une supply chain
J’en ai assez de voir des gens venir ici traiter « open source » comme si cela portait des « valeurs morales », en y mélangeant des concepts volés au logiciel libre comme si les deux étaient identiques
L’open source, c’est juste les grandes entreprises du logiciel qui prennent à une multitude de bénévoles
Les gens du côté du code de conduite sont juste là pour créer des problèmes
Il suffit de regarder les débats « bouton rouge / bouton bleu » : cette virulence ne s’explique que si les boutons existent vraiment ou si les gens aiment sincèrement se comporter méchamment
Les partisans d’un code de conduite de bonne foi parlent de liberté d’association et de liberté d’expression
La question est de savoir s’il est acceptable qu’une plateforme bannisse quelqu’un simplement parce qu’elle ne l’aime pas, ou s’il faut s’en tenir à la tradition pragmatique des mailing lists consistant à « rester courtois »
Bien sûr, tout dépend de qui détient le pouvoir de décision, mais c’est vrai pour n’importe quel projet
On ne peut pas à la fois exiger de participer au projet de quelqu’un d’autre en posant des conditions contraires à la volonté de sa direction, et revendiquer en même temps la liberté d’association
Si je devais deviner, quand l’auteur dit qu’un « Code of Conduct ostentatoire n’est pas nécessaire », il veut peut-être dire que, pour un petit projet qu’on partage avec le monde tout en gardant seulement l’option d’accepter plus tard des contributions externes, il n’est pas nécessaire de mettre en place un code de conduite avant même d’avoir rencontré une situation concrète
Pas besoin de se torturer l’esprit pour des problèmes purement hypothétiques
S’il existe un code de conduite, c’est parce que l’alternative est soit une punition arbitraire pour des violations arbitraires, soit une anarchie totale de spam
J’ai du mal à comprendre comment ceux qui prêchaient autrefois la netiquette peuvent aujourd’hui être si opposés à la clarté et à des communautés saines
En y repensant, c’est peut-être une Goomba fallacy, et ceux qui méprisent les codes de conduite sont peut-être les mêmes qui passaient les années 1990 sur Usenet à lancer sans fin des flamewars et du spam
L’open source n’est pas un simple choix de licence
C’est une reformulation du logiciel libre pour le rendre plus attractif aux entreprises, et au cœur de l’open source il y a l’idée qu’il est plus efficace pour les entreprises de développer des logiciels en collaborant avec le public plutôt qu’en travaillant à huis clos
L’open source implique donc une communauté ouverte
Si vous voulez simplement jeter du code au public sous une licence permissive sans vouloir de développement collaboratif, bien sûr vous pouvez le faire, et ce code est bien du code open source
Ouvrir le code est une bonne chose et vous n’avez pas l’obligation d’aller au-delà, mais ce n’est pas agir conformément au but pour lequel l’open source a été conçu, et cela ignore une partie de son cœur
Les gens qui voient du code open source et supposent qu’il y a un développement collaboratif ne sont pas irrationnels
C’est le but même du mouvement open source
Même si cette hypothèse ne s’applique pas à votre logiciel, ce n’est pas eux qui enfreignent une norme sociale, c’est vous
Moi, je pense à Stallman, au pilote d’imprimante, au fait que l’utilisateur possède son propre travail ; donc ce genre d’affirmation tranchée sur le but de l’open source me paraît inexacte
https://en.wikipedia.org/wiki/The_Open_Source_Definition
Il n’y est absolument pas question de développement collaboratif
Les gens deviennent émotifs, et prennent souvent soin de nouveaux utilisateurs ou d’utilisateurs qui ne veulent pas apprendre les bases
Il vaut mieux garder une relation séparée du forum de support, mais stricte, réactive et détachée
coreboot ou MrChromebox sont de bons exemples ; il ne répond que lorsque c’est nécessaire
Je suis d’accord, et j’ajouterais qu’il n’est pas non plus nécessaire de créer une page marketing pour convaincre les gens d’utiliser son logiciel
À la place, ou en complément, il peut être utile d’expliquer toutes les raisons pour lesquelles il ne faut pas utiliser ce logiciel
Plus il y a d’utilisateurs, plus il y a de problèmes
Une application FOSS n’a pas besoin d’être distribuée publiquement, c’est juste une attente sociale courante
Être FOSS ne signifie pas non plus que le code doit être fourni à des personnes qui ne sont pas clientes, et c’est le développeur qui décide qui est client
Le FOSS encourage la vente contre rémunération, et vous pouvez même vendre le logiciel gratuit de quelqu’un d’autre (voir https://www.gnu.org/philosophy/selling.en.html)
Un logiciel open source assorti d’une licence non libre reste open source tout en étant non-FOSS, et un développeur n’a pas à avoir honte de choisir une licence open source non libre s’il veut gagner plus d’argent avec son logiciel ou imposer des restrictions supplémentaires à son avantage
Cela peut même être du copyleft
En résumé, nous avons créé LICENSE.md et nous nous y reposons énormément, mais personne n’a pensé à créer SOCIAL.md
Quand quelqu’un dit « open source », beaucoup supposent que « l’auteur fait cela pour les gens, pour la société, pour tout ce qui l’entoure, qu’il se soucie du développement du projet et de l’ajout de nouvelles fonctionnalités, en particulier celles dont j’ai besoin, ainsi que des améliorations au bénéfice de tous les utilisateurs. Sinon, pourquoi le publier ? »
Mais ce n’est que l’attente sociale la plus courante autour du FOSS, et c’est très loin d’être le seul cas possible
L’absence de distinction entre l’open source technique et l’open source social est la cause principale des désaccords, des polémiques, et au final du burn-out provoqué par des attentes sociales mal alignées
Avant, je devais expliquer ce problème et cette différence à des foules en colère, mais j’ai récemment lu un texte de Jeffrey Paul, https://sneak.berlin/20250720/the-agpl-is-nonfree/, qui compare le code open source à un cadeau
Mon explication finissait par devenir : « si le cadeau ne vous plaît pas et ne vous convient pas, jetez-le et oubliez-le »
Il n’existe que quelques licences approuvées par l’OSI que la FSF ne considère pas comme du logiciel libre
Il suffit de consulter la longue liste des licences de logiciel libre incompatibles GPL sur https://www.gnu.org/licenses/license-list.html
En plus, « open source non-FOSS » n’a pas de sens, puisque FOSS signifie littéralement Free and Open Source Software
Aujourd’hui, presque tout arrive directement sur GitHub avec des binaires que n’importe qui peut utiliser, sans avoir à passer par des sites douteux ou des pipelines de build étranges
Pas de « communauté », pas de politique, pas de code de conduite, pas de pull requests ni d’issues, pas de wiki, pas d’équipe cœur : ça ressemble au paradis
J’ai l’impression qu’aujourd’hui il y a trop de communauté au point de nuire au projet lui-même
Mieux encore, je n’arrive pas à me souvenir d’une seule fois où une communauté aurait aidé un projet open source d’une manière ou d’une autre
Si l’objectif est de maximiser le contrôle au détriment de la qualité, très bien
Mais dans ce cas, on peut vraiment se demander si c’est bien du FLOSS que vous recherchez