Last modified: 2019-05-21 12:38

Une bonne expression de la façon dont un esprit capitaliste peut ĂȘtre introduit dans l’Open Source :

RĂ©inventer la roue, mais “mieux”.

Je pensais que c’était juste un problĂšme dans le monde du Javascript (d’oĂč la tonne d’outils qui font la mĂȘme chose. Vous avez dĂ©jĂ  cherchĂ© uglify sur npm ?), mais ça arrive aussi en PHP (et dans d’autres langages, au final).

Je n’attends pas de rĂ©ponse du style “C’est Open Source, on fait ce qu’on veut”, ou “Si t’aimes pas, t’as qu’à pas t’en servir”. Le but de cet article est ailleurs. Vous pouvez lire jusqu’au bout.

L’état (totalement subjectif) de l’Open Source

Quand un outil est utilisĂ© par beaucoup de monde, on trouve parfois des dĂ©tracteurs qui le trouvent “nul”. Pourquoi “nul” ? Vous avez 4 heures (ou annĂ©es) de dĂ©bat pour en discuter. Ce que je veux dire, c’est que tout le monde a un moment donnĂ© peut avoir des arguments pour amĂ©liorer quelque chose. L’Open Source, c’est aussi cet engagement.

Un cas oĂč ça s’applique peu : les frameworks.

Par exemple, l’éternel dĂ©bat “Symfony vs Laravel”. Ce dĂ©bat n’a aucun sens, parce que la plupart des arguments sont subjectifs et dĂ©pendent de ce que les gens estiment ĂȘtre “les bonnes pratiques”. Chacun a son avis, et pour chaque avis il y a un dĂ©tracteur. Et dans le cas d’un framework aussi utilisĂ© que Symfony ou Laravel, l’impact peut ĂȘtre trĂšs large.

Non, ici je parle plutĂŽt des BIBLIOTHÈQUES (qu’on va abrĂ©ger ici en lib).

Une lib c’est un outil qui devrait ĂȘtre “rĂ©utilisable dans tout l’écosystĂšme”. Que ce soit une lib en C, un module Javascript, une Gem en Ruby, un package PHP, ou une extension PHP. Du coup au bout d’un moment, certaines libs deviennent populaires, mĂȘme dans plusieurs frameworks.

C’est le cas de certains : League/Flysystem, assez populaire (avec Gaufrette mais moins cĂ©lĂšbre), ou encore HTMLPurifier, et d’autres milliers de libs.

Ces packages existent depuis un moment, ils sont tous trĂšs bons, mais ils sont vieux, du coup dans un tel cas, la maintenance peut ĂȘtre complexe.

Du coup, on fait quoi ?

Je pense qu’il y a 2 solutions :

  1. RecrĂ©er quelque chose de “mieux”
  2. AmĂ©liorer l’existant

Créer quelque chose de nouveau

La solution 1 présente quelques facilités :

« Hey, cette lib est vieille, j’en ai fait une nouvelle, elle fait la mĂȘme chose, mais c’est plus joli ! »

On pourrait penser que c’est intĂ©ressant, voilĂ  quelques raisons :

  • Clean code dĂšs le dĂ©part, yep. C’est une bonne stratĂ©gie, parce qu’on enlĂšve directement ce qui est vieux et mauvais, avec un code tout beau tout neuf, une nouvelle documentation toute fraĂźche. En fonction de qui s’en occupe, on peut avoir un tout nouveau package avec une nouvelle Ă©quipe de mainteneurs (ou juste une seule personne), et une opinion diffĂ©rente des “bonnes pratiques”. Certaines personnes prĂ©fĂšrent aussi cette solution parce qu’elle pensent que “la compĂ©tition est bĂ©nĂ©fique”.
  • On peut supprimer toutes les vieilles fonctionnalitĂ©s qui ne sont plus utilisĂ©es, notamment si le langage a beaucoup Ă©voluĂ© (par exemple, de PHP 5 Ă  PHP 8, ou de Python 2 Ă  3, etc.).
  • On peut se concentrer sur des “nouvelles pratiques”. Si le langage permet maintenant le typage strict, on peut le rajouter partout. Si c’est un langage de POO, on peut arrĂȘter d’utiliser des fonctions globales et commencer Ă  utiliser des objets. Avec PHP, on peut commencer Ă  utiliser Composer et l’autoload, etc.

Quelques inconvénients cela dit :

  • Évidemment, on peut en arriver Ă  faire des copier/coller de l’ancien code et l’adapter, ou tout rĂ©Ă©crire Ă  partir de zĂ©ro, ce qui peut ĂȘtre plus long (genre une annĂ©e ou plus).
  • Si c’est un nouvel outil, vous n’aurez peut-ĂȘtre pas tout de suite de la popularitĂ©, et beaucoup de gens ne migreront pas sur l’outil, soit parce qu’ils n’aiment pas l’idĂ©e, soit Ă  cause du point suivant:
  • Le nouvel outil ne sera pas aussi bien mis en situation et Ă©prouvĂ© que l’ancien, donc vous aurez probablement beaucoup de tĂąches de maintenance au dĂ©but, et n’aurez peut-ĂȘtre pas ce temps Ă  dispo parce que la communautĂ© d’un nouvel outil est forcĂ©ment rĂ©duite.

Tout cela peut lĂ©gĂšrement se corriger si jamais vous ĂȘtes dĂ©jĂ  une personne cĂ©lĂšbre (si vous avez crĂ©Ă© un framework trĂšs populaire, par exemple).

Il y a d’autres raisons qui me font penser que ce n’est pas la meilleure idĂ©e, j’en parle plus loin (est-ce que j’ai dĂ©jĂ  dit que cet article est subjectif ?).

Pour jouer l’avocat du diable face Ă  mes propres dires, j’ai au moins un “bon” exemple d’une lib totalement rĂ©Ă©crite de zĂ©ro :
Swiftmailer.
Cet outil utilise Ă©normĂ©ment d’anciennes (parfois mauvaises) pratiques, et mĂȘme s’il fonctionne bien, pas mal de problĂ©matiques d’architectures freinent la maintenance et empĂȘchent l’usage de ce qu’une lib d’envoi de mail moderne devrait pouvoir faire (par exemple, envoi asynchrone, appels HTTP plutĂŽt que SMTP, configuration d’API diverses pour des services tiers d’envoi de mail, etc.).

Ce sont d’ailleurs les raisons qui ont fait que cette lib a Ă©tĂ© totalement rĂ©Ă©crite sous la forme de Symfony Mailer.
Il n’y a pas de “facilitĂ© de migration” spĂ©cifique, car l’architecture a vraiment changĂ©, donc c’est trop compliquĂ©. Le temps de migration dĂ©pendra surtout d’à quel point vous utilisez les fonctions du cƓur de Swiftmailer, les surcharges que vous faites, etc.

Pour moi, par exemple, la migration Ă©tait rapide : l’appli sur laquelle je l’utilisais n’envoyait que 3 mails diffĂ©rents (inscription, mot de passe, formulaire de contact). Plus simple, mais Ă©videmment ce n’est pas le cas de plus grosses applications.

Je pense donc que rĂ©Ă©crire Swiftmailer de zĂ©ro Ă©tait une bonne solution, l’architecture Ă©tant vraiment trop complexe pour ĂȘtre juste mise Ă  jour. Et il n’y a pas vraiment de compĂ©tition : c’est la mĂȘme Ă©quipe, et Swiftmailer ne sera plus maintenu au bout d’un moment, donc c’est une incitation Ă  migrer vers un nouvel outil.

AmĂ©liorer l’existant

C’est une solution qui “inverse” pratiquement le problĂšme de la philosophie “rĂ©inventer la roue”.

Certaines libs bĂ©nĂ©ficient vraiment de cette option, comme Twig, et l’avantage c’est qu’il n’y a pas vraiment de compĂ©titeurs directs dans le monde de PHP (Ă  part Blade, sponsorisĂ© par Laravel), et crĂ©er un nouveau moteur ne serait pas pertinent, car Twig a dĂ©jĂ  tout ce qu’il faut. Du coup, l’amĂ©liorer a plus de sens.

Cela dit, faire du refactoring de façon granulaire peut prendre pas mal de temps.

Il y a une discussion intĂ©ressante dans une Pull-Request sur Symfony. Le sujet parle ici de changer le systĂšme de “Kernel” dans Symfony 4, et quelques pensĂ©es vont vers une mĂ©thode du style “DĂ©prĂ©cier dans Symfony 5, supprimer dans Symfony 6”. Pour info, la PR date de Mars 2019, Symfony 5 est sorti en Novembre 2019, et Symfony 6 sortira en Novembre 2021. Cela fait donc plus de 3 ans entre le temps auquel la PR a Ă©tĂ© crĂ©Ă©e et le temps Ă©ventuel oĂč la fonctionnalitĂ© sera supprimĂ©e.

C’est ce que j’appelle un “chemin de migration clair”. Surtout quand on parle d’un composant aussi important que HttpKernel.

AprĂšs, amĂ©liorer l’existant a Ă©galement des inconvĂ©nients :

  • La rĂ©trocompatibilitĂ© c’est le pire. Soit vous vous en fichez et vous faites une nouvelle version majeure du style “On a tout changĂ©, adaptez-vous”, ou vous dĂ©prĂ©ciez des tas de trucs dans la version actuelle, en rajoutant des appels du type @trigger_error('Deprecated (...)', E_USER_DEPRECATED); (vive PHP pour ça), faites bien gaffe Ă  ne pas tout casser en sortant la nouvelle version mineure, et supprimez tout ça Ă  la prochaine version majeure en faisant bien gaffe Ă  ne pas pĂ©ter tout l’existant. Bref, la rĂ©trocompatiblitĂ©, c’est tout un mĂ©tier.
  • Il faudra faire avec du vieux code. Vieux, moche, sale, mal organisĂ©, souvent du code que vous n’avez Ă©crit, d’ailleurs qui l’a Ă©crit ? Personne ne sait. Des fois, ce sera du code illisible, qui est en bazar partout.
  • Oh, et je le dis encore une fois, DU VIEUX CODE ! Des pratiques qu’on n’a pas vu depuis des dĂ©cennies, genre du HTML dans du PHP dans un vieux script CGI, et
 Nan, c’est pas possible ça, si ??

Yep, amĂ©liorer l’existant, c’est chaud. Mais :

  • Vous pouvez faire appel Ă  votre communauté ! Et oui, du coup des gens qui connaissent au moins un peu l’outil. Avec plusieurs cerveaux, ça peut aller plus vite.
  • Quand une version majeure est presque terminĂ©e, il est mĂȘme possible de sortir des versions beta ou “release candidate”, et demandez aux gens qui utilisent dĂ©jĂ  l’outil de le tester dans leur projet, balancer tout ça dans leur intĂ©gration continue, en gĂ©nĂ©ral ça devrait suffire Ă  dĂ©tecter les bugs les plus directs. Évidemment ça ne fonctionnera que pour les gens qui ne surchargent pas trop votre code. Sinon, bah
 c’est un problĂšme d’architecture, et ça se rĂšgle aussi.
  • Si votre lib est dĂ©jĂ  popuplaire, et que la nouvelle version est meilleure, eh bien elle sera probablement encore plus populaire aprĂšs. Bon point pour vous.

La philosophie “encore un nouvel outil”

Quelque chose est arrivĂ© aujourd’hui et qui m’a donnĂ© envie d’écrire cet article : un nouveau “FlysystemBundle” a Ă©tĂ© crĂ©Ă©, et il est hĂ©bergĂ© sur l’organisation Github de ThePhpLeague.

On m’a dit que ce nouveau bundle avait “3 avantages”.

Il est soi-disant :

  1. Officiel
  2. Mieux codé, genre il gÚre mieux les nouvelles fonctionnalités de Symfony 4.2
  3. Suit les standards de code de Symfony et de Flysystem

Oui, sur le papier, c’est joli.

Mais.

(oui, toujours un “mais”, sinon ça sert Ă  rien d’écrire un article et de faire l’odieux connard)

Il existait un bundle depuis un loong moment pour l’exact mĂȘme usage : OneupFlysystemBundle, crĂ©Ă© par 1-up Lab. C’est une implĂ©mentation directe de ThePHPLeague/Flysystem et il a dĂ©jĂ  plein de fonctionnalitĂ©s.

La suite sera encore plus subjective.

Les trois points ci-dessus m’ayant Ă©tĂ© donnĂ©s comme des “bonnes raisons” auraient pu ĂȘtre tous corrigĂ©s sans aucun nouveau bundle.

“C’est officiel”

Oui, ça l’est. Ok. D’accord. Super. Cool.

Ça veut dire quoi, “ĂȘtre officiel” ?

Ça veut dire que les mainteneurs de la lib initiale vont maintenir cette lib Ă©galement, en gros. Si j’ai tort, arrĂȘtez-moi lĂ , hein.

Être officiel c’est “juste un nom”. Il est dĂ©jĂ  arrivĂ© plusieurs fois dans le passĂ© que des outils changent d’équipe et que la notion d’outils “officiels” soit juste valide pendant un certain temps, ou pas.

Un bon exemple, c’est le bundle FOSCKEditorBundle. Au dĂ©but, c’était juste IvoryCKEditorBundle, et aprĂšs des discussions et une dĂ©cision de la communautĂ©, il a Ă©tĂ© transfĂ©rĂ© Ă  l’organisation FriendsOfSymfony, pour une maintenance communautaire plus large et un “meilleur” support. Aucun chemin de migration complexe nĂ©cessaire : c’est exactement le mĂȘme outil, il suffit de changer le nom et la version dans votre composer.json et c’est le mĂȘme code, juste un namespace diffĂ©rent. Vous pouvez aussi utiliser la vieille version si vous ne voulez pas migrer, de toute façon c’est la mĂȘme chose, n’est-ce pas ?

C’est aussi arrivĂ© avec Laminas qui est la suite historique de Zend Framework. Bon, je n’ai pas tous les dĂ©tails pour ce cas prĂ©cis, mais l’idĂ©e est la mĂȘme : changez le nom et la version, et la base de code est la mĂȘme. En tout cas je pense que vous avez saisi l’idĂ©e.

Du coup, contre quoi je me prends la tĂȘte, dĂ©jà ?

Ah oui : “officiel” n’est pas un argument.

L’équipe de Flysystem aurait pu proposer Ă  1up-Lab de reprendre la maintenance de leur projet et de la rendre “officielle”. AprĂšs tout, c’est la plus utilisĂ©e de toutes les implĂ©mentations de Flysystem pour Symfony, sinon la seule, donc pourquoi pas ? 1up-Lab resterait l’équipe crĂ©atrice initiale, c’est Ă©crit partout dans l’historique et les contributions de toute façon, les commentaires, les pull-requests, la licence, etc.

“Officiel” pourraĂźt ĂȘtre un argument seulement si 1up-Lab avait refusĂ© que son outil devienne “officiel”. Seulement. Dans. Ce. Cas.

Et mĂȘme, c’est Open Source, donc si quelqu’un de ThePhpLeague avait fait un fork de ce bundle pour le rendre officiel, pas de problĂšme, la licence est lĂ  pour prĂ©parer Ă  ça justement.

Cependant, il n’y a eu aucune proposition. Aucune discussion. Aucune contribution à l’existant.

Rien de tout ça.

“Mieux codĂ©, gĂšre mieux les nouvelles fonctionnalitĂ©s de Symfony 4.2”

Yep, “meilleur code”. C’est sĂ»r. Il est aussi possible d’optimiser le code du repo d’origine.

“GĂšre mieux (
)”, dans la plupart des cas on peut ajouter quelques lignes de code pour ça (bon, peut-ĂȘtre un peu plus que ça, mais c’est toujours moins de code Ă  Ă©crire que de tout rĂ©Ă©crire).

”(
) fonctionnalitĂ©s de Symfony 4.2”, c’est toujours possible de façon automatisĂ©e en rajoutant une couche de compatibilitĂ© spĂ©cifique en dĂ©tectant la version du framework, ou mĂȘme en crĂ©ant une nouvelle version majeure de l’outil qui supprime le support de vieilles versions de Symfony et gĂšre “mieux” les nouvelles.

Un bon example sur ce nouveau bundle Flysystem, la seule et unique fonctionnalitĂ© “nouvelle” m’a pris une seule heure de travail & tests & relecture et je l’ai envoyĂ©e via cette PR, et elle a Ă©tĂ© acceptĂ©e sans problĂšme. Une heure, et tout le monde a cette “nouvelle super cool fonctionnalitĂ©, such wow” promue ailleurs.

Aucun rĂ©el argument ici, du coup, seulement des choses qui auraient probablement coĂ»tĂ© bien moins que de juste contribuer Ă  l’outil initial.

On m’a d’ailleurs dit que ce nouveau bundle avait mis prĂšs d’un an Ă  ĂȘtre codĂ©.

Une année vs une heure, vous préférez quoi ?

“Suit les standards de code de Symfony et de Flysystem”

Quels standards ? Indentation K&R vs Allman ? ModĂšles riches vs modĂšles anĂ©miques ? Mediator plutĂŽt qu’Observer ?

Oui, certaines organisations ont des standards de code stricts, comme Doctrine, et Symfony.

Si les styles diffĂšrent, la plupart du temps c’est une affaire de “goĂ»t”, un “dĂ©tail d’implĂ©mentation” peut-ĂȘtre. Tant que le code fonctionne pareil et qu’il est assez performants (benchmarks et profiling Ă  l’appui), et que les fonctionnalitĂ©s sont extensibles (rapport aux principes SOLID), quels “standards” pourrions-nous clairement raisonnablement avoir de plus ?

On peut utiliser PHPStan ou Psalm pour renforcer ces standards, c’est une dĂ©cision du mainteneur ou de l’équipe, ou mĂȘme simplement une simple PR exĂ©cutant les outils en question par exemple.

Les standards sont des guides que vous pouvez suivre si vous avez des problĂ©matiques d’organisation dans l’équipe. Si vous maintenez une lib, les standards ne seront pas utilisĂ©s de la mĂȘme façon que pour un framework triple-A, l’impact n’est pas le mĂȘme. Idem pour un projet clĂ©-en-main (comme OctoberCMS, Wordpress, etc.), qui n’ont pas les mĂȘmes exigences.

Si vous dĂ©cidez quand mĂȘme de suivre un standard, j’ai quand mĂȘme des doutes sur le fait que 1up-Lab pusse avoir refusĂ© une PR exĂ©cutant php-cs-fixer avec les standards de code de Symfony.

AprĂšs tout, travaillent bien sur des correctifs de style de code, et tout le monde peut venir en discuter.
Ah, et au fait, l’auteur de ce nouveau FlysystemBundle n’a jamais ouvert une seule discussion avec la communautĂ© sur une nouvelle version ou une nouvelle intĂ©gration ou que sais-je. Cliquez sur le lien: jamais.

Une fonctionnalitĂ© est juste Ă  la portĂ©e d’une pull-request.

Tous ces Ă©tats de faits sont vrais pour ce FlysystemBundle, mais si j’écris c’est article, c’est qu’en rĂ©alitĂ© c’est vrai pour N’IMPORTE QUEL OUTIL.

C’est pas juste à propos d’une lib, ça va bien plus loin

Je me prends la tĂȘte sur ce sujet Ă  cause d’un problĂšme plus grand.

Cela ne surprendra probablement pas grand monde si je dis que nous vivons dans une société de consumérisme gouvernée par le capitalisme.

Consommez, si vous n’aimez pas, allez voir ailleurs, ou faites-le vous-mĂȘme. Et vous payez pour tout ça. Tout le temps.

Le “passĂ©â€

Cette histoire de “faites-le vous-mĂȘme” Ă©tait plutĂŽt intĂ©ressante quand les “choses” n’étaient pas aussi avancĂ©es qu’aujourd’hui.

Les machines remplacent les humains au travail, dans les usines par exemple, pour une “bonne” raison : elles font plus de “choses”, pour moins cher, et permettent aux patrons de gagner encore plus. Du coup, les humains rentrent chez eux, ou cherchent un autre boulot.

Dans l’industrie de l’IT, genre il y a 20-30 ans, c’était vraiment “l’ñge d’or” du do it yourself, car il n’y avait quasiment pas de documentation, trĂšs peu de standards, et les langages de programmation Ă©taient un peu moins simples qu’aujourd’hui. Je me souviens de mon grand frĂšre lisant un livre de genre 200 pages format A4, rempli de lignes de codes Ă  copier sur son propre ordinateur, juste pour avoir un jeu vidĂ©o.

Aujourd’hui, c’est plutĂŽt de l’élitisme.

Les travailleurs sont remplacĂ©s par des machines automatisĂ©es, et de leur cĂŽtĂ© les devs “bas-niveau” sont remplacĂ©s par des interfaces de programmation “haut-niveau”. Le problĂšme c’est que l’industrie de l’IT a besoin de tellement de devs qu’il faut les former, les Ă©duquer Ă  cette industrie, et plein de centres de formations se vantent de faire ça en 3 Ă  6 mois. Je pense que c’est n’importe quoi. On ne devient pas dev en 6 mois. Au mieux, on devient dev junior qui a des notions thĂ©oriques sur plusieurs sujets, mais c’est insuffisant. Toute l’expĂ©rience, la thĂ©orie sur l’architecture, l’Open Source, les diffĂ©rents langages, les concepts, etc., rien de tout ça ne peut ĂȘtre acquis en une pĂ©riode si courte. Les seules formations disponibles il y a plus de quinze ans Ă©taient des DUT ou BTS, donc au minimum 2 ans, ainsi que d’autres Ă©tudes supĂ©rieures pouvant aller jusqu’au doctorat. Du coup, les devs qui arrivent dans l’IT aujourd’hui sont beaucoup moins expĂ©rimentĂ©s. AprĂšs, si ce sont des dĂ©butants, c’est logique. Mais. (oui, encore un “mais”)

Ce que l’on peut constater est que les devs avec plus de 10 ans d’expĂ©rience, un ou plusieurs diplĂŽmes dans l’informatique, ou juste une passion dĂ©vorante oĂč le temps libre est Ă©galement consacrĂ© Ă  l’informatique, ou tout ça en mĂȘme temps, sont tellement plus expĂ©rimentĂ©s, l’écart s’agrandit de plus en plus chaque annĂ©e avec la recrudescence de nouvelles technologies, et on en arrive Ă  un genre de “conflit de gĂ©nĂ©rations”. Les devs “hipster-JS-fullstack-react” versus “vieux barbu dans sa cave avec un donut et un Apple II” (je caricature trĂšs grossiĂšrement). C’est un peu normal, en soi, mais ça peut aboutir Ă  des problĂšmes comme l’élitisme sur StackOverflow.

Le “prĂ©sent”

Et du coup, l’élitisme est partout.

Les travailleurs disparaissent, et de nouveaux emplois apparaĂźssent, avec un niveau d’exigence et de compĂ©tence encore plus grand. Et tout le monde en a besoin. Et c’est difficile de trouver des profils avec un bon niveau (surtout vu que beaucoup de juniors sont sur le marchĂ©). Un peu comme la pĂ©nurie de pilotes de ligne, ou de devs COBOL.

Il faut des “top-level” partout, et moins de compĂ©tences n’est pas vraiment acceptable car les architectures et environnements des applications sont de plus en plus complexes (docker, kubernetes, async partout, APIs et web-services, micro-services, etc.). Dans le passĂ©, il y avait “l’intĂ©grateur HTML/CSS”, le “sysadmin”, l’“UX Designer”, etc. Maintenant on a un truc du style “devops qui fait tout parce que c’est cool d’avoir un full-stack-ninja-jedi-babyfoot-biĂšre-pizza-react-laravel-wordpress”. MĂȘme les dĂ©signations de mĂ©tiers sont insensĂ©es quand ça tourne autour de l’IT. Le mĂ©tier de “dev” est maintenant tout aussi vague que ne l’était le mĂ©tier “d’informaticien” il y a 15 ans.

Je me répÚte :

Les métiers qui nécessitent un niveau plus bas de compétences sont en train de disparaßtre.

Cela force les personnes qui ont un moins bon niveau Ă  soit galĂ©rer sur le marchĂ© du travail, ou alors se former pour un job avec encore plus d’exigences. Et c’est injuste (gna gna gna calimĂ©ro), parce que je pense que tout le monde n’a pas forcĂ©ment le niveau pour changer, et surtout, je pense que tout le monde n’a pas forcĂ©ment envie. Du coup les projets avec moins de “skills” s’étiolent, pour le moins. Les devs en ont marre, ils se barrent rapidement (turn-over de 1 Ă  3 ans dans notre mĂ©tier, c’est quand mĂȘme gros), et recommencent dans une autre entreprise. Encore et encore. Et du coup les connaissances acquises se perdent, le projet “vit” moins bien, l’entreprise en est impactĂ©e, et ainsi de suite.

Ces entreprises sont donc dĂ©sormais contraintes Ă  participer Ă  cette “consommation de devs”, au mĂȘme titre que la sociĂ©tĂ© nous enjoint Ă  “consommer des choses”.

Retour au sujet initial

FOSS (Free Open Source Software) c’est donc un petit peu “consommer des logiciels libres”. Et gratuits. Et tout le monde fait selon ses envies.

Mais le mieux dans l’Open Source c’est l’esprit de partage. On partage, on discute, on dĂ©bat, on contribue, tout le monde en profite, et ainsi de suite.

Partager gratuitement n’est pas vraiment une valeur principale dans le monde du capitalisme.
Dans ce monde, les valeurs viennent plutît de ce qui fait du profit. De la thune. Des bas d’laines. Tout c’qui traüne.

Le capitalisme se sert de l’Open Source comme d’un moyen pour faire du profit. Point. Barre.

Le profit interne de l’Open Source n’est pas un profit financier, c’est plutît le partage d’outils utiles pour les gens. C’est plutît un profit communautaire.

En son cƓur, le logiciel libre et Open Source est une forme d’humanisme.

Mais pas seulement. En tout cas, j’en ai peur :

Ego

We’re only human, after all.

Mais des fois (souvent ? Ouais, cet article est subjectif, je sais) j’ai le sentiment que l’égo domine partout.

Comme dit plus haut, pour des logiciels open source, on a parlĂ© de deux stratĂ©gies : recrĂ©er de zĂ©ro, ou amĂ©liorer l’existant.

Le capitalisme dirait probablement “On recrĂ©e, en privĂ©, et on vend”. Évidemment, l’Open Source ne vend pas vraiment. Du coup, chacun “fait ce qu’il veut”, et finalement il reste juste des “satisfactions personnelles”. L’égo, du coup, catalyseur de satisfaction personnelle des Hommes.

(je parle surtout d’hommes et moins de femmes, car j’ai le sentiment que les femmes sont moins sujettes à l’ego dans l’Open Source, probablement parce que l’IT est une industrie avec malheureusement 95% d’hoommes, et que la plupart des femmes dans l’IT souffrent de cette situation, mais c’est un autre sujet)

La satisfaction peut venir sous plusieurs formes, mais je dirais que dans l’IT, l’égo vient surtout en fonction de comment on est considĂ©rĂ©s dans note champ d’expertise, notamment comme une forme “d’autoritĂ©â€.

Un petit exemple : devenez dev Symfony ou Laravel, accumulez plein de compĂ©tences, contribuez au framework avec des fonctionnalitĂ©s utiles, et beaucoup de monde vous considĂšrera comme une forme “d’autoritĂ©â€, ou “d’influence”. Et des fois, avec quelques compĂ©tences avancĂ©es, vous allez dĂ©clencher sans faire exprĂšs le syndrome de l’imposteur d’autres devs qui n’auront pas ces compĂ©tences ou connaissances. Alors que ces personnes savent certainement faire plein d’autres choses aussi.

ThĂ©oriquement, si l’on regarde bien, n’importe quel dev peut contribuer Ă  de tels frameworks. C’est d’ailleurs grĂące Ă  la documentation de contribution de ces outils que l’on se rend compte qu’il suffit d’une idĂ©e, d’un cas particulier, et ensuite lire la doc de contribution, pour pouvoir contribuer soi-mĂȘme.

Oui, mais non.

Tout le monde n’est pas forcĂ©ment impliquĂ© dans l’Open Source que les membres des Ă©quipes de Symfony ou Laravel ou d’autres contributeurs rĂ©guliers. Certaines personnes sont vraiment passionnĂ©es par leur sujet, d’autres s’en fichent tant qu’elles ont leur salaire. J’ai connu pas mal de gens qui se contentent de faire leur 8 heures quotidiennes et retourner chez eux sans allumer leur ordinateur Ă  la maison. C’est ok. L’Open Source, on “fait ce qu’on veut”, de toute façon, et c’est pas parce qu’on ne contribue pas qu’on n’a pas un bon niveau.

Plein de devs cependant sont dans une sorte de zone grise, c’est-Ă -dire que ces personnes ont un intĂ©rĂȘt pour l’Open Source mais ne contribue pas, peut-ĂȘtre par manque de temps. Ou de soutien, notamment de la hiĂ©rarchie professionnelle (plein de patrons s’en fichent complĂštement de l’Open Source et voient ça comme du temps et de l’argent perdu. Sauf que si ces gens rĂ©flĂ©chissaient un peu mieux, ils rĂ©aliseraient que l’Open Source fait bien leur beurre).

Du coup il y a une apparence d’élitisme dans le fait de dire “Si t’aimes pas, fais-le toi-mĂȘme”. Parce que tout le monde n’en a pas forcĂ©ment la possibilitĂ©. Sans compter la culpabilisation faite par certains mainteneurs lorsqu’une personne ne contribue pas.

J’ai dĂ©jĂ , personnellement, reçu des injonctions tu style “Tu peux discuter tant que tu veux, je m’intĂ©resse uniquement aux gens qui codent”. Des gens qui n’ont donc pas compris que la contribution Ă  l’Open Source ce n’est pas juste du code.

Je disais dans un tweet qu’il existe trois Ă©tapes faciles pour contribuer au monde de l’Open Source :

  • Utiliser des logiciels Open Source
  • Promouvoir leur usage (famille, travail, institutions
)
  • Aider les gens Ă  comprendre et utiliser l’Open Source

Tout le monde ne le peut pas, d’oĂč le paradoxe

C’est le principal paradoxe de l’open-source à mes yeux :

  • Vous partagez des outils libres et gratuits pour le bien commun
  • Tout le monde peut faire ce qui lui plait avec (dans les limites de la licence, bien sĂ»r)
  • Quiconque veut contribuer peut commencer Ă  discuter, dĂ©battre, rĂ©flĂ©chir, et peut-ĂȘtre finir par un consensus qui amĂ©liorera la qualitĂ© des outils, pour le bien commun toujours
  • Mais si ce “quiconque” ne sied pas Ă  vos opinions sur la façon de contribuer, vous les envoyez ch*er

Le dernier point est le plus important, parce qu’il est souvent prĂ©sent avant toute contribution.

Vous n’aimez pas la personne qui a fait tel ou tel outil ? Il suffit de le fork et de promouvoir votre propre travail. Baston d’égo.

L’équipe qui maintient l’outil n’aime pas votre idĂ©e, ou pire, ne vous aime pas vous ? L’équipe va juste supprimer votre contribution, la refaire elle-mĂȘme, et promouvoir son travail.

Si vous me dites “La compĂ©tition a du bon”, vous ĂȘtes clairement Ă  fond dans le capitalisme.

La compétition est intéressante quand il y a des bénéfices des deux cÎtés, ainsi que du cÎté utilisateur ou consommateur.

Par exemple, Laravel vs Symfony est une compĂ©tition intĂ©ressante parce que les deux frameworks ont une philosophie trĂšs diffĂ©rente, et chacun peut s’inspirer de l’autre pour apporter des petites nouveautĂ©s. Par exemple, Laravel emprunte des tas de concepts issus de Symfony et utilise mĂȘme ses composants, et de son cĂŽtĂ©, Symfony a introduit quelques nouvelles fonctionnalitĂ©s inspirĂ©es de Laravel (comme la fonction dd(), ou les assertions de tests inspirĂ©es de Laravel Dusk). C’est une compĂ©tition saine, en tout cas au regard des frameworks (parce que c’est vachement moins sain du cĂŽtĂ© des humains derriĂšre
).

Une compĂ©tition entre des outils A et B, l’un Ă©tant un fork ou une rĂ©Ă©criture de l’autre, n’est pas saine, car vous finissez avec 2 libs faisant la mĂȘme chose, et seule la popularitĂ© de l’outil (ou de son mainteneur
) gagnera Ă  la fin. Personne n’a jamais crĂ©Ă© un fork de Twig pour l’optimiser ou que sais-je, non. Twig a juste Ă©tĂ© optimisĂ©, et un petit peu rĂ©Ă©crit, peut-ĂȘtre.

Ici je parle plutĂŽt d’un concept : une lib qui fait la mĂȘme chose que la lib concurrente, mais est juste vendue comme “meilleure”.

À mes yeux, c’est juste du pur Ă©go que de rĂ©Ă©crire la lib d’origine et clamer que cette nouvelle version est “meilleure”, surtout sans avoir jamais contribuĂ© Ă  la lib d’origine ni jamais avoir dĂ©marrĂ© de discussion.

C’est pas du logiciel libre et Open Source.
C’est de l’ego.
C’est du capitalisme.