Un cas de capitalisme dans le monde de l open source
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 :
- RecrĂ©er quelque chose de âmieuxâ
- 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 :
- Officiel
- Mieux codé, genre il gÚre mieux les nouvelles fonctionnalités de Symfony 4.2
- 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.