Discussion :

[loufab]

les mairies bénéficies d'une autonomie de gestion, et une partie d'entre elle est déjà sur OpenOffice...quand aux logiciels clés GRH et Finances, il n'y a pas assez de concurrence, ils coûtent la peau du cul...je n'en connais pas de libre.

"La peau du cul..." par rapport à quoi ?
En principe elles achètent plus un service qu'un simple logiciel. Notamment la mise à jour réactive suivant la réglementation, le SAV...

T'as déjà vu une paye ou une compta publique ? C'est pour cela qu'il n'y en a pas en libre. Ce n'est pas qu'un développeur, il faut aussi des spécialistes métiers.

[Paul TOTH]

Il y a aussi une très grosse différence dont personne n'a parlé jusqu'à maintenant.

c'est n'est vrai qu'en parti...ce n'est pas parce que tu utilises une solution libre que tu as la compétence ou les moyens de faire évoluer ce produit s'il devait être abandonné.

Par exemple, en tant que programmeur Pascal j'ai forcément regardé FreePascal, notamment avant de me lancer dans FlashPascal, je me suis dit qu'il était sans doute possible d'ajouter une nouvelle plateforme Flash à FreePascal en conservant tout la partie compilation qui est commune...ben au final j'ai trouvé plus simple de faire tout moi même car le projet est plutôt complexe

[Paul TOTH]

"La peau du cul..." par rapport à quoi ?
En principe elles achètent plus un service qu'un simple logiciel. Notamment la mise à jour réactive suivant la réglementation, le SAV...

T'as déjà vu une paye ou une compta publique ? C'est pour cela qu'il n'y en a pas en libre. Ce n'est pas qu'un développeur, il faut aussi des spécialistes métiers.

pour avoir travaillé en informatique pendant 17 ans dans la fonction publique territorial, j'ai comme une petite de comment ça se passe oui

et je peux dire aussi que même avec un produit du privé tu as intérêt d'avoir des spécialistes métier ET informaticiens pour que ça tourne. Surtout quand ton éditeur décide du jour au lendemain que l'AS/400 c'est mort et qu'il faut faire du Client/Serveur !

[Chuck_Norris]

c'est n'est vrai qu'en parti...ce n'est pas parce que tu utilises une solution libre que tu as la compétence ou les moyens de faire évoluer ce produit s'il devait être abandonné.

Justement, je n'ai pas dit que c'était le client qui devait forcément le reprendre, justement faute de moyens ou de compétences. Par contre, il y a forcément quelqu'un qui pourra le reprendre, car il y a forcément quelqu'un qui aura les moyens ou les compétences nécessaires. Cela sera repris soit par la communauté par passion, ou alors cela sera repris par une boîte contre monnaie sonnante et trébuchante pour le client qui a besoin du produit abandonné, ou alors repris par ta propre société, qui éventuellement embauchera quelqu'un qui aura les compétences requises.

Certes hormis dans le premier cas ce n'est pas gratuit, mais je n'ai jamais prétendu que cela le serait.

Et ce n'est pas un avantage au logiciel propriétaire, non. Car il y a une grande différence entre "il est toujours possible que quelqu'un reprenne le logiciel libre abandonné" et "si la société abandonne son produit propriétaire il n'y a aucun espoir".

[Invité]

Bon, je sens qu'on tombe dans la discussion sur le libre qu'on a tous eu un million de fois déjà...

un logiciel libre qui n'a pas de développeur n'évolue pas, si Apache ou Linux tournait avec une poignée de développeurs sur leur temps libre...ben ça n'existerait pas

Il faut faire une différence entre les fonctionnalités de base, et le code critique. Ce n'est pas la même chose, et ce ne sont pas les mêmes développeurs.

Il me semble qu'on ne parlait *que* de sécurité. A ton avis, combien des développeurs qui contribuent à Apache, ou à Linux, ont une vision précise de la sécurité du produit? Combien testent, comme ils le feraient s'ils étaient payés pour (et que leur entreprise risquait un procès ou une chute du cours de bourse en cas d'erreur)?

ça c'est faux, le code a 10 ans, il est passé entre les mains de tas de développeurs qui ne sont plus là depuis longtemps, la doc n'est pas à jour et la plus grande peur des développeurs actuels c'est que tout leur saute à la tête ^^

C'est une vision de SSII, qui de toute façon a un intérêt financier à produire du code pourri (c'est tout le défaut de la vision du développement comme service, d'ailleurs).

Sur la partie sécurité d'un logiciel développé par une entreprise sérieuse, tu auras des specs, et des devs formés.

bon c'est sans doute peut-être pas le cas partout, mais c'est souvent comme ça !

C'est le cas chez des SSII qui crachent du code de gestion au kilomètre. C'est un autre sujet.

On doit pouvoir trouver des contres-exemples partout, mais de mon expérience, privé ne veux pas dire clean loin s'en faut...

Non, pas plus que libre veut dire "bien fait", "correct" ou "maintenu". Le reste, c'est de l'idéologie. C'est tout ce que j'essayais de dire...

Francois

[el_slapper]

... et la recherche de failles est facilitée. La fiabilité dépend alors du rapport entre le nombre de ceux qui cherchent des failles pour les corriger, et de ceux qui cherchent des failles pour les exploiter.

La recherche de failles est facilitée, du coup, elles sont corrigées plus vite. Beaucoup plus vite.

Du coup, l'argument ne tient que si on part du principe que les développeurs ne sont pas très impliqués dans la sécurité de leur logiciel (et donc qu'il faudrait ouvrir le code aux utilisateurs), et que les utilisateurs sont en majorité des gentils qui ne cherchent pas à exploiter les failles qu'ils détectent. C'est peut être vrai dans certains domaines, mais j'ai comme un doute, quand même.

Il suffit d'un gentil compétent. C'est ça, le truc. En propriétaire, il suffit d'un salopard pour exploiter la faille. En libre, d'un gars bien pour la clore à jamais.

Sinon, on pourrait faire remarquer qu'avec un code fermé, les "gentils" (les développeurs du logiciel), ont normalement une longueur d'avance sur les "méchants" (les utilisateurs qui cherchent à exploiter les failles). Ca ne garantit pas la sécurité (rien ne le fait), mais ça devrait y contribuer.

Si les gentils n'ont même pas idée que leur code est vulnérable, ils sont cuits.

Ca me parait douteux... Si je trouve une faille dans un système, je peux publier cette faille, ou ne pas le faire. Que le système soit ouvert ou fermé ne change rien à l'affaire.

Sauf que si un autre la trouve, et la publie, il reçoit des fleurs, et tu restes dans l'anonymat. L'orgueil des hackers est un outil puissant.

Je crois que la raison pour laquelle on préfère utiliser des méthodes de chiffrement publiées est qu'il s'agit d'un sujet notoirement difficile, où il est très facile d'avoir de fausses bonnes idées. Du coup, une méthode secrète est toujours considérée comme douteuse.

ça, ça vaut pour tous les domaines.

De là à dire que publier un algorithme le fiabilise...

Ben si. Je n'ai fait qu'effleurer le sujet dans mes liens, mais des décénnies de recherches, d'expériences et de publications le prouvent. Tu as des publications qui vont dans l'autre sens?

[Marco46]

Il me semble qu'on ne parlait *que* de sécurité. A ton avis, combien des développeurs qui contribuent à Apache, ou à Linux, ont une vision précise de la sécurité du produit? Combien testent, comme ils le feraient s'ils étaient payés pour (et que leur entreprise risquait un procès ou une chute du cours de bourse en cas d'erreur)?



C'est une vision de SSII, qui de toute façon a un intérêt financier à produire du code pourri (c'est tout le défaut de la vision du développement comme service, d'ailleurs).

Sur la partie sécurité d'un logiciel développé par une entreprise sérieuse, tu auras des specs, et des devs formés.



C'est le cas chez des SSII qui crachent du code de gestion au kilomètre. C'est un autre sujet.




Non, pas plus que libre veut dire "bien fait", "correct" ou "maintenu". Le reste, c'est de l'idéologie. C'est tout ce que j'essayais de dire...

Francois

Ce que tu ne sembles pas vouloir admettre c'est que 95% 75% des développeurs qui travaillent sur Apache ou le noyau Linux sont salariés exactement comme les autres.

Simplement au lieu de travailler sur un projet à sources fermées ils travaillent sur un projet à sources ouvertes.

[Invité]

Sauf que si un autre la trouve, et la publie, il reçoit des fleurs, et tu restes dans l'anonymat. L'orgueil des hackers est un outil puissant.

Ca devrait valoir pour le propriétaire également. Mais note bien que très souvent, on repère les failles après avoir constaté leur exploitation.

Je crois que ca montre la limite de l'orgueil des hackers...

Ben si. Je n'ai fait qu'effleurer le sujet dans mes liens, mais des décénnies de recherches, d'expériences et de publications le prouvent. Tu as des publications qui vont dans l'autre sens?

Des algorithmes publiés, qui se révèlent fautifs des années après, parfois parce que personne ne les a regardé de près, il y en a un paquet (et pas que dans le domaine de la sécurité). Autant de cas ou la publication ne fiabilise rien, simplement parce qu'on publie énormément.

Des organismes qui ont recours à des algorithmes secrets, je t'ai déjà cité les états. Tu dois savoir comme moi que la NSA est le premier employeur de mathématiciens. Je pense que son équivalent chinois n'est pas loin derrière. S'ils le font, et si on pense que sur certains domaines théoriques, ils ont probablement quelques décennies d'avance sur la recherche académique (je crois que c'est Schneier qui le faisait remarquer dans un de ses livres), c'est peut être qu'ils croient en la vertu du secret.

Francois

[Paul TOTH]

C'est une vision de SSII, qui de toute façon a un intérêt financier à produire du code pourri (c'est tout le défaut de la vision du développement comme service, d'ailleurs).

Je n'ai jamais travaillé en SSII, je parle en l’occurrence d'éditeurs de logiciels. Un code de qualité c'est chronophage et rarement compatible avec les impératifs budgétaires. Et il y a une grande différence entre un nouveau projet lancé sur de bonnes bases et un produit qui vieux de 10 ou 20 ans ne peut pas subir un lifting sans modifications profondes...et beaucoup de travail.

[Invité]

Un code de qualité c'est chronophage et rarement compatible avec les impératifs budgétaires.

D'abord, je ne crois pas qu'il y ait une corrélation entre code de qualité et temps passé... Il y a une corrélation entre la compétence des développeurs et la qualité de leur code, mais pas forcément avec le temps passé.

Ensuite, les impératifs budgétaires, ca dépend du modèle économique de l'entreprise. Si tu vends un produit à durée de vie courte, licence faible et one shot, sur un marché en crise, tu n'as pas les moyens d'investir beaucoup, et c'est normal.

Si ton produit a une forte valeur ajoutée, tu peux l'installer, et le financer dans la durée, et investir dans la maintenance future est logique.

Et il y a une grande différence entre un nouveau projet lancé sur de bonnes bases et un produit qui vieux de 10 ou 20 ans ne peut pas subir un lifting sans modifications profondes...et beaucoup de travail.

Mon expérience, c'est qu'un nouveau projet n'est JAMAIS lancé sur de bonnes bases. Les bonnes bases, on finit par les avoir après deux ou trois itérations. En ce sens, un produit vieux d'une dizaine d'années, et qui a tenu la durée, est généralement mieux fait.

Francoi

[Marco46]

Des organismes qui ont recours à des algorithmes secrets, je t'ai déjà cité les états. Tu dois savoir comme moi que la NSA est le premier employeur de mathématiciens. Je pense que son équivalent chinois n'est pas loin derrière. S'ils le font, et si on pense que sur certains domaines théoriques, ils ont probablement quelques décennies d'avance sur la recherche académique (je crois que c'est Schneier qui le faisait remarquer dans un de ses livres), c'est peut être qu'ils croient en la vertu du secret.

Francois

Oui ou pour travailler sur la découverte de failles mais garder les résultats pour eux afin de mieux espionner leurs voisins. Ca semble logique mais ça ne rend pas le secret meilleurs pour le commun des mortels, cela montre au contraire que la fiabilité des algorithmes à base mathématiques est bien meilleure que celle des algos basés sur le secret.

Le principe général d'ouvrir à tout le monde l'algo c'est de mutualiser l'effort dans un but commun, sinon chacun devrait réinventer la roue dans son coin, donc moins rentable et moins efficace. Il en va de même pour le logiciel libre, il est plus rentable pour IBM de contribuer fortement à Eclipse et de bénéficier du travail des autres et de vendre le support et les formations que de tout développer from scratch tout seul.

Pour appuyer ce que je disais sur le noyau Linux j'ai trouvé rapidement cet article assez récent (avril 2012). On a donc 75% des commit sur le noyau qui sont le fait d'entreprises contre 16% de particuliers sur leur temps libre. Le reste c'est des universitaires et divers.

Donc ça fait quand même tomber à l'eau la base de ton argumentaire.

[Paul TOTH]

Mon expérience, c'est qu'un nouveau projet n'est JAMAIS lancé sur de bonnes bases. Les bonnes bases, on finit par les avoir après deux ou trois itérations. En ce sens, un produit vieux d'une dizaine d'années, et qui a tenu la durée, est généralement mieux fait.

Francoi

c'est très surprenant comme affirmation...quand je parle de bonnes bases, ce sont des bases de travail...si le projet commence n'importe comment il a peu de chance de rentrer dans l'ordre en cours de route...

[Invité]

c'est très surprenant comme affirmation...quand je parle de bonnes bases, ce sont des bases de travail...si le projet commence n'importe comment il a peu de chance de rentrer dans l'ordre en cours de route...

Les bases dont je parle sont l'organisation des concepts, l'architecture du produit, les parti pris technologiques, tout ce qui va faire que ton produit sera encore maintenable dans cinq ou dix ans.

Mon expérience, c'est que les premières idées qu'on en a sont presque toujours mauvaises, simplement parce qu'on n'a jamais une vision assez claire du problème à résoudre avant de s'y être lancé.

Un projet part donc toujours sur de mauvaises bases, et généralement n'aboutit que parce que ceux qui le mènent ont assez d'humilité pour se renier au fur et à mesure du développement (au lieu de s'enferrer dans de mauvaises idées, et de se cacher derrière les specs, ou les donneurs d'ordres).

Francois

[el_slapper]

fcharton : je pense que sur le sujet de la crypto, Marco46 répond mieux que moi. Le secret, ça donne une fausse impression de sécurité.

(.../...)Un projet part donc toujours sur de mauvaises bases, et généralement n'aboutit que parce que ceux qui le mènent ont assez d'humilité pour se renier au fur et à mesure du développement (au lieu de s'enferrer dans de mauvaises idées, et de se cacher derrière les specs, ou les donneurs d'ordres).

Francois

Là, par contre, je suis 100% d'accord. Le projet bon dès sa "conception", c'est une version 2 ou 3. Et si c'est une version 1, c'est parcque les programmeurs ont fait une version zéro chez le concurrent d'abord...(vécu).

On m'avait prévenu lors de ma formation, en 2000 : 30% du code que vous ferez sera jeté à la poubelle. 30% du code restant ne sera jamais utilisé. 70% du code restant sera assez vite remplaçé.

C'est lié au fait, justement, que le codage lui-même fait partie de la conception. C'est en se frottant à la réalité du code que l'on réalise(au sens britannique du terme de comprendre pleinement) tout ce que l'on avait pas vu lors de la phase de préparation. Cette notion est souvent combattue en France, pays de l'intellect et de l'abstraction, ou la perfection de la pensée ne saurait être salie par le cambouis codistique. La réalité , forcément horrible, ne saurait avoir la moindre influence sur l'excellence conceptuelle de l'élite. (ceci commence à ressembler à un troll, j'arrête donc là).

[Jon Shannow]

Si demain, votre éditeur de logiciel propriétaire coule, ou décide de cesser la commercialisation du produit, ou cesse de faire des mises à jour aussi bien évolutives que de sécurité, ou même de cesser la possibilité d'installer ou d'utiliser votre version existante (par exemple à cause d'une activation par Internet ou téléphone obligatoire), vous faites quoi ? Ben vous n'avez plus qu'à réinvestir dans une nouvelle solution, si elle existe, et prier pour que vous puissiez importer les données dans la nouvelle application vu que le format de vos données est secret (pas systématiquement, certes).

Avec l'open source, le source est disponible. On sait déjà que vous aurez toujours accès au logiciel, pas de souci de fin de commercialisation ou d'activation. Ensuite, si jamais les auteurs originels coulent ou ne veulent plus supporter le produit, hé bien rien ne sera perdu car quelqu'un d'autre, voire votre propre boîte, peut reprendre le produit et apporter les améliorations nécessaires, ou alors au minimum savoir quoi faire pour importer les données dans la nouvelle application, vu que le format des données ne sera pas un format fermé inconnu.

Tout ceci est envisageable quelque soit la taille de la boîte propriétaire. Si Microsoft ne risque pas de couler comme la petite boîte d'informatique au fond du Cantal, en revanche Microsoft abandonne régulièrement des technologies, et c'est pareil pour tout éditeur de logiciel propriétaire. Si dans le libre quelque chose est abandonné, rien n'est perdu : cela peut être repris par n'importe qui.

C'est sans doute pour cela que toute la communauté à eu peur lors du rachat de Sun par Oracle quant au devenir de OOo et de MySQL.
Même si, au final l'histoire finit bien (enfin pour OOo, pour MySQL je ne sais pas ce qu'il en est), et la reprise d'OOo par une équipe qui a produit LO n'a pas rassuré du tout. Les questions qui ont fusé à l'époque sur la fiabilité de l'équipe de reprise et le devenir réel d'OOo n'était pas anodine.

Ce n'est pas pour rien qu'on développe de plus en plus l'EDI. C'est aussi pour avoir la possibilité de ne pas perdre ses données en cas de changement de logiciel (quelle qu'en soit la raison).

Et comme l'a dit quelqu'un, dans certains domaines (compta, paie, trésorerie, ... ) y a pas des masses de logiciels libres.

[Invité]

cela montre au contraire que la fiabilité des algorithmes à base mathématiques est bien meilleure que celle des algos basés sur le secret.

Je ne comprends pas cette nuance. TOUS les algorithmes de chiffrement raisonnables reposent sur une base mathématique. Le principe de tous les chiffres modernes, c'est l'existence d'un "calcul" que la théorie ne permet pas de résoudre simplement, et dans ce domaine, toute avancée théorique est à la fois une avancée du chiffrement et du déchiffrement.

Sachant que les théories utilisées sont TRES pointues, que la plupart des spécialistes de celles ci sont justement employées par des Etats, et que les avancées majeures sont assez rares, il y a un intérêt réel à garder pour soi son savoir faire théorique, et peu d'avantages à se soumettre à une peer-review, qui attirera soit des "gentils pas bons" soit des "bons ennemis".

Le principe général d'ouvrir à tout le monde l'algo c'est de mutualiser l'effort dans un but commun, sinon chacun devrait réinventer la roue dans son coin, donc moins rentable et moins efficace.

Pour l'utilisateur de base, l'intérêt est évident. Pour une agence d'état, il est très faible, simplement parce qu'elle a tout intérêt à laisser les autres réinventer la roue, surtout si celle ci est très difficile à "réinventer".

C'est pareil dans des domaines moins pointus, mais où le savoir faire d'implémentation fait toute la différence. En gros, si la mise au point d'un algorithme est très compliquée, tu n'as pas forcément intérêt à la "partager".

Francois

[Paul TOTH]

fcharton : je pense que sur le sujet de la crypto, Marco46 répond mieux que moi. Le secret, ça donne une fausse impression de sécurité.



Là, par contre, je suis 100% d'accord. Le projet bon dès sa "conception", c'est une version 2 ou 3. Et si c'est une version 1, c'est parcque les programmeurs ont fait une version zéro chez le concurrent d'abord...(vécu).

On m'avait prévenu lors de ma formation, en 2000 : 30% du code que vous ferez sera jeté à la poubelle. 30% du code restant ne sera jamais utilisé. 70% du code restant sera assez vite remplaçé.

C'est lié au fait, justement, que le codage lui-même fait partie de la conception. C'est en se frottant à la réalité du code que l'on réalise(au sens britannique du terme de comprendre pleinement) tout ce que l'on avait pas vu lors de la phase de préparation. Cette notion est souvent combattue en France, pays de l'intellect et de l'abstraction, ou la perfection de la pensée ne saurait être salie par le cambouis codistique. La réalité , forcément horrible, ne saurait avoir la moindre influence sur l'excellence conceptuelle de l'élite. (ceci commence à ressembler à un troll, j'arrête donc là).

je ne sais pas comment vous bossez mais j'aimerai bien vous avoir comme client, à chaque commande je pourrais vendre au moins 3 versions ! Une pour rire, une pour cerner le besoin, et une pour répondre au besoin ... bizarrement mes clients ont des attentes dès le début.

[Marco46]

Je ne comprends pas cette nuance. TOUS les algorithmes de chiffrement raisonnables reposent sur une base mathématique. Le principe de tous les chiffres modernes, c'est l'existence d'un "calcul" que la théorie ne permet pas de résoudre simplement, et dans ce domaine, toute avancée théorique est à la fois une avancée du chiffrement et du déchiffrement.

Sachant que les théories utilisées sont TRES pointues, que la plupart des spécialistes de celles ci sont justement employées par des Etats, et que les avancées majeures sont assez rares, il y a un intérêt réel à garder pour soi son savoir faire théorique, et peu d'avantages à se soumettre à une peer-review, qui attirera soit des "gentils pas bons" soit des "bons ennemis".

Ca ça dépend si tu es attaquant ou défenseur. Si tu es défenseur tu as tout intérêt à publier ton algo et encourager les autres à l'utiliser pour avoir un maximum de retours dessus.

Si tu es attaquant et que tu découvres une faille tu as tout intérêt à la garder pour toi pour pouvoir l'exploiter.

Tu comprends bien que si toutes les entreprises et gouvernements du monde unissent leurs efforts pour mettre au point un algo inviolable (en théorie), ils auront bien plus de ressources disponibles que les "méchants" comme tu dis. Il s'agit donc purement et simplement d'une question d'efficacité. Quand tu veux protéger tes communications c'est plus efficace de partager les infos que de cacher.

C'est marrant que tu discutes un fait qui est accepté par tout le monde dans ce domaine depuis une quinzaine d'années (ptet même plus).

Maintenant tu parlais des mathématiciens engagés par les agences de renseignement et tu pars du principe qu'ils travaillent sur des algos tenus secrets, c'est certainement le cas, je suis certain qu'ils font aussi de la recherche, mais ils doivent également travailler sur l'existant et sur la recherche de failles et publier certains résultats. C'est déjà arrivé que la NSA publie complètement les spécifications d'algorithmes à destination de l'administration et conseillés aux entreprises.

Pour l'utilisateur de base, l'intérêt est évident. Pour une agence d'état, il est très faible, simplement parce qu'elle a tout intérêt à laisser les autres réinventer la roue, surtout si celle ci est très difficile à "réinventer".

L'utilisateur de base c'est pas que le citoyen, c'est aussi les entreprises. Et une agence d'état est quand même censée bosser pour ces deux là. Donc non une agence d'état n'a pas nécessairement intérêt à tout garder pour elle parce que ce n'est pas sa mission. Sa mission de base étant de protéger son pays, donc de protéger ses communications, elle est très souvent en position défensive sur ce sujet.

C'est pareil dans des domaines moins pointus, mais où le savoir faire d'implémentation fait toute la différence. En gros, si la mise au point d'un algorithme est très compliquée, tu n'as pas forcément intérêt à la "partager".

Francois

Alors d'abord l'implémentation d'un algorithme ce n'est pas la mise au point d'un algorithme. L'implémentation c'est la programmation d'un algorithme. Bref la mise en oeuvre de l'idée pour obtenir une API intégrable dans un logiciel.

Et dans les 2 cas tu as tout intérêt à partager, surtout si c'est pointu, pour avoir un maximum de retours afin de le fiabiliser et du coup le populariser. Jamais les entreprises n'accepteront d'utiliser un algorithme dont elles ne connaissent rien.

T'imagines rien que pour le commerce international le bordel que ça serait s'il n'y avait pas de normes communes à ce niveau pour dialoguer de manière sécurisée ? Le commerce international sur internet est possible PARCE QUE les algorithmes sont publiés et ouverts. Sans ça ça serait ingérable.

C'est bien pour cette raison que la plupart des librairies utilisées en sécurité sont opensource, pour une question de confiance. Cela n'a rien à voir, mais absolument RIEN avec les positions de Stallmann sur le logiciel libre la liberté et tout ça. J'insiste, c'est une question d'efficacité et de confiance.

[Taurre]

Tu n'as pas lu le message de Freem ou le texte dont il est question ?

Si, j'ai lu le texte en question. Cependant, ce passage me laisse perplexe :

Si les droits sur le logiciel libre ne sont associés à aucune compensation financière, cela ne veut pas dire qu'il n'en coûte rien de mettre en œuvre et d'utiliser du logiciel libre, en particulier dans le domaine professionnel.

et me semble sous-entendre qu'un logociel libre est forcément gratuit.

Sinon, pour les dons, vous êtes au courant que ce n'est pas le seul moyen de remercier les projets libres ? La participation est beaucoup plus intéressante...

Je n'ai jamais dit le contraire. Je note juste que les dons ne sont pas légions et qu'une solution plus souple de ce côté augmenterait peut-être leur nombre.

[_skip]

Je n'ai jamais dit le contraire. Je note juste que les dons ne sont pas légions et qu'une solution plus souple de ce côté augmenterait peut-être leur nombre.

En effet, cependant il faut le dire franchement, pour un développeur de freeware, les dons c'est un petit sugus qui tombe de temps en temps. Rares doivent être ceux qui vivent de cela sans une structure ou un sponsoring plus sérieux.

Ce qui intéresse les gens avec le libre/gratuit c'est justement de rien payer. Je crois même pas que ça a à y voir avec la facilité du don, c'est juste les gens qui sont comme ça.
Dans le logiciel, puisqu'on est un téléchargeur anonyme sur le net et que le produit est immatériel et duplicable à l'infini, personne ne se sent coupable de profiter gratuitement. On ne se rend jamais compte que tout ça c'est le résultat des dizaines, des centaines, ou des milliers d'heures du travail de quelques uns.
Il n'y a pas de notion d'esthétique dans le logiciel, c'est un truc immatériel, du vent... pour les utilisateurs, si ça ne produit pas directement de valeur ça n'en a pas. Et ces mêmes gens n'auraient en revanche aucun problème à dépenser pour une bagnole, un smartphone à la mode ou un objet matériel de ce genre.

Enfin je voudrai dévier la conversation...