rien à voir, j'abandonneEnvoyé par esperanto
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 :
rien à voir, j'abandonne
Tutoriels OpenGL
Je ne répondrai à aucune question en MP
- Si c'est simple tu dis que c'est compliqué et tu le fait
- Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.
VS Code est surement le meilleur éditeur du moment, ça va d'ailleur difficile de mieux faire avant un moment, mais de là à dire que c'est un logiciel libresrien à voir, j'abandonne
comme ça c'est plus clair
Tutoriels OpenGL
Je ne répondrai à aucune question en MP
- Si c'est simple tu dis que c'est compliqué et tu le fait
- Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.
Ah oui...
Ah oui en effet tu confonds Visual Studio Code (simple éditeur) avec Visual Studio Community (environnement de développement complet, presque similaire à la version pro sauf pour sa licence)
mais à part ça c'est moi qui fait des confusions dans tous les sens...
Corrections over evolutions... Un jour peut-être...
Parce que des enseignants ont abandonné Apache Zeppelin dont j'attendais beaucoup pour passer à Jupyter, je suis allé sur le site Apache de Zeppelin. Pourquoi évoluait-il si lentement ? Peinait-il tant ? Je suis allé voir ses issues.
78 bloquantes, 109 critiques, 813+ majeures => le logiciel est mort et enterré, disons-le. Il ne s'en remettra pas.
Les contributeurs des projets open source préfèrent largement réaliser des nouvelles fonctionnalités à corriger les incidents.
Leur argument, odieux et récurrent (quand il n'ignorent pas totalement le report) est : "donnez-nous un test case, sinon on ne peut pas corriger". Si, bien sûr. Les développeurs doivent toujours corriger l'incident qui affecte leur code, quels que soient les éléments qu'on peut leur fournir pour le décrire. Même les développeurs des projets open source le doivent : qu'on sache, en entreprise, nous avons tous eu le bug rude, quasi-impossible à trouver avec un cas de test et un scénario à inventer soi-même et de la sueur, et il a fallu le faire. Alors les développeurs des projets open source aussi doivent s'y contraindre. Eh bien, ça na va pas de soi.
Je lis parfois des contributeurs de projets open source demander à un pharmacien, par exemple, qui rapporte un incident qui lui a fait tout perdre de son travail - et dont il ne peut pas se figurer qu'il met en œuvre de la concurrence d'accès, du parallélisme -, un cas de test rejouable... Sans rire... Pire que ça : parfois un Test Unitaire (Si !) pour leur montrer (que dis-je ? Leur prouver !) le bug. Sinon, ils ne feront rien...
C'est pour cela que je cherche les projets open source qui apportent une garantie qu'avant toutes évolutions,
ils corrigeront en premier lieu,
très volontairement et sans pinailler,
tout incident majeur ou supérieur qu'ils auront entériné dans leur issues connues.
Redite : l'autre jour, j'achète un livre : "Méthodes Numériques Appliquées" . Il dit : Java, C++, Python, bof, c'est en Scilab (open source) qu'on va tout développer.
Il s'installe mal, bug sur beaucoup de fonctions, avec des justifications en réponse "que c'est parce qu'il y a un problème et que ça ne marche pas" (on s'en doute) et voilà le bouquin devenu bien moins utilisable.
J'ai qu'à corriger Scilab moi-même, pourrait-on me rétorquer, n'est-ce pas ? Croyez-moi, dans certains projets open source, on ne s'est pas privé de me faire ce genre de réponses, mâtinées de "Oh ! Comment osez-vous ?! Les développeurs open source sont bénévoles, prennent du temps, font gratuitement : ils sont gentils ! (ça c'est atroce : votre soft bug et on vous fait du chantage aux sentiments) vous devez accepter ou corriger leurs bugs au lieu de les critiquer". La belle affaire, ouais !
L'open source manque de labels de garantie de qualité concernant sa propension, célérité, à corriger ses bugs.
L'absence de rémunération dans le domaine des logiciels open source est insoutenable
L'absence de rémunération dans le domaine des logiciels open source est insoutenable, d'après Thomas Stringer, développeur logiciel
Thomas Stringer, développeur logiciel et programmeur de logiciel open source, parle des problèmes que rencontrent les développeurs open source. Selon lui, l'absence de rémunération dans le domaine de l'open source décourage de plus en plus les développeurs. Il propose quelques solutions pour y remédier.
Les logiciels open source sont des logiciels dont la licence respecte des critères précisément établis par l'Open Source Initiative, c'est-à-dire les possibilités de libre redistribution, d'accès au code source et de création de travaux dérivés. Mis à la disposition du grand public, ce code source est généralement le résultat d'une collaboration entre programmeurs.
L'intérêt de l'open source est qu'il met en avant la qualité des logiciels produits. Le code source peut être relu et amélioré par tout le monde, ce qui peut permettre notamment la correction de problèmes de sécurité. Les logiciels open source intéressent beaucoup les pays nouvellement industrialisés et émergents (Chine, Brésil, Inde, etc.) car ces logiciels leur confèrent une indépendance technologique à moindre coût.
Voici un article que Thomas Stringer a écrit concernant la situation des développeurs open source :
Source : Thomas Stringer, développeur logicielIl est 23h43, un lundi soir. Mon fils de 6 semaines s'est endormi dans mon bureau afin que ma femme puisse se reposer sans interruption pendant la première moitié de la nuit. Il est enfin endormi, et je devrais l'être aussi après une journée de travail bien remplie. Mais je n'ai pas fini ma journée. Même si je suis ingénieur logiciel de métier, je suis aussi un programmeur informatique par hobby et par passion. Je fais donc ce que je fais depuis plus d'une décennie : Je démarre mon ordinateur pour écrire du code.
Que faire, que faire... Apprendre quelque chose de nouveau ? Peut-être. Écrire un article de blog ? Eh bien... me voilà. Mais... au fond de moi, je sais que j'ai des projets open source qui ont besoin d'attention. L'un d'entre eux est très utilisé. J'en suis à près de 3/4 millions de téléchargements, et c'est quelque chose dont les gens semblent penser qu'il a un certain niveau d'utilité. Ce sont les bons côtés. Les mauvais côtés sont qu'il y a une douzaine de problèmes que je n'ai même pas examinés, et encore moins triés, étudiés et corrigés. Il y a quelques PRs de la communauté que je dois examiner. Il y a des dépendances qui doivent être mises à jour. La liste est longue. Ce projet a atteint une étape OSS pas si rare : L'épuisement du mainteneur.
Ce qui motive tous les créateurs de logiciels
Je ne suis certainement pas le seul à vouloir écrire des logiciels. Et avec la crainte de trop généraliser un groupe massif d'artisans du logiciel, je pense que l'effort que nous mettons dans le logiciel est une équation simple :
Temps = Passion + ArgentChaque heure que nous passons à écrire du code est due à une combinaison de passion et d'argent. Ces deux éléments peuvent être nuls, mais l'autre partie doit être suffisamment importante pour compenser la valeur nulle. Prenons mon cas comme exemple :
Mon travail d'ingénieur logiciel est excellent. On me donne de l'argent pour écrire du code. J'ai aussi la chance d'avoir une grande passion pour le code que j'écris et les choses que je construis. Mon travail est également très demandé. C'est une grande victoire ! J'ai de la chance. D'autres peuvent être peu ou pas passionnés par leur travail, mais leur rémunération leur permet de revenir le lundi matin à 9 heures. C'est tout à fait normal !
Voyons quelques-uns de mes autres projets en cours. Mon blog, ce blog, est l'un d'entre eux. Je ne gagne pas d'argent, mais j'y mets un peu de passion et cela correspond assez bien à la demande. Ensuite, il y a le projet passion, qui ne me rapporte pas d'argent, mais qui me passionne et me motive beaucoup. Et comme il n'y a pas de demande, je vais à mon propre rythme et je prends la direction que je veux !
Et enfin, il y a mon projet OSS (logiciel open source) inintéressant (pour moi). Ce qui ressemblait autrefois à un projet passion est maintenant méconnaissable du point de vue de la motivation. Mais la demande est forte. Il y a beaucoup d'utilisateurs, dont beaucoup en entreprise, qui utilisent mon logiciel pour faire progresser leur organisation. Et la mauvaise nouvelle, c'est que je n'en tire aucun revenu. La motivation est donc essentiellement inexistante à ce stade. Là où la passion fait défaut, l'argent pourrait me motiver à travailler régulièrement sur ce produit.
Que se passe-t-il vraiment ?
Tout cela se résume à une situation dans laquelle de nombreuses entreprises génératrices de profits utilisent un logiciel qu'un programmeur s'est porté volontaire pour écrire. Ce logiciel permet à l'entreprise de gagner encore plus d'argent. Mais le développeur ne voit rien de tout cela parce qu'il n'est qu'un auteur sur quelques commits git, et qu'il ne fait pas partie du personnel de l'entreprise.
C'est ce qu'on appelle le volontariat en tant que service (Volunteering as a Service - VaaS). Il s'agit littéralement d'un repas gratuit aux dépens de personnes qui travaillent dur.
C'est assez sombre, alors permettez-moi de revenir un peu en arrière. Ce ne sont pas toutes les entreprises qui traitent les logiciels open source (OSS) de cette manière. Et même pour celles qui le font, je suis prêt à parier que 99 % d'entre elles ne négligent pas les compensations par malveillance. Le système des OSS n'est tout simplement pas équipé pour permettre à ces entreprises de rémunérer leurs contributeurs.
Quelle est la solution ?
L'énoncé du problème n'est pas nouveau. Elle a souvent été évoquée, sous de nombreuses formes. Quelle pourrait être la solution ? Les développeurs de logiciels libres devraient être rémunérés de la manière suivante :
Argent = Contributions * UtilisationSi vous contribuez activement à un produit très utilisé, la rémunération devrait en tenir compte. 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. Mais ce n'est pas si simple, car il existe différents types de développeurs de logiciels open source. Certains écrivent du code OSS dans le cadre de leur emploi, auquel cas ils sont probablement déjà rémunérés pour leurs contributions. Cette rémunération leur est versée deux fois par mois. Mais l'autre type de développeur de logiciels open source est celui qui fait ces contributions en dehors de ses heures de travail et qui n'est pas affilié à une organisation.
Les entreprises utilisatrices de logiciels open source devraient financer ces projets. Après tout, ce sont elles qui les utilisent. Et même si elles ne sont pas obligées d'acheter des licences à SomeClosedSourceSoftwareCompany, cela ne signifie pas qu'elles ne devraient pas contribuer.
Comment les entreprises peuvent-elles contribuer ?
La réponse évidente est l'argent. La réponse moins évidente est le temps de travail des développeurs. Il s'agit d'une pratique assez courante. Les entreprises peuvent avoir des employés qui contribuent à temps plein ou partiel à des projets de logiciels open source. Kubernetes et tous les développeurs qui contribuent à Kubernetes sur leur temps de travail en sont un bon exemple. Les entreprises figurant sur cette liste (Google, Red Hat, VMware et Microsoft, pour ne citer que les plus importantes) contribuent à la réussite de ces projets. Elles donnent du temps aux développeurs.
Lorsqu'une entreprise ne consacre pas suffisamment de temps aux projets, elle devrait compléter sa contribution par de l'argent distribué aux développeurs OSS qui ne représentent pas leur entreprise. La rémunération des entreprises devrait ressembler à ce qui suit :
Rémunération = Développeurs + ArgentVoici une autre façon de voir les choses :
Ces trois entreprises contribuent de manière responsable au produit OSS, mais de différentes manières. L'entreprise 1 apporte de l'argent et du temps de développement, l'entreprise 2 n'envoie que de l'argent, et enfin l'entreprise 3 fournit les développeurs adéquats au projet.
Comment les dépendances sont-elles rémunérées ?
Vite, nommez toutes les dépendances de Kubernetes. Vous ne pouvez pas, et moi non plus. Il y en a tout simplement trop. Les produits destinés aux utilisateurs finaux ne devraient pas être les seuls à bénéficier d'une compensation appropriée. Ce devrait être ces produits qui envoient une partie de leurs contributions (argent et temps de développement) à ces dépendances dans un grand arbre heureux de contributions.
Pourquoi est-ce si difficile ?
Il y a beaucoup de défis à relever. Et ce ne sont que les choses auxquelles j'ai pensé. Je suis sûr qu'en réalité, c'est encore plus compliqué. C'est pourquoi je ne pense pas que la responsabilité morale incombe actuellement à ces entreprises. Il faut mettre en place un système qui gère les contributions des utilisateurs et les distribue aux projets et aux projets de dépendance. L'entreprise 2 peut se réveiller un jour et dire "Je veux faire ce qu'il faut et rémunérer les développeurs de logicielS open source". Mais... euhhh... où envoie-t-elle l'argent ? Je n'en ai aucune idée. Il n'y a personne à qui l'envoyer sans ajouter une tonne de frais généraux, ce qui n'est juste pour personne. Et non, je ne pense pas que les sponsors GitHub soient la solution à ce problème.
Résumé
J'espère qu'un jour nous trouverons le moyen de rémunérer équitablement les créateurs de logiciels open source. C'est la bonne chose à faire, et je ne connais personne (y compris ces entreprises) qui conteste ce point de vue. Nous sommes tous ensemble dans ce grand monde du logiciel.
Et vous ?
Pensez-vous que l'avis de Thomas Stringer est crédible ou pertinente ?
Voir aussi :
Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités
Il ne faut pas se le cacher, les gens aiment l'open source surtout plus pour le coté gratuit que idéologique. Mais personne ne se pose la question de qui/comment a développé cela et dans la grande majorité des cas, personne ne fait de dont. L'avantage du payant c'est que vous avez un "minimum" de garantie qu'il va continuer à vivre. Après, l'open source y a apporté beaucoup de chose dans le domaine du numérique et il faut y féliciter ceux qui ont contribués.
Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...
Ce qui serait intéressant de savoir .
C'est comment est considéré une donation a une fondation ou au monde open source , par le système fiscal du pays , dans lequel est fait la donations .
Si je ne raconte pas de bêtises , en France , a une époque il y avait une déductibilité d'imposition , sur une fourchette de donation.
Il me semble que cela a était longtemps le cas pour : Les Restos du Coeur.
Mais pour le monde open source , est ce qu'il existe une notion de déductibilité d'imposition ????
Ne pas savoir n’est pas une faute si l’on cherche à combler ses lacunes.
"Il n'y a pas d'obstacles infranchissables , il y a des volontés plus ou moins énergiques voilà tous" Jules Vernes
Une vision bien naïve
Je commente l'article "L'absence de rémunération dans le domaine des logiciels open source est insoutenable".
Le Monsieur explique qu'il estmais queun programmeur informatique par hobby et par passionC'est contradictoire, soit on fait du soft pour l'argent et à ce moment-là un modèle open source n'est pas le plus indiqué, soit on fait du soft par passion et à ce moment-là on se fiche d'être rémunéré puisqu'on le fait d'abord pour soi.Selon lui, l'absence de rémunération dans le domaine de l'open source décourage de plus en plus les développeurs
Si des développeurs sont découragés, c'est sans doute plus pour une panne de motivation que par manque d'argent.
Ensuite il explique qu'il a undont :projet OSS (logiciel open source) inintéressant (pour moi). Ce qui ressemblait autrefois à un projet passion est maintenant méconnaissable du point de vue de la motivationSi ça ne le motive plus, il n'a aucune obligation envers les utilisateurs, en plus professionnels ! Son code source est publié, à eux de le forker et de le modifier pour qu'il réponde à leurs besoins. C'est quand même pour cela que l'on donne accès à son code source...Les mauvais côtés sont qu'il y a une douzaine de problèmes que je n'ai même pas examinés, et encore moins triés, étudiés et corrigés. Il y a quelques PRs de la communauté que je dois examiner. Il y a des dépendances qui doivent être mises à jour. La liste est longue. Ce projet a atteint une étape OSS pas si rare : L'épuisement du mainteneur
S'il veut en tirer des revenus, il crée une entreprise uni-personnelle et propose ses services pour assurer une maintenance payante de son code.
Il reconnaît lui même queEn effet, une entreprise ne peut pas financer une entité abstraite comme un projet open source (entité qui n'a pas de compte bancaire à qui verser de l'argent), et souvent très difficilement un particulier. Les entreprises s'adressent et peuvent payer d'autres entreprises !Le système des OSS n'est tout simplement pas équipé pour permettre à ces entreprises de rémunérer leurs contributeurs
Elles ont besoin en contrepartie de recevoir une facture pour leur comptabilité, de gérer les taxes afférentes, de montrer qu'elles ne blanchissent pas d'argent, etc.
C'est donc extrêmement simple. Soit un projet open source est "hébergé" par une entité légale avec qui une entreprise puisse être en relation (fondation, entreprise) et là(je doute qu'elles le fassent car elles n'ont aucune obligation), soit certains des développeurs ou contributeurs de ces projets open source ont des structures juridiques qui permettent de les rémunérer pour un travail de maintenance ou d'évolutions.Les entreprises utilisatrices de logiciels open source devraient financer ces projets
Les DSI n'ont en général aucune envie ou intérêt à être en relation avec des particuliers ou des communautés. S'ils veulent avoir la garantie d'une correction ou d'une évolution logicielles, ils préféreront en revanche être en relation avec une entreprise payant des développeurs membres de ces projets ou communautés.
Je reviens par ailleurs sur le chapeau de l'article :Il est juste faux de dire queL'intérêt de l'open source est qu'il met en avant la qualité des logiciels produits. Le code source peut être relu et amélioré par tout le monde, ce qui peut permettre notamment la correction de problèmes de sécuritéPar ceux qui connaissent la programmation et le langage de développement utilisé, éventuellement. Mais en pratique, quasiment personne ne lit le code source des autres sauf raison impérieuse (bug, problème de sécurité).Le code source peut être relu et amélioré par tout le monde
Et c'est encore plus faux de croire que celacar cela nécessite de s'y connaître en sécurité informatique ET en développement, ce qui est extrêmement rare (la plupart des gens qui font de la sécu font surtout de l'infra, la plupart des développeurs n'ont qu'une très vague idée de ce qui peut occasionner un problème de sécurité dans un code source (aucune connaissance du référentiel OWASP par exemple)).peut permettre notamment la correction de problèmes de sécurité
L'exemple récent de la faille de sécu restée pendant 4 ans dans le code source de Curl, l'un des logiciels les plus utilisés au monde, l'illustre bien.
Il me semble évident que l'Open Source n'est qu'une mode passagère initiée par une idéologie post-soixante-huitarde de barbus californiens, puis reprise par tous ceux qui vivent chez papa et maman et qui n'ont pas besoin de payer des factures.
L'Open Source, en plus de ne pas être durable, dévalorise le métier de développeur en laissant à penser aux décideurs que le code, c'est gratuit.
C'est délétère sur le long terme et il est plus sain et valorisant pour les développeurs que le code soit une activité rémunérée.
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...
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 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 ?
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager