2022-03-23 - Open-source.md 10KB
Open-source
[en] [En commentaires de l’article]
— But really open-source (as in free) is the misnomer here, it should be called free open-source, or FOSS as some correctly name it.
— That battle has been fought already, and the accepted term is ==“source available”==, not “open source”.*Server-Sent Events: the alternative to WebSockets you should be using* (cache)
Cela fait longtemps que je souhaite aborder ce sujet. Il y a la traditionnelle ambigüité entre « libre » et « gratuit » qui vient d’un quiproquo de traduction-trahison de free en anglais. Mais il y a quelque chose de plus profond entre rendre du code disponible — librement utilisable au sens de sa licence — et le maintenir en vie. Si l’Open-Source c’est de la solidarité entre développeurs
(ce qui est déjà pas mal) et que la distinction avec le logiciel libre (cache) est si floue, toute la différence se situe au niveau des échanges et de leur gouvernance.
Le code en tant que tel, lorsqu’il est publié, est déjà mort. (Comme une pensée écrite mais je digresse.) C’est l’effort qui est mis pour continuer à l’alimenter, à le guider, ensemble, qui est intéressant. Il faut peut-être un nouveau terme pour désigner cela d’ailleurs, je proposerais bien « inclusive-source » avec une définition qu’il faudrait co-définir (pour rester cohérent) mais dont les grandes lignes à titre d’exemple pourraient être :
- le ou la contributeur·ice principal·e participe a moins de 80 % du code ;
- il y a plusieurs administrateur·ices du dépôt principal ;
- les discussions et la gouvernance s’effectuent de manière publique ;
- etc etc.
Il y a très peu de dépôt populaires qui répondent ne serait-ce qu’à ces trois critères. Et c’est tout a fait acceptable. L’importance de créer une catégorie explicite est de pouvoir aussi faire des choix éclairés lors de ses propres contributions, d’avoir le sentiment de s’impliquer pour participer à un bien commun (lâchons les gros mots). Les étoiles Microsoft Github ne sont pas forcément un bon indicateur pour évaluer la santé d’un produit. Et donc sa pérennité.
On voit aussi qu’il est facile de se heurter aux limites de règles strictes/mesurables si on en vient à ajouter des indications du type « l’équipe d’administration est pluriversifiée (cache) » qui seraient pourtant essentielles pour un écosystème sain. Il est beaucoup mentionné en ce moment la notion de réciprocité (pécuniaire) dans l’usage de l’open-source, il y aurait peut-être des choses à creuser pour rendre les attentes explicites à ce niveau, indépendamment de la licence.
Comment arriver à une définition légère et vérifiable ? Dans quel·s espace·s discuter de ces distinctions ? Comment ne pas en faire un label ? Qu’en est-il des questions éthiques ?
Note : au passage je retrouve Inclusive developer qui a 5 ans et où j’écrivais turn open-source into free software (more in a future article)
, c’est maintenant chose initiée.
Le jour même, réaction de Franck au sujet de Dotclear (cache).
Open links
💔 L’examen des propos tenus par leurs employés lors de trois grandes conférences open source révèle une division claire entre, d’un côté, les grands groupes de type Gafam et, de l’autre, les sociétés de taille plus réduite. Face au modèle économique et aux prétentions communautaires des premières, les secondes affichent une vision critique et plus axée sur la soutenabilité des projets. Leurs représentants insistent sur l’importance des licences et du respect des principes « libristes », quand les employés des Gafam répètent que la question ne présente aujourd’hui plus ==guère d’intérêt== pour une majorité de contributeurs.
*Le pillage de la communauté des logiciels libres* (cache)
[en] 💯 Q: Who maintains dataklasses?
A: If you’re using it, you do. ==You== maintain dataklasses.
*dataklasses: A different spin on dataclasses.* (cache)
[en] 💰 If you can make sponsorship happen, great: you should do that. But if not… ==how about reaching out to the maintainers and offering to hire them for an hour-long “consultancy” speaking engagement instead?==
Thanks to the rise of remote working and Zoom, giving a talk no longer requires traveling to a venue—which can easily turn an hour-long opportunity into a full day.
One-off paid speaking opportunities are much more likely to fit into a regular company’s model of how money should spent that monthly donations.
*Support open source that you use by paying the maintainers to talk to your team* (cache)
[en] 🤕 For every issue closed, three new issues showed up. I love open source, but it felt endless and unmanageable. As burnout encroached, I went into self-preservation mode. I did a bit here and there, but sought refuge for my mental health in video games and comic books instead of working nights and weekends. Years went by and having children deleted any concept of spare time. […]
But financials are one part of the sustainable open source equation. ==There’s an emotional cost== to having a publicly available project that hundreds or thousands of people and companies depend on as well.
*Sustaining Maintaining* (cache)
[en] 🍌 This is why I am very careful about how I make “useful” software and release it to the world without any solid way for me to get paid for my efforts. I simply do not want to be in a situation where my software that I develop as a passion project on the side is holding people’s companies together. That’s why I make software how and where I do. Like, no offense, but I really do not want to go unpaid for my efforts. The existing leech culture of ==“Open Source” being a pool of free labor== makes it hard for me to want to have my side projects be actually useful like that unless you pay me.
*“Open Source” is Broken* (cache)
[en] 💍 Starting a company, anytime, anywhere, for virtually anything, is an extra set of commitments on top of being an open source maintainer. It is more like going ==from being engaged to being married== to your project, rather than a free solution to balance maintainer responsibilities with new compensatory income.
*On Paying Open Source Maintainers* (cache)
[en] ⚖️ When you hear rallying cries to fund open source, or complaints that open source maintainers are overburdened and under-thanked, it’s usually due to the misapplication of healthy open source principles. With liberal licenses, open source projects grant a lot of freedom, and that means it’s easy for ==the relationship between maintainers and users to form a toxic imbalance== if they aren’t both careful and vigilant. Just like healthy personal relationships, healthy open source relationships establish clear boundaries and exhibit mutual respect to succeed.
With proper boundaries, a healthier, more helpful community can be fostered; developers and maintainers won’t be over-burdened, companies and other users still get what they need, and expectations and requirements are satisfied on both sides. Establishing boundaries does not have to conflict with the freedoms granted from liberal licenses. And crucially, boundaries can be established without switching licenses.
Too often, we often talk about what open source licenses grant the users. Instead, we should place equal emphasis on what open source licenses grant the developers.
*The Asymmetry of Open Source* (cache)
[en] ⏳ Here is the thing: making a project’s code accessible to any audience is just a small piece of running an open-source project. Take GitHub, for example: you can turn off the issue tracker and turn off project discussions, but you cannot turn off the ability for people to create pull requests. And I get that, the whole “fork it, change it, and submit your changes upstream” culture is a huge part of open source - and one part I really like about (F)OSS projects.
The problem, though, is that reviewing pull requests, paying adequate attention, and providing helpful feedback takes ==a lot of time and energy.== Reviewing code sometimes feels harder than writing code, and I do believe that this is true to a certain extend: you not only have to understand the intentions of the person writing the code, you also have to think about how this new code fits into the existing system and if there are any side-effects that might be tricky to catch from looking at the implementation itself.