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
1 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