Kenavo l'asso

🇫🇷 – vendredi 19 avril 2024

Mots clés : #AAEE, #ENSSAT, #associatif, #social, #fatigue

Depuis le temps, il faudrait peut être exorciser le truc pour passer à autre chose. Avec le temps, je me rends compte que la ressource la plus précieuse que l'on ait est le temps justement. Temps qui, comme la fatigue, peut être notre ennemi. Et quand on fait de l'associatif, qui est vraiment important en soit si on s'y retrouve et que l'on a l'impression d'être utile, le temps et la fatigue peuvent jouer énormément.

J'ai obtenu mon diplôme d'ingénieur “informatique, multimédia et réseaux” à l'ENSSAT, sur Lannion, école d'ailleurs que je recommande tant pour son équipe éducative, les enseignements, les intervenants extérieurs, le programme et aussi la volonté de toujours faire mieux. C'était en 2015, et j'ai rejoint son association d'anciens élèves en 2016. Si c'était à refaire, je le referais sans hésiter.

L'ENSSAT est une “petite” école d'ingénieur, mais qui bouge et qui grossit. Son association d'anciens élèves, l'AAEE, est aussi de taille modeste. En effet, on est loin de ces très grandes écoles corporatistes, usines à ingénieurs de salon généralistes, avec des réseaux d'anciens énormes, qui parfois ont pour travers de maintenir le réseautage et l'entre-soit. En rejoignant l'association, j'avais envie de m'y investir, de faire des choses pour elle et pour l'école, et aussi de travailler sur ça avec d'anciens élèves, d'anciens camarades, et si ce n'était pas encore le cas, de bons potes. Mais 6 ans après, il était temps d'arrêter, de suivre de loin et de soutenir comme je pouvais, car le temps disponible se faisait rare et l'énergie n'était plus là, alors autant ne pas s'acharner si on a fait sa part. Je n'aime pas l'idée de faire du job protection et de garder sa place au chaud ; si je ne sers à rien, je sors.

En soit, le bilan n'était pas si mal. On a organisé des évènements comme des afterworks dans différentes villes, la traditionnelle rencontre annuelle entre étudiants et anciens, et aussi des brunchs. En plus de ça, du relai d'information aux diplômés, des discussions avec IESF, de la communication sur les réseaux sociaux et d'autres chantiers plus ou moins inachevés. Un autre projet important concernait la caisse de secours que l'on maintenait pour les étudiants en galère, que ce soit pour avancer des frais ou parce que les fins de mois étaient trop difficiles. Ça fait se nouer le ventre, mais ça permet de garder les pieds sur terre. Au moins on en aura aidé et sorti de la galère.

Le sujet de cette caisse de secours était épineux. D'une part des étudiants, une fois diplômés, et avec des situations correctes, malgré les relances, refusaient de rembourser les prêts d'honneur qu'on leur avait octroyés pour les sortir de la merde. On s'est posé la question de passer par un huissier ou une entreprise spécialisée, mais ça nous aurait coûté encore plus d'argent sur un budget serré. Et d'autre part, des diplômés se permettaient de critiquer nos actions ; on se faisait reprocher d'aider des étudiants en galère alors qu'on ne leur payait pas les premiers verres en afterworks, à eux (qui avaient une activité salariée). Peu importe l'école, il y aura toujours de beaux connards.

Un autre sujet pénible était le peu de retours sur nos afterworks. La chose est d'une simplicité dingue pourtant : chercher un bar, convenir d'une date, et venir. Pour ces évènements, on a eu peu de monde par moment, et pour ceux qui ont bien marché il a fallu vraiment insister pour faire venir du monde. Pire encore, des lieux avaient été réservés pour un nombre de personnes ayant accepté de venir, et les entrées étaient bien en dessous des chiffres prévus. Manque de respect et fatigue de voir que des adultes ne sont même pas capables de tenir un engagement ou de prévenir.

On nous a reproché de ne pas être visible sur les réseaux sociaux. Toujours preneurs de remarques et suggestions, on a amélioré la chose : Twitter (pas encore X à l'époque), Instagram, Mastodon, une page publique LinkedIn et une refonte du groupe privé. Même avec ces efforts, pas de retours, pas d'avis, pas d'abonnés. On avait même mis en place un serveur Discord pour favoriser les échanges et le partage d'information, et ça ne décolle toujours pas. Le bilan était décevant, et on ne comprend pas pourquoi ça n'a pas décollé.

On avait aussi pas mal travaillé sur le partage des cours aux anciens diplômés afin de favoriser la diffusion des connaissances. Ce fut une belle galère ; entre les problématiques techniques de la plateforme à choisir et les réticences de certains enseignants, on n'avait finalement pas pu aller bien loin.

L'autre sujet le plus chaud concernait IESF. J'ai une particulière aversion pour les corporatismes de tous bords et de tous poils, qui se contentent d'exister et se tapent sur le ventre à la moindre occasion de rappeler qu'ils sont là. Cette association était pénible et le dialogue était plus que compliqué avec. En même temps, les conseils d'administration de ventres bedonnants et de cheveux blancs semblent bien, bien loin de la réalité du terrain et du métier d'ingénieur ainsi que des associations d'alumni qui ne sont pas assez grosses et prestigieuses pour eux. Déjà, la cotisation à payer tous les ans était exorbitante et représentait une partie énorme de notre budget. Pourtant, les services disponibles en contre-parties ne nous étaient d'aucune utilité. Peut-être que pour de grosses et vieilles associations parisiennes ils l'étaient, mais pour le reste du pays non. Malgré des tractations pénibles ayant réussi à leur arracher une réduction dérisoire de 50 €, l'adhésion était à 500 € par an. Près de la moitié de notre budget pour louer des salles sur Paris à prix réduits, bénéficier du service Labellis pour certifier via blockchains les diplômes, et inscrire les étudiants au Registre National des Ingénieurs (RNI), chasse gardée d'IESF, c'est non. Car oui, même si on a un diplôme d'ingénieur, validé par la CTI, on peut ne pas être dans ce RNI car une association poussiéreuse fait du gate keeping. On a pourtant demandé des métriques sur ces services : qui les utilisent, combien de requêtes sont faîtes, quels types de résultats, bref on voulait savoir dans quoi notre argent allait servir. On n'a jamais eu les chiffres demandés à part des approximations grossières au pifomètre. On nous affirmait que des milliers de requêtes étaient faîtes par mois sur le RNI ; un débugueur de navigateur web nous montrait que la saisie de chaque caractère dans le formulaire de recherche envoyait une requête. Autrement dit, si je saisis mon nom, j'envoie 10 requêtes, de quoi donner des chiffres incroyables ! Outre le fait que l'autocomplétion n'est pas compatible avec l'ecoconception et n'est pas vraiment recommandée dans le RGESN, ce calcul grossier de métriques est ridicule. “Ingénieurs et scientifiques” donc. Les prises de contact en direct n'aboutissaient pas, il fallait les chatouiller sur les réseaux sociaux pour susciter des réactions agacées, mais amenant quand même la possibilité de discuter un peu. Ce ne fut pas utile in fine, mais bon, au moins leur responsable communication s'est donné la peine d'échanger, merci à lui. On avait réussi à remonter le fait qu'IESF était trop franco-parisienne et exclusive, ce qui a mené à une création maladroite d'entités régionales IESF, plus ou moins inféodées à la structure principale, mais pas trop. Dit autrement, pour profiter de IESF Bretagne, il fallait adhérer à IESF Bretagne. Pour profiter d'IESF France, il fallait y adhérer aussi, donc double peine, double adhésion, encore plus de dépenses. Et l'entité nationale ne soutenait pas d'une quelconque manière l'entité régionale, pas la bretonne en tout cas. Bref, quand le budget d'une association est constitué des dons et adhésions de ses membres, c'était dur de justifier ce gaspillage de moyens pour des services rendus inutiles ou dont l’utilité n'était pas démontrée. À la fin, on a finit par se faire exclure, n'ayant pas payé notre dernière cotisation. On nous avait même dit que les temps étaient durs pour eux aussi ; en même temps quand on voyait les bilans en assemblées générales, il aurait été facile d'économiser sur certaines rémunérations, les cocktails et des services payés bien trop chers. Ils nous demandaient même de payer pour avoir le résultat des enquêtes d'insertions des ingénieurs que nous avions nous-mêmes relayés auprès de nos diplômés ! À force de les secouer, nous avions enfin pu avoir un échange entre le président de IESF et la présidente de l'association de l'époque. Mais bon, ils nous auront vite oubliés je pense, à défaut d'avoir vraiment pensé aux petites structures. C'est pas faute d'avoir tenté de rejoindre le poste d'administrateur IESF sans succès.

En plus de ça, les critiques des uns et des autres finissaient par être pénibles à encaisser. Entre les anciens qui critiquent sans s'investir ou comprendre, et les étudiants qui font de même, dur de consolider la diaspora enssatienne et d'en faire quelque chose de chouette. Heureusement que l'on avait quand même des anciens qui étaient là et savaient soutenir au besoin. On sait sur qui on peut compter.

On a eu aussi pour projet de valoriser certains profils de femmes ingénieures, ou encore de faire des témoignages de personnes étant dans de grands groupes, peut-être qu'en flattant les égos ça aurait marché : Saint Gobain, Ubisoft, Arkéa, Cisco et SFR, Airbus Helicopters, Philips, ING, Sagem, VMWare, Decathlon, Google, STMicroelectronics et NXP, Enedis, Betclic, Huawei, Amadeus, Nokia, Microsoft, le CEA, NVIDIA, Oracle, mais aussi à l'époque Intel, Facebook, l'Armée de l'Air et de l'Espace..... Bref il y avait moyen de faire quelque chose. Certains n'ont jamais répondu ou voulu répondre, et quand aux données récoltées et analysées, peu de personnes dans l'association ne voulaient les exploiter et contacter les anciens ayant répondu.

Autre point de crispation, des divergences de point de vue avec certaines instances de l'école. Jusque là, on s'occupait de grossir l'association et de s'affairer à construire la diaspora enssatienne, en reprenant contact avec tout le monde. Mais avec le nouveau conseil de l’époque, il y avait trop de divergence. Les cheveux blancs du monde d'avant préféraient que ce soit l'association qui verse une cotisation à l'école, sans forcément réfléchir aux conséquences que ça avait, et la direction de l'école préférait s'aligner sur les autres établissements en ne soutenant pas la cotisation à IESF.

Concernant les finances, on avait ponctuellement et marginalement du sponsoring d'entreprises locales notamment pour éditer nos annuaires papiers. On a pu creuser le sujet aussi d'être reconnu d'intérêt général ou d'utilité publique, mais les associations d'anciens élèves ne sont pas compatibles avec ces critères. Ainsi, pas de dons défiscalisés possibles, donc peu d'entrées d'argent.

Et à ça s'ajoutent les autres crispations : peu de réponses des diplômés, peu d'investissement d'une partie du conseil d'administration, concours de yakafokonsufide, des critiques de toutes parts... bref il fallait s'arrêter.

Y'avait encore pas mal de choses à faire : faire des interviews des diplômés, chercher des faits marquants des anciens, se rapprocher d'entreprises pour leur parler de la taxe d'apprentissage, mettre à jour le site web, gérer le recouvrement de la caisse de secours, dynamiser l'année avec des évènements dans plusieurs villes... mais trop peu de moyens humains n'étaient mis, même pas un tiers du conseil d'administration à faire tourner la boutique, et faisant partie du reste des personnes actives, ça m'a usé d'en faire autant avec si peu de copains.

C'est con, mais ça fait du bien de se vider la tête une dernière fois pour ne plus y penser. Au moins j'ai gardé de bons potes qui se reconnaitront, le noyau dur du conseil d'administration, les vieux schnocks. J'ai constaté qu'avec d'autres membres du bureau il y avait trop de divergences de points de vue sur la façon de faire, autant partir plutôt que de laisser les relations se dégrader et finir fâchés.

On aurait pu faire tellement plus et bien mieux, mais bon, c'était chouette quand même. Bon courage à celles et ceux qui prendront la suite.

— Dernière mise à jour : mardi 23 avril 2024 —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.

Les pièges de certains composants open source

🇫🇷 – dimanche 9 janvier 2022

Mots clés : #opensource, #FLOSS, #GitHub, #licences, #social

D'ordinaire nous aimons utiliser des bibliothèques tierces dans nos projets, ces “librairies” que l'on retrouve par exemple sur des forges logicielles publiques comme GitHub et GitLab. Rares sont les logiciels qui ne possèdent pas une once de FLOSS (Free Libre and Open Source Software) à l'intérieur. Le plus souvent, on retrouve dans chaque projet des composants FLOSS, que ce soit pour se faciliter la vie, écrire des tests unitaires ou gérer une base de données par exemple. On a vite tendance à prendre l'outil le plus connu, le plus répandu, ou à faire des réflexions trop rapides pour choisir ce dont on a besoin, et pourtant il y a des pièges à éviter.

Tout le monde est juriste, évidement !

Beaucoup (trop) d'entre nous ne considèrent pas suffisamment la licence qui est appliquée à la libraire choisie ; par paresse intellectuelle, par pure fainéantise, par certitude de bien comprendre les licences, par oubli, ou par excès de confiance. On fait tous la boulette, et on en tire des leçons ensuite, ce n'est pas si anormal quand encore aujourd'hui dans les établissements de formation à l'ingénierie logicielle ou “les écoles de codage” on en parle assez peu, ou pas assez, voire pas du tout. Merci les formations au rabais vendeuses de rêves laissant leurs apprenants se fracasser sur le mur de la réalité.

Toutefois, parmi les pièges dans lesquels chacun et chacune peuvent plonger, il y en a particulièrement qui sont beaux. Et grossiers. Et pourtant, beaucoup de personnes se font avoir, et ne finissent par réagir que lorsque le sujet est médiatisé. Avant de se jeter sur le dernier composant à la mode, regardons en détails les pièges, en commençant par les licences évidemment.

Des clauses déloyales dans les licences

Par exemple, il y a quelques années, on pouvait trouver les frameworks React de Facebook / Meta sous une curieuse licence “BSD + Patents”. Le truc, c'est que cette licence possède des clauses relatives aux brevets (une vague idée ici). Si j'exagère et grossis les choses, le fait de chercher des noises en justice à Facebook à l'époque pouvait faire tomber le droit que vous aviez d'utiliser ses cadriciels (j'adore ce mot). Pot de terre contre pot de fer dans du béton armé, embêter Big F peut revenir à vous interdire d'utiliser ses technos, donc à retirer beaucoup de produits. Une fois la chose médiatisée, finalement Facebook changea son fusil d'épaule et utilisa la licence MIT.

Bref, attention aux clauses déloyales des licences !

Des changements radicaux de licences

Récemment encore, c'est HashiCorp qui changea brutalement la licence de son produit phare nommé Terraform, et l'entreprise est dans son bon droit. Le passage de la licence MPL 2.0 à la Business Source License a été fait avec fracas, justifié maladroitement par l'entreprise et décrié par la communauté open source. MongoDB a eu droit aussi auparavant à son concert de casseroles avec le passage à la SSPL. Pour aller plus loin, MariaDB propose cette page de FAQ sur la BSL. Benoit Sibaud (un chouette collègue chez Orange !) a rédigé et diffusé un billet abordant les “virevoltantes valses de licences libres et non libres dans les bases de données”, très instructif ! En d'autres termes, attendez-vous à peut-être voir des revirement de situations dingues sur les licences appliquées !

Le truc, c'est que quand bien même une entreprise décide d'agir ainsi, elle reste tout de même légalement dans l'obligation de satisfaire les demandes qui concernent les licences anciennement appliquées. Autrement dit, si à un instant T un composant C était sous une licence libre L (admettons GPL 3.0), mais que plus tard cette licence passe à une bullshit licence BL, si vous avez eu le composant sous licence L vous êtes en droit de demander les sources (si L l'autorise évidement), même si elles ne sont pas accessibles publiquement. Bon courage donc.

On peut ainsi imaginer jouer la prudence, et se dire que si on utilise des composants FLOSS, dans le doute, au cas où, on pourrait garder une copie du code source. J'apprécie beaucoup cet article de Geoffrey Dorme qui vous donnera davantage de motivations à le faire. En plus cloner les dépôts Git d'une organisation GitHub c'est facile pour l'instant.

Imaginez maintenant, malgré les trahisons précédentes, que certaines technos soient si répandues qu'elles en deviennent presque indispensables pour des entreprises, au hasard les frameworks comme React. Rien n'empêche Facebook / Meta du jour au lendemain de changer la licence, de rendre l'exploitation de l'outil payante, et de monter un vrai business model dessus. Un magnifique coup à jouer maintenant que le place est faite dans l'écosystème logiciel. Impossible ? C'est vite oublier le ramdam lorsque Oracle avait mis en place son JDK payant.

Mais il y a d'autres pièges plus gros encore...

L'ajout de clauses additionnelles

Prenons par exemple une librairie Java bien connue, qui est utilisée en production : Realm Java (la situation a été corrigée depuis, mais a trainé un bon moment tout de même pour que ce soit notable).

À première vue, si on regarde le README vaguement, on voit ceci :

On peut alors en déduire que le composant est sous licence open source Apache 2.0. Sauf que trop de gens s'arrêtent là. Car que si on jette un œil au fichier de licence, on trouve certes des références à la licence Apache 2.0, mais aussi un autre élément d'enfoiré : l'export compliance.

Vous pouvez retrouver le diff du commit sur GitHub, je vous met ci-dessous le contenu scélérat de cette clause, qui rend la licence non conforme à la définition donnée par l'OSI, donc plus open source du tout.

Pour celles et ceux qui n'ont plus assez de caféine dans le sang pour comprendre, voici un résumé : si on se retrouve sur une liste noire du gouvernement américain, que ce soit dans un pays, ou individuellement, ou dans une entreprise détenue par une personne dans cette liste noire, on ne peut pas utiliser ce produit.

En soit, quel est le soucis ?

Et bien le soucis est que l'on peut avoir des applications critiques ou indispensables, ou son produit tout bêtement qui, si un jour le client, l'éditeur, le pays, les actionnaires etc. sont dans le collimateur des États Unis d'Amérique, peuvent être dégagées des boutiques d'applications, avec toutes les conséquences que ça implique.

On peut espérer que ça n'arrivera jamais, ceci dit l'ère Trump a montré qu'il ne fallait pas grands choses pour que des fous furieux mettent la pagaille à l'échelle mondiale en interdisant l'usage de produits. Et le contexte international actuel ne rassure pas non plus vis à vis de la Russie. Demandez leur avis aux iraniens, cubains, ukrainiens ou chinois.

Bref, dit autrement, quand vous utilisez une librairie FLOSS, regardez sur GitHub la section dédiée à la licence. Si le texte “View licence” apparaît au lieu du nom de la licence, il y a deux cas de figure :

• le texte a été modifié (souvent les copyrights) ou décoré faisant que GitHub s'y perd ;
• il y a du texte en plus dans le fichier. Ceci pouvant être des détails sur d'autres licences appliquées ou d'anciens contributeurs, ou des clauses additionnelles.

Et oui, tout ça en droit français est valable.

Mais où ailleurs peut-on se faire avoir ?

La plaie de l'excès de social dans les forges logicielles

Et si on regardait le nombre de commits ?

Déjà, pour “évaluer” un composant FLOSS, on peut regarder par exemple la vie de son code source. Ainsi, si un projet a des commits faits régulièrement, on serait en droit de se dire qu'il est toujours vivant. Toutefois la contraposée est fausse car on peut très bien avoir des projets FLOSS qui semblent “vivoter”, avec peu de commits réguliers mais qui fonctionnent très bien, tout simplement car le projet en lui-même peut être maintenu ponctuellement, discrètement, mais efficacement.

D'ailleurs regarder la date et le nombre de commits est aussi une fausse bonne idée, car par exagération on pourrait croire qu'un projet qui a beaucoup de commits est un projet de qualité, et fiable, ce qui est absurde. Dans la mesure où des outils comme Git permettent le squashing, les merge commits et le rebasing, on remarque bien que se fier uniquement à un historique de commits n'est pas viable. De plus, doit-on vraiment prendre en compte les commits et pull requests ridicules qui arrivent lors du Hacktoberfest quand celles et ceux qui les proposent veulent juste profiter du moment pour avoir un joli badge sur le profil GitHub par pur opportunisme ?

Est-ce que pour l'exemple ci-dessous le projet est vivant ou mort ? On peut s'y fier ou pas ? Pour faire des confettis, c'est suffisant ?

Et Si On RegArDaIt LeS LiKes eT LeS FoLlOwErS ?

Les réseaux sociaux ont amené du pire dans GitHub avec les “likes” et les compteurs de “followers”.

Cet autre piège à éviter consiste à se contenter de regarder ces nombres de stars et de forks d'un projet sur la forge logicielle que l'on veut. Avec l'avènement des réseaux sociaux, on veut “liker”, “booster”, “up-voter” ou “starrer” des projets que l'on aime bien, ou que l'on pourrait aimer, ou pour faire plaisir au gars derrière qu'on connait. Mais en soit, ni le fonctionnel ni la qualité du projet ne sont par essence et par définition concernés. Il en est de même pour les forks ; il est courant de voir des utilisateurs en crééer juste... au cas où, pour grossir son profil GitHub, ou pour faire une pull request un jour ou pas. Surtout ou pas. Quand au nombre de “followers” du développeur principal, en quoi le fait qu'il en ait 2 300 au moins soit rassurant ? Le personnage peut être tout à fait exécrable, pénible voire même adepte de la pizza avec des patates dessus, pourquoi afficher cette fausse notoriété qui n'apporte rien ?

Est-ce que l'exemple ci-dessous est un gros projet ? Un truc balèze ? Non, c'est juste un programme affichant un train à vapeur si on se trompe de commande (moi j'adore).

Oh, et puis, bien évidemment, on peut acheter des “stars” sur GitHub à prix réduit ! La plaie du social jusqu'aux forges logicielles, et à portée de main. Cet article est très instructif sur le sujet.

Environnement et qualité, beau code ou infect projet

On regarde les issues et requests ?

Un autre élément à considérer avec prudence est le nombre de issues et de pull requests / merge requests. En effet, un projet qui en possède beaucoup peut être un projet très vivant, comme aussi un projet qui est très à l'abandon mais avec une base d'utilisateurs réclamant des choses ou voulant contribuer sans personne derrière pour valider. Ou alors peut être victime de trolls, comme ce fut le cas pour le dépôt contenant l'algorithme de recommandations de Twitter. Prudence donc si on ne regarde que ces éléments sans les contextualiser.

On regarde les contributeurs ?

Chose intéressante aussi à voir, les contributeurs, ces petites mains visibles fournissant un incroyable travail.

Si vous utilisez un composant FLOSS avec un faible nombre de contributeurs, il est possible que derrière ce projet il n'y ait presque personne en dehors de quelques passionnés dévoués (bénévolement le plus souvent) à leur projet (pour la gloire plus que pour l'argent). Il faut donc se demander si le fait que le projet repose sur un tout petit nombre de contributeurs est bloquant ou pas. Pour une librairie affichant de confettis c'est peut-être un élément peu pertinent. Mais pour votre couche de chiffrement, est-ce une bonne idée de compter sur un seul péquin derrière ?

D'ailleurs, question bête, est-ce que l'on suppose que la source de vérité est... fiable ? Car pour être affichés comme contributeurs sur un projet GitHub, il faut apparaître à certains endroits dans les commits. Quid des personnes voulant rester anonymes ? Des personnes en pair-programming ? Ou d'une organisation faisant que le mainteneur principal s'acharne maladroitement à garder un historique Git propre et donc fait du copier/coller des pull requests mais en gardant à jour le fichier AUTHORS par honnêteté intellectuelle ? Ou des robots qui exécutent des tâches automatisées sur le dépôt et qui figurent dans les contributeurs ?

Ci-dessous un exemple, avec le projet Amaroq. A-t-on vraiment 13 contributeurs ou 1 seul ? D'ailleurs peut-on vraiment se contenter de mesurer l'activité par le nombre de commits ? Non, évidemment.

En parlant de commits et des contributeurs, peut-on vraiment faire confiance aux contributions ? Il y a des projets FLOSS qui exigent des signatures cryptographiques des commits d'une part, et que le Developer Certificate of Origin soit appliqué d'autre part. Engager les responsabilités de chacun et s'assurer que les commits soient intègres ne semble pas une mauvaise idée, mais a-t-on toutes et tous l'habitude de le faire ? Non. Méconnaissance ou fainéantise ?

La doc ?

D'ailleurs, on peut aussi regarder les échanges qui ont lieu dans les issues, les Slack ou Mattermost. Pour ce composant FLOSS qui vous intéresse, peut-être ne seriez-vous jamais amenés à échanger avec les mainteneurs derrière. Mais si vous voulez contribuer, êtes-vous prêts à dialoguer avec une équipe ayant une organisation pyramidale ? Ou concentrée sur un développeur quasi-messianique à qui tout le monde demande son avis et attend son accord ? Est-ce que l'ambiance est délétère dans le projet ?

On regarde le code source alors ?

Par ailleurs, jetez un œil aussi au code source en lui-même.

Si vous avez un projet iOS écrit en Swift, avec uniquement des compétences en Swift dans votre équipe, seriez-vous prêt à soumettre des pull requests sur un composant écrit en bon vieux Objective-C à la papy ? Si une librairie JavaScript vous plait pour faire des jolies animations, ça vous tente vraiment de l'utiliser sachant qu'elle va tirer jQuery et que vous êtes fiers de vous en être débarrassés y'a 2 ans ? Si le CERT signale de vulnérabilités critiques, et que le composant que vous voulez est concerné, comment et à quelle vitesse sont corrigées ces failles ? Il y en a certaines qui ne le sont toujours pas ? Et ils feront comment si le Cyber Resilience Act passe ? Si on voit plusieurs issues sur des vulnérabilités non corrigées, remontées par Dependabot ou Snyk peut-on nécessairement en conclure que ce composant est dangereux alors qu'un autre sans de telles choses le serait moins même si finalement il pourrait n'avoir en place aucun outil de détection ?

Les gens c'est bien aussi non ?

Truc rigolo, vous connaissez le développeur / grand chef derrière le composant que vous voulez ? Car peut-être politiquement engagé ou susceptible, ou impulsif, ou infect, et qu'il va saboter son projet ou pas, quitte à se faire virer de GitHub. Impossible ? Voyez plutôt.

D'ailleurs, pourquoi c'est là ?

Ce n'est pas parce que le code est sur GitHub, avec une licence libre ou open source que forcément cela a été fait avec une volonté de respecter la philosophie de l'un ou la méthodologie de développement de l'autre.

Par exemple le code a très bien pu être publié juste pour des raisons de transparence totalement opportuniste comme l'algorithme de recommandation de Twitter, maintenant X. Ou alors le code est publié car il embarque un composant sous licence à copyleft fort qui implique une mise à disposition du code source. D'autres projets peuvent être open source pour attirer des contributeurs très rapidement et aussi éviter toute polémique en pleine période de crise, tant sur le manque de fonctionnalités que sur le fonctionnement, sans pour autant avoir des perspectives sur le long terme. Ou alors certains projets décident de se mettre en open source pour faire comme les concurrents et tout avoir public et sans vraiment de contributions venant de l'extérieur, pour le moment, ce qui est dommage car la qualité du produit est là. Ou juste pour montrer ce qu'ils savent faire mais avec des licences ni libre ni open source, pour avoir quelques contributions mais juste avec le code source public. C'est trompeur, mais correct. Mais on a aussi des dépôts open source car une communauté s'est formée autours de l'outil, et là c'est chouette. Plus chouette qu'exposer des projets comme des design system alors que les seuls utilisateurs pourraient être des filiales ou partenaires, qui se serviront gratuitement, plutôt que d'être facturés.

Bref... ce n'est pas parce que le produit est joli sur la vitrine, bien placé en tête de gondole avec un emballage coloré qu'il faut forcément sauter dessus. C'est bien de regarder la date limite de consommation, les ingrédients, les excipients et les origines.

Du coup...

Du coup, il n'y a pas de bons ou de mauvais composants FLOSS. Et non, cette réflexion n'est pas de la “branlette intellectuelle”, bien au contraire. Certains composants sont d'apparence plus fiables que d'autres, il faut les juger par leur efficacité mais pas uniquement ceci dit. Il faut rester prudent sur les licences altérées, bâtardes ou simplement sur leur nature intrinsèque. S'intéresser à l’environnement, à l'ambiance, aux commits et au code source est une bonne chose également.

Il faut aussi envisager le fait qu'un projet finisse par mourir, que sa core team abandonne, que le moteur s'épuise. N'attendez pas pour les soutenir. N'attendez pas pour contribuer. N'hésitez pas les soutenir s'ils défendent des causes justes. L'open source c'est comme une kombucha : c'est super de récupérer une souche mère pour faire vos boissons, mais c'est mieux de partager vos souches filles à d'autres personnes pour qu'elles fassent pareil. À rester dans votre coin tout finira par pourrir et vous n'en tirerez plus grands choses. Prenez, améliorez, partagez et profitez.

Si vous voulez quelques pistes pour aborder les projets FLOSS, je vous partage ce support documenté, factuel et juste.

— Dernière mise à jour : mercredi 17 octobre 2023 Précédemment sur paper.wf —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.