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...
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