Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Vous avez une vision extrêmement restreinte du domaine. Avez-vous compris que Llama-2 de Meta est disponible en Open Source, par exemple ? Avez-vous entendu parler de git, Linux, Emacs, PostgreSQL, LibreOffice ? Et tant d'autres...Envoyé par yahiko
Connaissez-vous le modèle de fonctionnement de RedHat ? Le rôle d'IBM ? L'adoption de Linux par Microsoft comme kernel alternatif à Windows ?
Réfléchissez un brin avant d'asséner vos vérités...
Il faut distinguer l'Open source développé par un ou un petit groupe de développeur et celle développé par une entreprise et mis en "open source".
Vous, vous parlez du second point et je pense qu'il parlait du premier. En soit il n'a pas tort , mais ces deux mondes restent flou pour certains et il faut pourtant bien les distinguer.
Il y a peut être un juste milieu... Par ex. une licence open source du type "gratuit pour les projets open source ± les particuliers" et payant pour les sociétés, les collectivités... Ou comme fitzing qui fait payer les binaires (bien qu'on puisse compiler soi-même c'est pas donné à tout le monde).
L'open source c'est un mouvement énorme. Sans, il y aurait un avantage supplémentaire aux grands groupes financièrement puissants en informatique. Si une petite boîte (voire une société d'une personne) voulait lancer un projet, sans open source, il faudrait un apport de capital supplémentaire pour payer des licences pour toutes les lib. C'est un peu comme si on revenait au temps où fallait payer le compilateur, la lib graphique, audio, la lib de compression, le réseau... et tous ces trucs en #include ou import. En tous cas ça ferait disparaître tout ce qui n'est pas nettement rentable, peut être linux et GNU.
un argument de plus pour l'avenir de l'open source
L'open source n'est pas nécessairement la production de développeurs bénévoles. Lorsque j'ai installé les premières versions de Linux, au siècle dernier, les contributeurs des compilateurs étaient de grands groupes comme HP. Cela se voyait très bien dans les entêtes de code source qui portaient encore les traces HP. Pourquoi avoir lancé un produit comme Linux ? Pour diviser les coûts de développement entre contributeurs, simplement. Et la communauté est donc largement constituée de professionnels (par exemple la fondation Apache ...)
Il y a une raison supplémentaire au maintien de l'Open source en bonne santé : certaines organisations, comme Microsoft, ont une position dominante et quasi-monopolistique sur leur marché, de sorte que la plupart des concurrents ont été éliminés. Or les monopoles sont souvent interdits dans les pays de l'OMC (Organisation mondiale du Commerce) ce qui peut entraîner la dissolution de l'organisation. Un grand groupe en situation de monopole (comme Google par exemple, mais vous avez certainement d'autres noms en tête) a intérêt à maintenir des activités open source concurrentes pour ne pas se retrouver en situation de monopole absolu sur ses produits.
Donc l'open source vivra, même sous respiration artificielle, mais pas forcément avec de petits contributeurs.
ça dépend, il y a des limites. Quand j'écris une fonction pour mon propre usage, ok pour la passion. Quand je reçois plein de demandes (et non de contributions) de la part d'utilisateurs, au bout d'un moment on espère recevoir un peu plus que du chantage à "si je n'ai pas cette fonction je vais utiliser le concurrent"
On peut avoir d'autres motivations pour publier le code source, mais pour la possibilité de forker je suis d'accord. Les licences open source précisent bien qu'elles s'appliquent au logiciel tel quel, en l'état, sans aucune obligation (en contrepartie de la mise à disposition gratuite)
Pour l'entreprise unipersonelle, j'aimerais être d'accord mais ce n'est pas si facile: si tu as un employeur tu peux te retrouver avec une clause d'exclusivité, et si tu lâches tout pour ta société, tu vas te retrouver à faire du développement freelance à côté parce que la maintenance payante de ton code ne suffira pas à payer les factures.
Le problème c'est qu'il n'existe pas de "système OSS" à proprement parler: chaque projet a une structure (association) .... ou pas, auquel cas c'est compliqué de les financer.
Si au moins chaque projet se structurait en association il pourraient recevoir des dons.
Mais je préfère le principe du paiement pour un développement spécifique, qu'on appelle fonction sponsorisée.
là ça tombe bien, je suis programmeur freelance et il m'arrive de contribuer à des logiciels libres suite au sponsoring d'une entreprise utilisatrice. Dans ce cas, c'est ma petite entreprise qui facture, le projet d'origine ne voit pas la partie financière, il voit juste la nouvelle fonction (qu'il peut accepter ou non d'ailleurs...)
Mais c'est dommage, s'ils pouvaient au moins se structurer en association ils pourraient eux aussi utiliser les dons pour sponsoriser les développeurs et avoir les fonctions qu'ils veulent.
Maintenant concernant l'article.
Hélas non. Beaucoup de logiciels libres sont utilisés dans les entreprises ... comme second choix, elles ont toutes acheté une licence pour le logiciel leader du marché, évidemment très cher et impossible à personnaliser, mais souvent imposé sur certains projets parce que le client le demande. Du coup le logiciel est utilisé par beaucoup de monde, mais de petites équipes. Après, parfois le DSI accorde un petit budget pour payer des contributions ponctuelles. Mais si le projet ne se structure pas, impossible de structurer plusieurs PME ayant le même souci pour aboutir ensemble à financer un développeur.De même, si vous avez soumis quelques commits sur un produit que personne n'utilise, l'argent (ou l'absence d'argent) devrait en être le reflet.
Ca c'est du chantage affectif, faut pas céder à ça :-)Quand je reçois plein de demandes (et non de contributions) de la part d'utilisateurs, au bout d'un moment on espère recevoir un peu plus que du chantage à "si je n'ai pas cette fonction je vais utiliser le concurrent"
J'ai une clause de ce type dans mon contrat de travail, mais c'est une clause standard dans ma boîte. Si je vais en discuter avec mon boss, puis ma DRH, je suis persuadé que je peux la faire revoir (enfin ça dépend du niveau de confiance que la boîte a en toi).Pour l'entreprise unipersonelle, j'aimerais être d'accord mais ce n'est pas si facile: si tu as un employeur tu peux te retrouver avec une clause d'exclusivité, et si tu lâches tout pour ta société, tu vas te retrouver à faire du développement freelance à côté parce que la maintenance payante de ton code ne suffira pas à payer les factures
Après, c'est déjà arrivé pour mes propres collaborateurs. du moment que les limites sont précisées (et éventuellement que les sommes en jeu sont montrées), c'est acceptable.
Oui, c'est ce que je disais. On peut défrayer quelqu'un, mais dès qu'il s'agit de payer un service il faut un "véhicule légal" acceptable.Le problème c'est qu'il n'existe pas de "système OSS" à proprement parler: chaque projet a une structure (association) .... ou pas, auquel cas c'est compliqué de les financer.
Si au moins chaque projet se structurait en association il pourraient recevoir des dons.
Mais je préfère le principe du paiement pour un développement spécifique, qu'on appelle fonction sponsorisée.
Il y a une autre possibilité, c'est la souscription d'un service par l'entreprise (location de serveurs, par exemple) auquel on donne accès au projet à code ouvert ou libéré.
Il y a longtemps, quand l'hébergement Internet était hors de prix, j'avais accepté de faire de l'admin sys/réseau/sécu pour une boîte d'hébergement en échange de la jouissance de ses infrastructures pour mes propres besoins et ceux de mes amis.
On a fait ça pendant 7 ans. Je ne voulais pas de relation contractuelle, ni d'argent entre nous...
Ce n'est pas probablement pas totalement propre au niveau fiscal cependant...
Qu'est-ce qui vient après l'open source ? Un pionnier de l'open source affirme qu'il faut changer de paradigme
Qu'est-ce qui vient après l'open source ? Un pionnier du mouvement de l'open source affirme qu'il faut changer de paradigme
et trouver un moyen équitable de rémunérer les développeurs
Bruce Perens, l'un des fondateurs du mouvement de l'open source, déplore l'état actuel de la communauté. Il a déclaré lors d'une récente interview qu'il existe plusieurs problèmes urgents auxquels la communauté open source doit s'attaquer. Perens affirme notamment que les licences open source ne fonctionnent plus et que les grandes entreprises (comme Red Hat, Apple et Google) se contentent de tirer le meilleur de la communauté et font ensuite un doigt d'honneur à cette dernière en guise de remerciement. Il a déclaré que l'open source a échoué à servir le commun des mortels. Enfin, il estime que l'open source a atteint ses limites et qu'il faut penser à ce qui va suivre.
Perens : l'open source est en proie à un certain nombre de problèmes graves
Bruce Perens est considéré comme l'un des pères fondateurs du mouvement de l'open source. Il est cofondateur de l'Open Source Initiative et détient la marque Open Source Initiative. Mais au début de l'année 2020, Perens a quitté l'Open Source Initiative à la suite d'un différend sur la nouvelle licence de partage de données cryptographiques : « nous avons fait fausse route en matière de licences ». L'informaticien a également profité de l'occasion pour promouvoir un mouvement alternatif appelé "open source cohérent". Aujourd'hui encore, Perens reste convaincu que l'organisation fait fausse route et que le mouvement a besoin d'être réformé.
Selon Perens, l'open source fait face à de nombreux défis. « J'ai écrit des articles à ce sujet et j'ai essayé de mettre au point un prototype de licence. Il est évident que j'ai besoin de l'aide d'un avocat. La prochaine étape consistera à obtenir des subventions. Tout d'abord, nos licences ne fonctionnent plus. Nous avons eu suffisamment de temps pour que les entreprises trouvent toutes les failles et nous devons donc faire une chose de nouveau. La GPL n'agit pas comme elle aurait dû le faire lorsqu'un tiers de tous les systèmes Linux payants sont vendus avec un contournement de la GPL », explique Perens dans une récente interview accordée à The Register.
Il cite notamment l'exemple du récent scandale autour de la distribution Red Hat Enterprise Linux (RHEL). La distribution RHEL est sous la coupe d'IBM depuis que le géant des mainframes a racheté Red Hat pour 34 milliards de dollars en 2019. Red Hat a annoncé cet été qu'il ne publiera plus le code source de sa distribution comme l'exige la licence GPL. L'entreprise interdit également à ses clients de partager et de redistribuer le code source ou de l'utiliser pour créer une distribution en aval. Ce faisant, Red Hat s'est attiré les foudres des développeurs, qui dénoncent une violation des principes fondamentaux de la communauté des logiciels open source.
Les employés d'IBM affirment qu'ils continuent à fournir des correctifs au projet open source en amont, mais qu'ils ne sont évidemment pas tenus de le faire. Perens a dénoncé la décision de Red Hat et affirme que cela trahit l'esprit même de l'open source. Dans une déclaration partagée avec le média britannique, Perens note :
Perens : il faut trouver un moyen de rémunérer les développeurs open source
Perens estime que l'open source a atteint ses limites et qu'il faut désormais penser à ce qui va suivre. « Le logiciel libre a maintenant 50 ans et la première annonce de l'open source a eu lieu il y a 30 ans. N'est-il pas temps pour nous d'examiner ce que nous avons fait et de voir si nous pouvons faire mieux ? Oui, mais nous devons en même temps préserver l'open source. L'open source continuera à exister et à fournir les mêmes règles et le même paradigme, et ce qui vient après l'open source devrait s'appeler autrement et ne devrait jamais essayer de se faire passer pour l'open source. Jusqu'à présent, je l'appelle Post-Open », a-t-il déclaré.
Perens affirme que le Post-Open sera un peu plus impliqué que l'open source. Il définirait les relations entre les entreprises et les développeurs afin de garantir que les entreprises paient un montant équitable pour les avantages qu'elles reçoivent. Le Post-Open resterait gratuit pour les particuliers et les organisations à but non lucratif, et ne comporterait qu'une seule licence. Il imagine une simple procédure de conformité annuelle qui permettrait aux entreprises d'obtenir tous les droits dont elles ont besoin pour utiliser les logiciels Post-Open. Elles financeraient les développeurs qui seraient encouragés à écrire des logiciels en respectant certaines règles.
Par exemple, ces logiciels doivent être utilisables par le commun des mortels, plutôt que par des experts techniques. Se référant aux applications populaires d'Apple, de Google et de Microsoft, Perens note : « une grande partie des logiciels est orientée vers le client en tant que produit - ils sont certainement très surveillés et, dans certains cas, font l'objet d'abus. C'est donc le bon moment pour que l'open source fasse des choses pour les gens normaux ». Selon lui, la raison pour laquelle cela ne se produit pas souvent aujourd'hui est que les développeurs écrivent du code pour eux-mêmes et pour ceux qui ont les mêmes compétences techniques.
Pour éviter cela, Perens affirme qu'il faut rémunérer les développeurs afin qu'ils puissent prendre le temps de créer des applications conviviales. Il souhaite également que les entreprises paient la facture, qui pourrait être répartie entre les développeurs contributeurs à l'aide d'un logiciel comme celui qui instrumente GitHub et montre qui contribue à un projet donné. Selon l'informaticien, Merico est une entreprise qui fournit ce type de logiciel. Par ailleurs, il reconnaît que de nombreux obstacles doivent être surmontés pour implémenter ce projet, comme la recherche d'une entité acceptable pour gérer les mesures et la distribution des fonds.
De plus, les arrangements financiers doivent intéresser un nombre suffisant de développeurs. « Et tout cela doit être suffisamment transparent et ajustable pour ne pas bifurquer de 100 façons différentes. Vous savez, c'est l'une de mes grandes questions. Est-ce que cela peut vraiment arriver ? », a ajouté Perens. En effet, l'absence de rémunération dans le domaine des logiciels open source reste un problème épineux auquel les acteurs tentent de trouver une solution. Les développeurs affirment que l'absence de rémunération est de plus en plus insoutenable. Ils en appellent à la contribution des grandes entreprises qui profitent gratuitement du système.
Perens : le mouvement Post-Open doit impérativement repenser les licences
Selon Perens, la GPL (General Public License) n'est pas suffisante. « La GPL n'est pas conçu comme un contrat, mais comme une licence. Richard Stallman pensait qu'il ne voulait pas retirer des droits à qui que ce soit. Il voulait seulement accorder des droits. Ce n'est donc pas un contrat. C'est une licence. Désormais nous ne pouvons plus faire cela. Nous avons besoin de conditions contractuelles exécutoires », a-t-il déclaré. À la question de savoir si l'adoption de licences non open source (par des entreprises comme HashiCorp, Elastic, Neo4j et MongoDB) représente une voie viable pour l'avenir, Perens a répondu qu'une nouvelle réflexion est nécessaire.
Il n'est pas fan des licences telles que la Commons Clause, qui est au centre d'une bataille juridique impliquant Neo4j. « Pourquoi Commons Clause est-elle mauvaise ? Dans un premier temps, il y a le problème de la marque. Les licences open source ont une marque qui est la compréhension des droits qu'elles véhiculent, et bien sûr l'open source a aussi une marque, qui est la compréhension des droits dans la définition de l'open source. Commons Clause semble utiliser la licence open source, mais ne donne pas du tout les mêmes droits, abusant ainsi de la marque de la licence à des fins lucratives », a déclaré Perens. Mais ce n'est pas tout. Perens poursuit :
« L'autre problème est que Commons Clause est ajoutée à des licences qui ne permettent pas d'ajouter des termes, comme l'AGPL 3 sur Neo4J. L'AGPL et la GPL ont deux paragraphes qui interdisent l'ajout de termes. Ainsi, lorsqu'un donneur de licence ajoute Commons Clause, il crée une licence avec un langage juridique qui se contredit. Nous travaillons sur le problème des logiciels en tant que service depuis assez longtemps. Je me souviens d'avoir assisté à une réunion de la Free Software Foundation, où la question était de savoir ce qu'il fallait faire face à Google. L'AGPL est née de cette réunion ». Mais selon lui, cela ne résout pas le problème.
« Par exemple, l'AGPL oblige les logiciels à divulguer leur propre code source d'une manière ou d'une autre. Ce dont nous parlons en fait, c'est de l'exécution publique dans les logiciels, et l'exécution publique est un droit distinct en vertu du droit d'auteur, car elle était nécessaire pour les pièces de théâtre et les films. Nous disposons donc de ce droit dans le cadre du droit d'auteur et nous pouvons l'utiliser. En fait, ces licences essaient toutes d'atteindre un but et n'y parviennent que partiellement parce qu'elles n'ont essayé d'apporter que de légères modifications par rapport à l'open source », a-t-il déclaré. Selon lui, un changement radical est nécessaire.
Interrogé sur l'enthousiasme actuel pour l'IA, Perens a déclaré : « je pense que l'IA est toujours un plagiat. Lorsque vous entraînez le modèle, vous l'entraînez avec les données protégées par le droit d'auteur d'autres personnes. Et ce que fait l'IA, c'est de mélanger et d'assortir et de produire une combinaison de ce qui a été introduit. Nous devons en tenir compte. Comment indemniser les personnes dont les données ont été utilisées pour entraîner le modèle ? Devrions-nous l'entraîner à l'aide d'un logiciel open source ? Je ne le pense pas. Cependant, il [le modèle d'IA, NDLR] fait plus que cela. Il lit les sites Web des gens. Il lit l'intégralité de Wikipédia ».
« Personne du côté de l'entrée n'est rémunéré équitablement pour le résultat. C'est donc une grande question que nous devons résoudre », a-t-il ajouté. Par ailleurs, il a été interrogé sur les efforts des États-Unis pour empêcher la Chine de développer son industrie technologique ou d'accéder aux nouvelles technologies développées par des entreprises américaines ou occidentales. D'après Perens, ces efforts ont été largement inefficaces. « Les Chinois peuvent faire, à une ou deux exceptions près qui ne tarderont pas à disparaître, tout ce que nous faisons », affirme Perens, notant que même s'ils sont en retard sur les puces avancées, ils le rattraperont.
Source : interview de Bruce Perens
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
J'ai du mal a dire que la GPL a été pensé uniquement pour ajouter des droits, elle a de sacré contraintes (pour un développeur, et non pour un utilisateur finale), on pourra dire que ça la rend plus résistante aux soucis de l'articles, mais la BSD ou MIT ne se pose pas tant de question et tienne en un nombre léger de paragraphes...
(Ce qui n'empêche pas que Apple redistribue le code source publiquement sur son site pour ce qui tombe sous cette licence)
Je sais que les pro-GPL seront en désaccord avec moi mais a part la question de la rémunération qui serait un véritable atout pour la survie de l'open-source, je dirais plus que le soucis ce sont les défauts inhérent a la GPL et ses dérivés qui font la taille d'un roman (ouvrant a des failles juridiques et a des soucis comme ceux lié a Creative Commons) là où les licenses BSD et MIT sont "simple" et efficace dans leur vision du libre. (Qui est peut-être moins dans l'intérêt des utilisateurs finaux, mais offrant plus de libertés aux développeurs perso et pro)
Oui pour reponser Open source.
Certe il est temps de reponser Open source de la manière a préserver les acquis et s'ouvrir sur les actualités et tendances du monde réel, mais se verser dans la renumeration (lucratif) c'est admettre quelque part un échec qui n'est d'autre que le but tant attendu des rivaux.
Voilà que même un des pionniers du mouvement Open Source reconnaît que le modèle n'est pas viable. Ce qui est une évidence. On ne peut pas vivre d'amour et d'eau fraîche, tout passionné et altruiste qu'un développeur puisse être.
Seule une poignée de projets dit Open Source parviennent à se financer via des méthodes que je ne trouve pas saines, en facturant du support au lieu de facturer le véritable produit, le code, et donc tout le travail qui a conduit à le produire.
En cela, en dépit d'une certaine idéologie ambiante, les logiciels propriétaires ont le mérite de l'honnêteté et de la clarté. On paye les gens qui ont développé le code. C'est simple, c'est logique. Je ne comprends pas pourquoi certains réprouvent cette idée.
En espérant que le mouvement Open Source parvienne à grandir et à gagner en maturité car il n'est finalement pas surprenant qu'ils aient l'impression d'être les dindons de la farce. C'est leur modèle qui veut ça. L'Open Source part d'une vision naïve, rousseauiste, alors que le monde réel, ce n'est pas les bisounours. Pour valoriser son travail, il faut se protéger et se défendre. Ce n'est pas en ouvrant les portes et les fenêtres au tout-venant qu'on doit s'offusquer ensuite de voir le fruit de son labeur pillé par d'autres.
Welcome to the real world...
Les mainteneurs et les contributeurs du projet Rust sont confrontés à un problème d'épuisement professionnel
Les mainteneurs et les contributeurs du projet Rust seraient confrontés à un problème d'épuisement professionnel
selon une ancienne contributrice au projet Rust
Le projet Rust ferait face à l'épuisement professionnel de ses mainteneurs et contributeurs. Dans un article publié mardi sur le sujet, Jynn Nelson, ingénieure séniore Rust chez Redjack, affirme que le problème serait tel que le nombre de personnes qui ont quitté le projet Rust pour cause d'épuisement professionnel est scandaleusement élevé. Elle affirme également que le nombre de personnes dans le projet Rust qui sont proches de l'épuisement professionnel est également scandaleusement élevé. Selon son rapport, le projet Rust souffrirait d'un manque important de mentors et les contributeurs sont parfois amenés à gérer une grande partie du travail de manière indépendante.
L'épuisement professionnel des mainteneurs et des contributeurs est une grande préoccupation dans l'univers des logiciels libres et open source. Les pistes de solutions visant à résoudre ce problème sont constamment débattues dans la communauté, mais les choses semblent ne pas aller de l'avant. Dans le cas du projet Rust, Nelson affirme que les choses vont de mal en pire et propose quelques approches de solutions qui, selon elle, pourraient aider à venir à bout du problème. Nelson a contribué au projet Rust entre octobre 2019 et juin 2023 et dans son article, elle dépeint un environnement de travail chaotique pour les contributeurs et les mainteneurs.
Pour donner une idée de la façon dont les choses se passent, elle décrit ce scénario : « vous voulez contribuer à Rust. Vous trouvez quelque chose qui vous intéresse, puisque les problèmes faciles/mentorés sont pris. Il est difficile de trouver un mentor parce que toutes les personnes expérimentées sont débordées et épuisées, alors vous finissez par faire une grande partie du travail de manière indépendante ». Selon elle, vous venez ainsi d'apprendre que le travail sur ce projet ne se fait pas si vous ne le faites pas avancer personnellement. Le problème que vous avez résolu était ouvert depuis des années ; la majorité des problèmes sont là depuis des années.
Nelson explique que, une fois que vous êtes un contributeur actif, les choses se compliquent davantage et la charge de travail n'arrête pas d'augmenter avec le temps. Elle insiste sur l'argument selon lequel les choses ne se font pas si vous ne les faites pas personnellement. Voici ci-après l'atmosphère qu'elle décrit en se basant sur sa propre expérience :
- vous devenez un contributeur plus actif : le responsable actuel est trop épuisé pour effectuer un triage régulier, vous finissez donc par parcourir l'arriéré des problèmes (généralement, vous êtes la première personne à l'avoir fait depuis des années). Cela renforce l'idée que le travail ne se fait pas à moins que vous ne le fassiez personnellement ;
- le responsable actuel reconnaît votre travail et vous confie une grande partie des responsabilités, en particulier les révisions : les nouveaux contributeurs font des demandes de fusion (pull request). Ils font des erreurs simples et stupides dues à leur manque d'expérience ; vous les signalez et elles sont corrigées. Cela peut être amusant pendant un certain temps. Ce que cela vous apprend, c'est que vous êtes personnellement responsable de la détection des erreurs ;
- vous vous fatiguez : les gens font toujours les mêmes erreurs et vous avez peur de faire confiance aux autres évaluateurs ; vous êtes peut-être le seul évaluateur, ou les autres évaluateurs ont déjà laissé passer des choses et vous ne faites plus autant confiance à leur jugement qu'avant ; on vous confie peut-être trop de demandes de fusion et vous n'arrivez plus à suivre. Cela fait des semaines que vous n'avez pas travaillé sur les choses que vous voulez faire, et personne d'autre n'y travaille parce que vous avez dit que vous le feriez ("elles ne se feront pas si vous ne les faites pas personnellement", dit une voix) : "le projet serait pire sans toi".
Nelson dénonce cet état de choses et appelle les contributeurs à rester vigilants pour ne pas tomber dans cette routine. « "Cela ne sera pas fait si je ne le fais pas" et "je dois tout revoir ou des choses vont passer à travers", c'est exactement l'état d'esprit de mon propre épuisement professionnel. Peu importe que ce soit vrai, cela vous fera souffrir. Si le projet ne peut pas survivre sans que vous fassiez personnellement des heures supplémentaires non rémunérées, il ne mérite peut-être pas de survivre », a-t-elle déclaré. L'ingénieure estime que les contributeurs devraient faire attention même lorsqu'ils sont payés pour travailleur sur le projet Rust.
« Si vous êtes payé pour travailler sur Rust, vous avez probablement commencé en tant que contributeur non rémunéré et obtenu le poste plus tard. Traitez-le comme un travail dès maintenant. Ne faites pas des heures supplémentaires, ne vous portez pas volontaire à tout bout de champ, ne travaillez pas sur des choses qui dépassent largement votre description de poste. La meilleure façon d'aider le projet est de continuer à y contribuer pendant des années. Pour ce faire, vous devez éviter de vous épuiser, ce qui signifie que vous devez bien vous traiter », a-t-elle déclaré. Dans les commentaires, de nombreuses personnes semblent partager son avis.
« Selon mes observations, je pense que le projet Rust a des problèmes d'épuisement professionnel plus graves que la plupart des autres projets open source de taille similaire. Je ne sais pas si cela est lié à la façon dont le projet est organisé, à l'état de la base de code ou au type de personne qui est attiré par le travail sur Rust en premier lieu. La situation est de plus en plus préoccupante et mérite une grande attention de la part de la Fondation Rust. En attendant, prenez soin de vous. C'est un grand pas dans la vie d'un ingénieur logiciel lorsqu'il réalise que coder 24 heures sur 24 et 7 jours sur 7 n'est pas le mode de vie idéal », a écrit un critique.
D'autres critiques suggèrent que le problème est peut-être lié à la façon dont Rust est conçu. « C'est peut-être parce que Rust est nouveau et bien conçu. Les personnes qui l'ont adopté s'en soucient probablement, elles veulent le maintenir et cela est difficile. C'est peut-être mon perfectionnisme, mon désir de construire et de vivre dans une tour d'ivoire, mais je ressens cela en tant qu'utilisateur de Rust, une peur qu'ils puissent briser une certaine perfection perçue à laquelle je tiens. L'on pourrait dire que les développeurs C++ sont libérés du fardeau consistant à utiliser un langage parfait », ajoute un critique. Cet argument est toutefois controversé.
« Toutes les organisations bénévoles doivent lutter contre l'épuisement professionnel. Chaque fois que vous commencez à avoir l'impression que les choses ne seront pas "faites" à moins que vous ne les fassiez, vous êtes sur cette voie. Faites attention à vous », affirme un autre critique. De son côté, Nelson a déclaré que les chefs d'équipe peuvent jouer un rôle important dans la résolution de ce problème. À la question de savoir ce que ces derniers peuvent faire, elle a énuméré ces points :
- disposer d'une documentation sur ce qu'il faut faire en cas d'épuisement professionnel : il faut accorder à l'épuisement professionnel autant de priorité qu'aux problèmes techniques ou aux conflits de modération ;
- faire tourner les responsabilités : ne confiez pas la majorité des relations publiques à la même personne. Si cette personne révise les demandes de fusion d'autres personnes sans y être invitée, expliquez-lui pourquoi elle ressent le besoin de le faire. Si une personne est affectée à la file d'attente de révision et ne révise jamais les demandes de fusion, parlez-en avec elle ; retirez-la de la file d'attente ; donnez-lui des vacances ou confiez-lui d'autres responsabilités, le cas échéant ;
- demander aux gens pourquoi ils partent : Nelson affirme qu'elle connaît au moins une personne dont l'histoire d'épuisement professionnel ne correspond pas à celle décrite dans ce billet. Selon elle, il n'est pas possible de résoudre un problème si l'on n'en comprend pas les causes ;
- prendre ces problèmes au sérieux : donnez la priorité au développement de l'équipe et à la création d'un environnement sain plutôt qu'à la résolution des problèmes techniques. Les problèmes seront toujours là dans quelques mois ; vos collaborateurs ne le seront peut-être plus.
Selon certains critiques, bien que ces propositions puissent être efficaces pour faire face au problème de l'épuisement professionnel dans le projet Rust et dans l'univers des logiciels libres et open source, il est peu probable qu'elles soient mises en œuvre. Ces derniers estiment que la situation actuelle de l'open source profite à de nombreuses entreprises et qu'elles souhaitent maintenir le statu quo. « De toute évidence, les entreprises sont heureuses de profiter de tout ce dur labeur sans avoir à y contribuer en retour, et c'est en partie à cause de cette culture. L'open source a besoin d'être réinventé », a écrit un critique.
Source : billet de blogue
Et vous ?
Voir aussi
ça me déçoit de Bruce Perens. Faire la SACEM des codeurs pour pouvoir leur filer quelques miettasses, voir à votre employeur si jamais vous avez le malheur de collaborer sur du libre au boulot. Confiez leur l'argent, ils feront de la magie !!
Il a raison sur tout les constats qu'il fait mais faire une entité centralisatrice tuerait tout je pense. Il ne faut pas qu'il y ait "une tête" du libre qui déciderait ensuite d'une quelquonque manière quoi est prioritaire ou qui doit être payé.
Je conçois que les licences doivent évoluer, mais faire une nébuleuse pareille ça me semble être le pire choix possible. Déjà qui voudra payer ? ça va forker à tire larigot oui. Les grosses boîtes le font déjà, les petites qui se lancent hésiterons encore moins !
Perens était déjà préoccupé par le fait que l'OSI avait créé plus de 100 licences logicielles différentes, et il a demandé instamment sur la liste de diffusion : « Supprimons la Tour de Babel ».
Notez qu'on vit dans une société qui promeut la diversité en permanence, mais tout ce qui ne convient pas au grand capital doit vite devenir comme le reste. La diversité oui, mais dans le profit !
La dernière fois que j'ai entendu ça c'était pour des types qui livrent des sandwichs à vélo. ça s'est pas exactement fini comme ça...sans avoir à gérer une entreprise pour le faire...
Enfin on sent que lui a juste les glandes de pas avoir fait plus de fric, le libre est un succès en soi : les softs libre sont présents partout, sans eux l'infra ne tient pas, c'est un constat que fait un autre site d'actus qui adresse un peu l'éléphant dans la pièce :
Le seul échec c'est la thune, oh mais wait, c'était l'objectif de pas en faire !In a world where 96% of all software contains open-source components, one that has transformed many industries, empowering developers to collaborate and create innovative solutions, how can something so ubiquitous be considered a failure?
C'est peut-être pour ça que le monde du libre est ainsi fait... Certains codent, partagent, et d'autres créent des sociétés commerciales qui vont assumer le reste. Pourquoi changer ça ?“Users want one support vendor not hundreds,” observed Perens. “That’s why IBM wins contracts rather than the OS developers, because they promise to support all of their software.”
Répondre avec citation
Partager