Je n'ai pas été très clair, je vais reformuler. Firefox est un logiciel libre, destiné au grand public (RedHat ne l'est pas par exemple) et qui rapporte beaucoup d'argent à ses auteurs. Je ne voit pas d'autres soft dans ce cas (c'est à dire réunir les 3 critères - des cas qui réunissent 2 critères j'en voit beaucoup), mais je peux me tromper.
Je vais faire plusieurs remarques suite à tes différents posts :
Premièrement tu compares l'argent récoltée par un logiciel libre (avec des dons visiblement) et les prix d'un freelance, ce qui n'a pas beaucoup de sens. Il faudrait comparer à l'argent gagné par un logiciel propriétaire gratuit 'équivalent' et qui accepterait les dons lui aussi. Au final ça ne serait sûrement pas bien différent à mon avis : le don n'est pas un business model valide pour du logiciel.
Tu as l'air de penser qu'un freelance se fait 10 000€ par mois ; si certains s'en sortent certainement très bien, la réalité est bien différente. Il y a les taxes évidemment, mais surtout le freelance ne facture pas tous les jours du mois, vu qu'il va passer un certain temps à trouver des contrats. S'il ne facture rien dans le mois et bien il gagne 0€. Si être freelance c'était la recette facile pour une richesse assurée ça se saurait hein. Ceci dit tu es libre de faire freelance à mi-temps (et gagner 5000€ par mois selon toi) et faire du libre bénévolement le reste du temps…
Il est clair de gagner sa vie comptant sur les dons (ou même en vendant) un logiciel libre pour le grand public ça ne marche pas malheureusement : Firefox est l'exception (et ce n'est pas une entreprise), Mandrake ne faisait pas que vendre son logiciel etc… Il faut vendre quelque chose qui apporte un plus. À une entreprise tu vends du support, de la formation, des jours de développement spécifique. Pour un particulier, il faut trouver autre chose ; par exemple sur pokecraft tu pourrais vendre les assets (et ne pas les mettre sous une licence libre), si ça te semble acceptable (parce que du coup le soft n'est pas vraiment libre). Tu serais assez vite fixé sur le nombre de gens réellement prêts à payer, et ce n'est pas du tout dit que tu gagne un smic.
À coté de ça, les jeux libres sortent régulièrement des releases mais le jeu ne passe rarement la phase de développement
Je me demande depuis longtemps si ça serait envisageable que la communauté des libristes rachète les sources (code et assets) de jeux propriétaires ; un peu comme pour Blender, mais en allant chercher les éditeurs (alors que NaN a fait sa proposition lors de sa faillite). Par 'envisageable' j'entends 'combien ils demanderaient' (vu que tout à un prix). Je pense principalement à:
des jeux indépendants ayant reçu de bonnes critiques mais étant passé un peu à coté de leur public.
des jeux un peu anciens et plus commercialisés.
Dans les 2 cas peut être pourrait-on obtenir la libération pour un prix attractif, les ayants droits recevant une somme inespérée.
Comme tu le dis, les jeux libres faits bénévolement passent rarement la phase de développement : c'est dur, il faut un moteur, suffisamment de ressources graphique et sonores, des niveaux bien conçus, pas mal de polish… En revanche pour un soft ayant déjà atteint un bon niveau (voire ayant déjà une communauté), le développement serait plus attractif. Je pense à Blender ou à Warzone 2100 qui sont de bons exemples ; ou même, dans un genre très différent, TrackMania, qui démontre que beaucoup de joueurs sont prêts à faire de la création pour un jeu qui les amuse.
Tu prends un exemple où les choses se passent plutôt bien à l'heure actuelle: un projet bien défini, 100% informatique où des tonnes de solutions toutes prêtes existent.
Non pas forcément. Quand tu te mets à utiliser un ERP, il faut beaucoup de customisation derrière quel que soit le degré de finition de l'ERP (et donc ça ne se passe toujours bien du tout).
si une entreprise s'arrange pour avoir dans son personnel (managers, ingénieurs) quelques personnes qui savent programmer, alors […]
Oui je suis d'accord, si elle arrive a avoir des gens qui savent en plus programmer, ça va être cool pour elle. Mais comment font les employeurs profanes en info pour savoir si un de leurs managers sait programmer ? Dans la vraie vie, le gars-qui-sait-programmer (selon le profane) c'est souvent un gars qui à réussi à faire une macro Excel. Pour l'avoir vu un bon nombre de fois, ça finit en souvent une appli interne infâme en Access ou en WinDev totalement non maintenable.
Je ne dis pas que sous traiter change cet état de fait, je dis juste que "il suffit de trouver quelqu'un qui sait programmer" ça sonne bien, mais il n'y pas de solution magique malheureusement.
Je ne suis pas sûr de te suivre. Tu veux dire que si une entreprise qui fait, par exemple, de l'ébénisterie, et fait toute sa gestion manuellement depuis des années, veut mettre en place une gestion informatisée (stocks, clients, commandes etc…), elle doit chercher un ébéniste qui sait programmer ?
Ah mais on est d'accord. Le pire c'est les boites qui arrivent à sous traiter leur coeur de métier où elles sont compétentes en interne, à des gens moins compétents (oui ça existe) !!
Je dis juste que quand on n'y connait rien, embaucher ou sous-traiter sera difficile ; si le mec qu'on embauche (que ce soit pour se constituer des compétences en interne, ou pour surveiller la sous traitance) est mauvais, et bien la suite s'annonce compliquée.
Pour la petite histoire, le SI de bras cassés a passé, au début, le plus clair de son temps à faire croire au patron que c'est nous qui étions la cause des problèmes de la bonne marche du projet (plutôt que de faire son boulot). Depuis, le patron a finit par comprendre qu'ils payaient toute une bande d'incapables depuis des années, et il cherche à dégraisser…
Mon commentaire disait justement qu'on a le même problème avec les employés ! Si tu es incapable de comprendre que tes employés sont incompétents, tu seras incapable de savoir que ton sous-traitant est incompétent.
Je me suis peut être mal exprimé : je parlais précisément de mon 2ème exemple ; ces gens ont pondu une espèce d'ERP en PHP/MySQL. Donc oui, ils sont censés savoir faire une requête SQL (et les preuves de leur incompétence sont nombreuses, mais peu importe).
cest que les ssii essayent de tout faire et du coup ne font rien correctement
Je n'ai pas dit le contraire ; en fait j'ai même dit que je n'aimais pas les SSII…
les entreprises devraient commencer à embaucher quelques employés qui savent utiliser un ordinateur
Si je suis d'accord dans le fond (j'ai horreur des grosses SSII), ce n'est pas forcément aussi simple que ça. En effet, lorsque ladite entreprise n'a pas la culture informatique (ce n'est pas du tout son métier), et bien c'est difficile pour elle d'embaucher des gens compétents : ils sont rares, contrairement aux incompétents qui ont appris à cacher leur incompétence (surtout à ceux qui n'y connaissent rien). J'ai vu ce cas de figure à 2 échelles ; une fois un petit service informatique de 4 personnes dans une PME de quelques centaines d'employés, et une fois un service informatique de 150 personnes pour une entreprise de la grande distribution. Dans ce 2ème cas, les plus compétents du lot arrivent difficilement à pondre une requête SQL simpliste en 3 jours… Au moins le sous-traitant on peut s'en débarrasser un peu plus facilement.
et les geeks végètent en SSII
Mouais. Contrairement à un ouvrier peu qualifié qui n'a pas trop le choix, un informaticien compétent peut trouver un boulot sympa s'il s'en donne la peine. S'il se contente des mêmes SSII qui embauchent tous les bras cassés, et ben il ne peut s'en prendre qu'à lui même.
Je parlais bien d'un « et ». On va dire qu'effectivement on ne peut pas toujours améliorer à la fois tous les critères que j'énumère, mais 2 ou 3 sans dégrader les autres est très souvent possible. Je travaille beaucoup avec des (talentueux) juniors, mais bien souvent ils se contentent de faire du code qui marche (ce qui est déjà bien) ; j'essaie de relire systématiquement leur code, et je les surprends souvent en améliorant tous (ou du moins la plupart) de ces critères. Et leur code est bien meilleur que ce que j'ai pu voir écrit par le mec lambda en SSII, ce qui doit représenter une grosse partie du code écrit dans le monde. Je n'ai évidemment pas la prétention d'en faire de même dans le kernel, mais l'informaticien de gestion de base n'est pas Linus Torvalds malheureusement…
Et moi je me suis toujours demandé comment on pouvait être aussi sûr qu'un code n'est "pas correct".
Autant il est difficile de dire qu'un code est correct, autant il est bien souvent facile de montrer qu'un code ne l'est pas. Si on peut le réécrire en 3 fois moins de lignes, en plus simple, plus robuste, plus lisible et plus performant, c'est que le vieux code n'était pas bien fameux.
Heu c'est normal d'avoir 50 après 15 (alors que les autres constantes vont en décroissant) ?
PS: en tant que développeur python, j'aurai créé un alias du genre "diff = self.f.score - self.old_score", histoire de gagner en lisibilité et en performance.
Un bémol cependant : il me semble que des fonctionnalités obligatoires du C99 vont devenir optionnelles dans la version suivante (genre les nombres complexes). Si c'est le cas, un code C99 (utilisant ces fonctionnalités) ne passera pas forcément sur un compilateur C11.
Ça a déjà été galère quand j'ai mis à jour ma machine de 2.5 vers 2.7 (je ne connais que très très peu python)
Je souhaite bon courage aux pythonistes pour maintenir leur code à chaque évolution de leur langage.
Il n'y a pas à toucher un programme qui tourne en 2.5 pour qu'il tourne en 2.7 : la cassure est avec la branche 3, les versions d'une même version ont bien heureusement la compatibilité ascendante.
Personne n'a envie de réécrire des millions de lignes de code en f77 qui fonctionnent bien et ont été méticuleusement testées sur au moins vingt ans, et tout le monde veut bien les utiliser.
C'est bien ce que je dis, il y au moins une personne qui passe son temps libre, ou bien qui est payée, pour maintenir f77 dans GCC. Si demain ce n'est plus le cas, et que tu es le dernier utilisateur, tu devras aussi te garder sous le coude la dernière distribution gérant f77, et utiliser une machine virtuelle par exemple.
Si ces projets ne sont pas activement maintenus (les étudiants finissent leur thèse puis passent à autre chose), il sera impossible de les exécuter quelques années après l'abandon de python2. Ou alors avec un vieux livecd de 2012, s'ils démarrent encore sur les ordinateurs de demain.
Je ne sais pas quand le support de Python2.7 sera perdu dans la pratique ; si des tas de gens sont prêts à payer pour qu'il soit maintenu (plutôt que passer les 2h à modifier leur programme) ça peut être dans longtemps (de base le projet Python a tablé sur 5 ans, mais dans les distributions comme Debian ça devrait être là plus longtemps). Mais effectivement, si en 2025 tu es vraiment intéressé pour faire tourner le code de tes thésards de 2010, tu devras peut être te garder une Debian de 2024 + Machine Virtuelle, c'est bien triste pour toi. Quelque chose me dit que si personne n'est motivé pour passer quelques heures sur ces programmes d'ici 15 ans, c'est qu'ils ne doivent pas être si utiles que ça... Je peux comprendre cependant que tu sois déçu.
Mes scripts perl qui ont 10 ans sans maintenance dans /usr/local/bin
Pareil que f77 (quelqu'un fait la maintenance).
Tout cela est une histoire d'offre et de demande en quelque sorte. Une communauté peut se former pour faire Python2.8, Python2.9 etc.. qui ne cassent pas la compatibilité. Si ça ne se fait pas, c'est que les "conservateurs" ne sont pas prêts à payer, simplement.
Je ne dis pas que l'approche de Python ("progressiste") est mieux que l'approche Fortran ("conservatrice"); les 2 ont leurs avantages et leurs inconvénients. L'approche des langages n'est que le reflet de leur communauté ; il faut croire que la communauté Python préfère corriger les petites erreurs (je le répète, elles sont petites), plutôt que de pénaliser les futures implémentations. Je préfère l'approche Python, sans nier qu'elle a aussi des inconvénients ; tous les choix techniques sont des compromis, je l'ai déjà dit.
En ce qui me concerne faire évoluer mes programmes n'est pas une contrainte mais une véritable philosophie (et même un grand plaisir).
Cette notion que casser des programmes qui marchent, c'est toujours "les améliorer" me fatigue. Un programme qui a été développé, qui marche bien, qui est en prod depuis plusieurs années, pourquoi devrait-il être modifié ?
Je ne force personne à changer son code (enfin sauf mes collègues ! :) ). Ceci dit, je pense que dans l'ensemble, en informatique, on souffre beaucoup plus du pattern "ah oui ce truc a été écrit par Jean-Louis y a 15 ans, personne ne sait ce que ça fait exactement alors on y touche pas" que gens qui aiment réécrire leur code en mieux.
Ça ne veut pas dire qu'ils faillent tout refaire depuis zéro tous les 3 mois ; mais dans le cas présent passer 2 jours en 10 ans, ça me paraît acceptable. Tous les choix techniques sont des compromis, et en tant que Pythoniste je suis content que cela soit cette voie qui soit prise (plutôt que l'immobilisme de Java par exemple).
De toutes les façons, il ne faut pas rêver, un système informatique nécessite de la maintenance, l'immortalité n'est pas de ce monde. Si il veut recompiler son programme Fortran77 avec le dernier GCC et bénéficier des dernières optimisations, il faut que des gens aient porté Fortran77 avec la dernière infrastructure de GCC. S'il veut juste tourner sur le dernier Linux sans recompiler son programme, il faut que les développeurs Linux fassent attention à ne pas casser l'ABI. Si il ne veut rien changer du tout au soft, et compte faire tourner la bécane telle quelle pendant 30 ans, il lui faudra quand même prévoir des pièces de rechange, car le hardware ça vieillit.
Mais si un jour plus personne n'est prêt à payer (en temps ou en argent peu importe) pour que Fortran77 soit maintenu dans GCC, et bien le support sera jeté, c'est comme ça. Mais croire que ne rien toucher suffira pour que ça continue à marcher comme avant, alors que le coeur de GCC aurait été réécrit pour bénéficier des dernières avancées en terme de compilation, c'est se mettre le doigt dans l'oeil. On ne peut pas avoir le beurre et l'argent du beurre.
Pour l'instant la communauté Fortran77 est sûrement assez active, peut-être même que des tas de gens sont prêts à payer pour ne pas avoir à changer leur vieux code. Mais au final il y a forcément des gens qui payent cette maintenance. Et comme c'est du libre, on peut en profiter sans avoir soi-même payer quoi que soit ; mais rien de magique la dedans.
En fait nous sommes d'accord je pense, je voulais juste tempérer tes propos. Parce que la phrase "le compilateur n'a qu'a optimiser", je l'ai souvent entendu prononcée par des mauvais codeurs, qui pondent 100 lignes de code toutes pourries, là où 10 lignes simples suffisaient (mais fallait utiliser sa tête).
D'ailleurs, quand on réécrit du code en 4 fois de lignes, en ayant la volonté première d'avoir un code plus simple, lisible et maintenable, mais qu'en bonus le code devient plus rapide, est-ce de l'optimisation ?
ça sous-entend déjà qu'ils pourraient décider d'arrêter et ça rassure pas du tout pour la pérennité de l'éventuel code que je pourrais écrire si je m'y mettais.
Ce n'est pas un sous entendu : le destin de la branche 2 est de mourir, remplacée par la branche 3 (encore une fois les différences sont minimes et valent le coup à mon avis). Donc effectivement, si ta façon de bosser est d'écrire du code, et de ne plus y toucher pendant 30 ans, alors non le Python n'est pas pour toi. Mon post n'avait pas pour but de faire la promotion de Python, il a déjà une active communauté (que d'autre bons langages n'ont pas).
Il faut bien voir qu'une nouvelle version de Python sort en moyenne tous les 2 ans, avec à chaque fois des fonctionnalités bien vues, qui vont permettre d'améliorer lentement mais sûrement les applications. Passer de Fortran77 a Fortran90, ça serait comme passer de Python1.0 à Python3.0, ce que personne ne fait, ne serait-ce que parce que personne n'utilise plus la branche 1, et les premières versions de la branche 2 ne doivent plus l'être non plus. Si il y avait eu Fortran79, Fortran81, etc... avec à chaque fois tous les compilateurs mis à jour en même temps, des fonctionnalités alléchantes mais qui permettent une évolution progressive, peut-être que ton code Fortran77 aurait été amené en douceur vers Fortran90, pour un code plus simple et maintenable (peut être même plus efficace, je ne connais pas Fortran).
Je pratique (ou ai pratiqué) le C++ et le Python à titre personnel comme à titre professionnel, et ce sont 2 langages que j'affectionne beaucoup.
Je vais répondre à la pique sur Python. Tu penses que la cassure Python2/Python3 est une erreur, et tu as raison dans la mesure où, si cette politique était appliquée au C++, cela provoquerait une catastrophe. Mais les situations de Python et de C++ sont très différentes, et donc ce qui est bon pour l'un ne l'est pas forcément pour l'autre. Je m'explique.
Le Python a une implémentation de référence (CPython), qui est utilisée par 99% des gens. On peut trouver ça dommage. Mais bon cette implémentation est libre, gratuite, multiplateforme, plutôt performante, ce qui fait que globalement on n'a pas trop à se plaindre.
Du coup quand une nouvelle version sort, on peut si on le veut utiliser les nouvelles fonctionnalités tout de suite, pas la peine de se demander quand est-ce que la majorité des implémentation auront un support suffisant (par exemple la gestion catastrophique des templates par VC++6), ou bien de faire plusieurs version du même code suivant le compilateur (avec de la compilation conditionnelle). Pas non plus de fonctionnalité dans le standard mais implémentée par personne ('import' du C++).
La branche 2 sera maintenue par l'équipe Python pendant des années ; en plus les dernières versions de cette branche (2.6, 2.7) se sont beaucoup rapprochées de la branche 3. Au final l'effort à fournir est minime (et il existe un outil officiel qui fait la conversion) et on a des années pour faire ce petit effort. À côté de ça, dans la pratique, malgré la non cassure du monde C++, si tu trouves un vieux projet C++ qui a traîné des années sans avoir bougé, pas sûr qu'il compilera sans problème, pour peu qu'il s'appui sur d'autres bibliothèques qui elles auront évolué. De toutes les manières un code non maintenu finit par mourir.
Il y a évidemment bien moins de logiciel en Python qu'en C++, et leur code est sûrement bien plus petit (c'est bête mais pragmatique).
Je vis en faisant du Python (c'est donc un peu plus qu'un simple amusement sans conséquence), et le passage à Python3 ne m'effraie du tout, j'ai même hâte de le faire.
Les langage C++ et Python évoluent de manière différente, mais à mon avis les 2 le font assez bien (même si je suis assez déçu de la dernière version de C++).
(En même temps, c'est un faux argument, ce n'est pas à l'humain de faire les optimisations mais au compilateur.)
C'est un peu plus compliqué que ça malheureusement. Même dans les langages fonctionnels, il est par exemple conseillé de faire des récursions terminales, histoire d'utiliser efficacement la pile. Or la version avec récursion terminale est souvent un peu moins jolie que la version naïve.
Peut être que des compilateurs sont capable de faire cette transformation tout seuls cela dit (je ne suis pas un spécialiste), mais je pense que le programmeur aura toujours une part de responsabilité dans l'optimisation.
Malgré les qualités intrinsèque de FireFox (et plus récemment de Chrome), il est clair qu'il a percé aussi parce que IE6, pourtant installé de base sur 90% des machines de bureau, est une vraie bouse. Je pense qu'en limitant la casse (en laissant une poignée ingénieurs sur le projet) afin de le rendre juste assez médiocre pour que la fuite des utilisateurs soit faible, IE serait encore en quasi monopole. Et du coup Bing serait sûrement bien moins à la traîne.
En somme pour économiser quelques dollars, ils ont craché à la figure de millions d'utilisateurs, et maintenant des milliards leur passent sous le nez. Ahah, bien fait !
peut t'on comparer l'équipe gambas ... a celle d python ... elle est égale a celle de python après ses 10 premières années ...
C'était une boutade hein, je me doute que l'équipe de Gambas est petite et a mieux à faire. Ceci dit le typage statique de Gambas faciliterait peut-être la compilation, comparé à des langages comme JavaScript ou Python (mais ça reste un gros travail).
On est systématiquement mis au défit et comparé aux gros du moment.
Ah ben ça c'est tout à fait normal. Du moment que tu dis aux gens d'utiliser ton logiciel, ils vont forcément se demander pourquoi le tien et pas un autre. C'est d'autant plus vrai pour un langage de programmation : il est assez facile de changer de navigateur Web ou de lecteur multimédia, mais quand on se lie à un langage cela a plus de conséquences. Ce n'est pas pour rien qu'il y a des tas de langages (libres) de qualité avec une faible communauté.
Comme le disait Benoit, l'important c'est la maitrise de l'outil, sa compréhention, son adaptabilité. C'est a ce jeu que gambas est bon.
Ce qui est bon aussi, c'est l'ide, pas forcément révolutionnaire mais de plus en plus complète et j'oserais a ce titre dire unique dans le monde du libre.
Il faudrait peut-être rentrer plus dans les détails sur ces qualités (être "vendeur", ce n'est pas péjoratif).
En quoi un utilisateur de Gambas maîtrise plus Gambas q'un utilisateur Python maîtrise Python ?
Qu'entends-tu par "adaptabilité" par exemple ? Tu parles de modifier l'interpréteur lui-même ?
Pour l'IDE, quelles sont ces qualités par rapport à QtDesigner (pour ne citer que la référence libre) ?
Pour ce qui est de la vitesse d'excution, a l'affichage en gui on attend moins un programme gb qu'un py. Voila un ressenti :-)
Pour avoir fait du python embarqué temps réel, je dirais que la façon de coder importe plus que le langage. Par exemple un langage rapide ne dispense pas de jouer avec l’asynchronisme pour rendre une application vraiment réactive.
J'ai fait de très mineures modifications histoire que ça soit plus pythonique :
#!/usr/bin/pythonn=500000x=0.2deft(x):mu=10.0pu=0.0pol=[0]*100r=range(0,100)foriinxrange(0,n):#Ici xrange pour pas allouer une grosse liste pour rienforjinr:pol[j]=mu=(mu+2.0)/2.0su=0.0forvalinpol:#ici j'itère sur la liste histoire de ne pas passer inutilement par un indicesu=x*su+valpu+=su# += pour faire bôreturnpuforiinrange(0,10):printt(x)
Je passe sur ma machine de 231.824s à 209.599s, soit presque 10% de gain. Gambas reste donc bien plus rapide, ce qui montre bien que le typage statique permet des optimisations intéressantes, même avec un simple interpréteur.
Et (après avoir installé Psyco !) le code s'exécute en 84.306s, soit presque 3 fois plus rapidement. Évidemment Psyco c'est que x86 et plus trop maintenu, mais ça donne une idée de ce qu'on va avoir avec PyPy qui est annoncé comme 5 fois plus rapide que CPython.
L'équipe de Gambas relèvera-t-elle le défi en implémentant du JIT (le suspens est à son comble) ?? :)
J'en profite au passage pour féliciter ladite équipe pour son travail.
Comme le dit Zenitram au dessus, tu oppose libre et commercial, mais ce sont 2 concept orthogonaux. La double licence TrollTech, c'était libre vs propriétaire. Du moment que tu fais du libre, tu n'empêche pas les concurrents de faire du commercial ; tu peux juste les empêcher de faire du propriétaire (licences *GPL), mais même pas les obliger à contribuer avec toi.
Encore une fois la protection du code, pour nous qui vendons du service, n'est pas une problématique. Les mauvais payeurs sont un problème par exemple, pas les "voleurs" de code.
Mais admettons que tu n'aies pas fait la confusion propriétaire/commercial ; il est clair que TrollTech était confronté à un problème de business model dans le libre : ils pouvaient difficilement vendre du service autour de Qt. Ils en vendaient (support etc...), mais leurs utilisateurs sont des techniciens et n'en pas souvent besoin. Et c'est encore plus un problème dans le cas de produit pour le grand public ; il est clair qu'on ne peut transposer le modèle propriétaire classique dans le monde du libre, et c'est bien embêtant. Les réponses changent donc en fonction du type de logiciel ; mais encore une fois, pour beaucoup la "non-protection" n'est pas gênante.
Oui la question est intéressante. Une première réponse et après au dodo.
Faire du libre est déjà pour nous une démarche militante. Ce n'est pas une volonté issue d'une étude de marché pointue qui nous aurait démontré que dans notre cas c'est plus rémunérateur ; évidemment il n'est pas question non plus de partir au casse-pipe. Mais avant nous faisions de l'intégration VTiger (un autre CRM libre), et on a bien vu que sur ce marché très concurrentiel, en travaillant sérieusement nous arrivions à gagner notre vie.
La concurrence est déjà rude, et les CRM libres s'en sortent plutôt bien ; ça ne ferait qu'un concurrent de plus au final.
Pour le moment en tout cas, le fait que notre boite soit jeune et petite est le plus gros problème pour lutter face aux gros ; le fait de faire du proprio n'y changerait pas forcément grand chose (c'est discutable toutefois, car on aurait du coup peut-être accepté des financements qu'on refuse justement pour pouvoir garder le contrôle et rester libres). Du coup que des gens utilisent notre soft serait plutôt synonyme de publicité.
On a écrit la moindre des lignes de Creme, alors quand il faut le customiser nous sommes efficaces forcément. Si nous n'arrivons pas à nous démarquer face à un concurrent faisant du Creme "sauvage" c'est que nous devons nous améliorer (mais oui c'est plus rude que de vivre de rentes comme avec le proprio).
Au final je dirais que ce problème d'auto concurrence est un peu une chimère, mais c'est vrai c'est LA question que nous posent les gens habitués au monde propriétaire. À part nous empêcher un jour d'ériger un monopole (ce qui est une bonne chose, ils ne sont pas souhaitables), ça n'est pas un gros problème.
[^] # Re: Confusion...
Posté par GuieA_7 (site web personnel) . En réponse au message Différence de prix open-source/propriétaire. Évalué à 1.
Je n'ai pas été très clair, je vais reformuler. Firefox est un logiciel libre, destiné au grand public (RedHat ne l'est pas par exemple) et qui rapporte beaucoup d'argent à ses auteurs. Je ne voit pas d'autres soft dans ce cas (c'est à dire réunir les 3 critères - des cas qui réunissent 2 critères j'en voit beaucoup), mais je peux me tromper.
# Confusion...
Posté par GuieA_7 (site web personnel) . En réponse au message Différence de prix open-source/propriétaire. Évalué à 3.
Je vais faire plusieurs remarques suite à tes différents posts :
En espérant avoir éclairé ta lanterne.
[^] # Re: Jeux libres
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Regrouper les efforts pour les jeux vidéos libres. Évalué à 2.
+ 1Je me demande depuis longtemps si ça serait envisageable que la communauté des libristes rachète les sources (code et assets) de jeux propriétaires ; un peu comme pour Blender, mais en allant chercher les éditeurs (alors que NaN a fait sa proposition lors de sa faillite). Par 'envisageable' j'entends 'combien ils demanderaient' (vu que tout à un prix). Je pense principalement à:
Dans les 2 cas peut être pourrait-on obtenir la libération pour un prix attractif, les ayants droits recevant une somme inespérée.
Comme tu le dis, les jeux libres faits bénévolement passent rarement la phase de développement : c'est dur, il faut un moteur, suffisamment de ressources graphique et sonores, des niveaux bien conçus, pas mal de polish… En revanche pour un soft ayant déjà atteint un bon niveau (voire ayant déjà une communauté), le développement serait plus attractif. Je pense à Blender ou à Warzone 2100 qui sont de bons exemples ; ou même, dans un genre très différent, TrackMania, qui démontre que beaucoup de joueurs sont prêts à faire de la création pour un jeu qui les amuse.
[^] # Re: Mauvaise organisation des entreprises
Posté par GuieA_7 (site web personnel) . En réponse au journal De l'incompétence comme moteur de l'économie…. Évalué à 2.
Non pas forcément. Quand tu te mets à utiliser un ERP, il faut beaucoup de customisation derrière quel que soit le degré de finition de l'ERP (et donc ça ne se passe toujours bien du tout).
Oui je suis d'accord, si elle arrive a avoir des gens qui savent en plus programmer, ça va être cool pour elle. Mais comment font les employeurs profanes en info pour savoir si un de leurs managers sait programmer ? Dans la vraie vie, le gars-qui-sait-programmer (selon le profane) c'est souvent un gars qui à réussi à faire une macro Excel. Pour l'avoir vu un bon nombre de fois, ça finit en souvent une appli interne infâme en Access ou en WinDev totalement non maintenable.
Je ne dis pas que sous traiter change cet état de fait, je dis juste que "il suffit de trouver quelqu'un qui sait programmer" ça sonne bien, mais il n'y pas de solution magique malheureusement.
[^] # Re: Mauvaise organisation des entreprises
Posté par GuieA_7 (site web personnel) . En réponse au journal De l'incompétence comme moteur de l'économie…. Évalué à 1.
Je ne suis pas sûr de te suivre. Tu veux dire que si une entreprise qui fait, par exemple, de l'ébénisterie, et fait toute sa gestion manuellement depuis des années, veut mettre en place une gestion informatisée (stocks, clients, commandes etc…), elle doit chercher un ébéniste qui sait programmer ?
[^] # Re: Mauvaise organisation des entreprises
Posté par GuieA_7 (site web personnel) . En réponse au journal De l'incompétence comme moteur de l'économie…. Évalué à 2.
Ah mais on est d'accord. Le pire c'est les boites qui arrivent à sous traiter leur coeur de métier où elles sont compétentes en interne, à des gens moins compétents (oui ça existe) !!
Je dis juste que quand on n'y connait rien, embaucher ou sous-traiter sera difficile ; si le mec qu'on embauche (que ce soit pour se constituer des compétences en interne, ou pour surveiller la sous traitance) est mauvais, et bien la suite s'annonce compliquée.
Pour la petite histoire, le SI de bras cassés a passé, au début, le plus clair de son temps à faire croire au patron que c'est nous qui étions la cause des problèmes de la bonne marche du projet (plutôt que de faire son boulot). Depuis, le patron a finit par comprendre qu'ils payaient toute une bande d'incapables depuis des années, et il cherche à dégraisser…
[^] # Re: Mauvaise organisation des entreprises
Posté par GuieA_7 (site web personnel) . En réponse au journal De l'incompétence comme moteur de l'économie…. Évalué à 2.
Mon commentaire disait justement qu'on a le même problème avec les employés ! Si tu es incapable de comprendre que tes employés sont incompétents, tu seras incapable de savoir que ton sous-traitant est incompétent.
D'où le fait que je dise que c'est compliqué.
[^] # Re: Mauvaise organisation des entreprises
Posté par GuieA_7 (site web personnel) . En réponse au journal De l'incompétence comme moteur de l'économie…. Évalué à 1.
Je me suis peut être mal exprimé : je parlais précisément de mon 2ème exemple ; ces gens ont pondu une espèce d'ERP en PHP/MySQL. Donc oui, ils sont censés savoir faire une requête SQL (et les preuves de leur incompétence sont nombreuses, mais peu importe).
Je n'ai pas dit le contraire ; en fait j'ai même dit que je n'aimais pas les SSII…
[^] # Re: Mauvaise organisation des entreprises
Posté par GuieA_7 (site web personnel) . En réponse au journal De l'incompétence comme moteur de l'économie…. Évalué à 1.
Si je suis d'accord dans le fond (j'ai horreur des grosses SSII), ce n'est pas forcément aussi simple que ça. En effet, lorsque ladite entreprise n'a pas la culture informatique (ce n'est pas du tout son métier), et bien c'est difficile pour elle d'embaucher des gens compétents : ils sont rares, contrairement aux incompétents qui ont appris à cacher leur incompétence (surtout à ceux qui n'y connaissent rien). J'ai vu ce cas de figure à 2 échelles ; une fois un petit service informatique de 4 personnes dans une PME de quelques centaines d'employés, et une fois un service informatique de 150 personnes pour une entreprise de la grande distribution. Dans ce 2ème cas, les plus compétents du lot arrivent difficilement à pondre une requête SQL simpliste en 3 jours… Au moins le sous-traitant on peut s'en débarrasser un peu plus facilement.
Mouais. Contrairement à un ouvrier peu qualifié qui n'a pas trop le choix, un informaticien compétent peut trouver un boulot sympa s'il s'en donne la peine. S'il se contente des mêmes SSII qui embauchent tous les bras cassés, et ben il ne peut s'en prendre qu'à lui même.
[^] # Re: Julia
Posté par GuieA_7 (site web personnel) . En réponse au journal De l'enseignement de la programmation en classe préparatoire. Évalué à 3.
Je parlais bien d'un « et ». On va dire qu'effectivement on ne peut pas toujours améliorer à la fois tous les critères que j'énumère, mais 2 ou 3 sans dégrader les autres est très souvent possible. Je travaille beaucoup avec des (talentueux) juniors, mais bien souvent ils se contentent de faire du code qui marche (ce qui est déjà bien) ; j'essaie de relire systématiquement leur code, et je les surprends souvent en améliorant tous (ou du moins la plupart) de ces critères. Et leur code est bien meilleur que ce que j'ai pu voir écrit par le mec lambda en SSII, ce qui doit représenter une grosse partie du code écrit dans le monde. Je n'ai évidemment pas la prétention d'en faire de même dans le kernel, mais l'informaticien de gestion de base n'est pas Linus Torvalds malheureusement…
[^] # Re: Julia
Posté par GuieA_7 (site web personnel) . En réponse au journal De l'enseignement de la programmation en classe préparatoire. Évalué à 5.
Autant il est difficile de dire qu'un code est correct, autant il est bien souvent facile de montrer qu'un code ne l'est pas. Si on peut le réécrire en 3 fois moins de lignes, en plus simple, plus robuste, plus lisible et plus performant, c'est que le vieux code n'était pas bien fameux.
[^] # Re: Bien !
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Bubble Crusher 0.9 bêta release. Évalué à 2.
Heu c'est normal d'avoir 50 après 15 (alors que les autres constantes vont en décroissant) ?
PS: en tant que développeur python, j'aurai créé un alias du genre "diff = self.f.score - self.old_score", histoire de gagner en lisibilité et en performance.
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 1.
Ok alors toutes mes excuses ; le C est conservateur, pas le Fortran (les conservateurs ce sont les pappies qui s'accrochent à leur f77 :) )
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
Un bémol cependant : il me semble que des fonctionnalités obligatoires du C99 vont devenir optionnelles dans la version suivante (genre les nombres complexes). Si c'est le cas, un code C99 (utilisant ces fonctionnalités) ne passera pas forcément sur un compilateur C11.
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 2.
Il n'y a pas à toucher un programme qui tourne en 2.5 pour qu'il tourne en 2.7 : la cassure est avec la branche 3, les versions d'une même version ont bien heureusement la compatibilité ascendante.
C'est bien ce que je dis, il y au moins une personne qui passe son temps libre, ou bien qui est payée, pour maintenir f77 dans GCC. Si demain ce n'est plus le cas, et que tu es le dernier utilisateur, tu devras aussi te garder sous le coude la dernière distribution gérant f77, et utiliser une machine virtuelle par exemple.
Je ne sais pas quand le support de Python2.7 sera perdu dans la pratique ; si des tas de gens sont prêts à payer pour qu'il soit maintenu (plutôt que passer les 2h à modifier leur programme) ça peut être dans longtemps (de base le projet Python a tablé sur 5 ans, mais dans les distributions comme Debian ça devrait être là plus longtemps). Mais effectivement, si en 2025 tu es vraiment intéressé pour faire tourner le code de tes thésards de 2010, tu devras peut être te garder une Debian de 2024 + Machine Virtuelle, c'est bien triste pour toi. Quelque chose me dit que si personne n'est motivé pour passer quelques heures sur ces programmes d'ici 15 ans, c'est qu'ils ne doivent pas être si utiles que ça... Je peux comprendre cependant que tu sois déçu.
Pareil que f77 (quelqu'un fait la maintenance).
Tout cela est une histoire d'offre et de demande en quelque sorte. Une communauté peut se former pour faire Python2.8, Python2.9 etc.. qui ne cassent pas la compatibilité. Si ça ne se fait pas, c'est que les "conservateurs" ne sont pas prêts à payer, simplement.
Je ne dis pas que l'approche de Python ("progressiste") est mieux que l'approche Fortran ("conservatrice"); les 2 ont leurs avantages et leurs inconvénients. L'approche des langages n'est que le reflet de leur communauté ; il faut croire que la communauté Python préfère corriger les petites erreurs (je le répète, elles sont petites), plutôt que de pénaliser les futures implémentations. Je préfère l'approche Python, sans nier qu'elle a aussi des inconvénients ; tous les choix techniques sont des compromis, je l'ai déjà dit.
En ce qui me concerne faire évoluer mes programmes n'est pas une contrainte mais une véritable philosophie (et même un grand plaisir).
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 6.
Je ne force personne à changer son code (enfin sauf mes collègues ! :) ). Ceci dit, je pense que dans l'ensemble, en informatique, on souffre beaucoup plus du pattern "ah oui ce truc a été écrit par Jean-Louis y a 15 ans, personne ne sait ce que ça fait exactement alors on y touche pas" que gens qui aiment réécrire leur code en mieux.
Ça ne veut pas dire qu'ils faillent tout refaire depuis zéro tous les 3 mois ; mais dans le cas présent passer 2 jours en 10 ans, ça me paraît acceptable. Tous les choix techniques sont des compromis, et en tant que Pythoniste je suis content que cela soit cette voie qui soit prise (plutôt que l'immobilisme de Java par exemple).
De toutes les façons, il ne faut pas rêver, un système informatique nécessite de la maintenance, l'immortalité n'est pas de ce monde. Si il veut recompiler son programme Fortran77 avec le dernier GCC et bénéficier des dernières optimisations, il faut que des gens aient porté Fortran77 avec la dernière infrastructure de GCC. S'il veut juste tourner sur le dernier Linux sans recompiler son programme, il faut que les développeurs Linux fassent attention à ne pas casser l'ABI. Si il ne veut rien changer du tout au soft, et compte faire tourner la bécane telle quelle pendant 30 ans, il lui faudra quand même prévoir des pièces de rechange, car le hardware ça vieillit.
Mais si un jour plus personne n'est prêt à payer (en temps ou en argent peu importe) pour que Fortran77 soit maintenu dans GCC, et bien le support sera jeté, c'est comme ça. Mais croire que ne rien toucher suffira pour que ça continue à marcher comme avant, alors que le coeur de GCC aurait été réécrit pour bénéficier des dernières avancées en terme de compilation, c'est se mettre le doigt dans l'oeil. On ne peut pas avoir le beurre et l'argent du beurre.
Pour l'instant la communauté Fortran77 est sûrement assez active, peut-être même que des tas de gens sont prêts à payer pour ne pas avoir à changer leur vieux code. Mais au final il y a forcément des gens qui payent cette maintenance. Et comme c'est du libre, on peut en profiter sans avoir soi-même payer quoi que soit ; mais rien de magique la dedans.
[^] # Re: Hum ...
Posté par GuieA_7 (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 2.
En fait nous sommes d'accord je pense, je voulais juste tempérer tes propos. Parce que la phrase "le compilateur n'a qu'a optimiser", je l'ai souvent entendu prononcée par des mauvais codeurs, qui pondent 100 lignes de code toutes pourries, là où 10 lignes simples suffisaient (mais fallait utiliser sa tête).
D'ailleurs, quand on réécrit du code en 4 fois de lignes, en ayant la volonté première d'avoir un code plus simple, lisible et maintenable, mais qu'en bonus le code devient plus rapide, est-ce de l'optimisation ?
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.
Ce n'est pas un sous entendu : le destin de la branche 2 est de mourir, remplacée par la branche 3 (encore une fois les différences sont minimes et valent le coup à mon avis). Donc effectivement, si ta façon de bosser est d'écrire du code, et de ne plus y toucher pendant 30 ans, alors non le Python n'est pas pour toi. Mon post n'avait pas pour but de faire la promotion de Python, il a déjà une active communauté (que d'autre bons langages n'ont pas).
Il faut bien voir qu'une nouvelle version de Python sort en moyenne tous les 2 ans, avec à chaque fois des fonctionnalités bien vues, qui vont permettre d'améliorer lentement mais sûrement les applications. Passer de Fortran77 a Fortran90, ça serait comme passer de Python1.0 à Python3.0, ce que personne ne fait, ne serait-ce que parce que personne n'utilise plus la branche 1, et les premières versions de la branche 2 ne doivent plus l'être non plus. Si il y avait eu Fortran79, Fortran81, etc... avec à chaque fois tous les compilateurs mis à jour en même temps, des fonctionnalités alléchantes mais qui permettent une évolution progressive, peut-être que ton code Fortran77 aurait été amené en douceur vers Fortran90, pour un code plus simple et maintenable (peut être même plus efficace, je ne connais pas Fortran).
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 9.
Je pratique (ou ai pratiqué) le C++ et le Python à titre personnel comme à titre professionnel, et ce sont 2 langages que j'affectionne beaucoup.
Je vais répondre à la pique sur Python. Tu penses que la cassure Python2/Python3 est une erreur, et tu as raison dans la mesure où, si cette politique était appliquée au C++, cela provoquerait une catastrophe. Mais les situations de Python et de C++ sont très différentes, et donc ce qui est bon pour l'un ne l'est pas forcément pour l'autre. Je m'explique.
Le Python a une implémentation de référence (CPython), qui est utilisée par 99% des gens. On peut trouver ça dommage. Mais bon cette implémentation est libre, gratuite, multiplateforme, plutôt performante, ce qui fait que globalement on n'a pas trop à se plaindre.
Je vis en faisant du Python (c'est donc un peu plus qu'un simple amusement sans conséquence), et le passage à Python3 ne m'effraie du tout, j'ai même hâte de le faire.
Les langage C++ et Python évoluent de manière différente, mais à mon avis les 2 le font assez bien (même si je suis assez déçu de la dernière version de C++).
[^] # Re: Hum ...
Posté par GuieA_7 (site web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 4.
C'est un peu plus compliqué que ça malheureusement. Même dans les langages fonctionnels, il est par exemple conseillé de faire des récursions terminales, histoire d'utiliser efficacement la pile. Or la version avec récursion terminale est souvent un peu moins jolie que la version naïve.
Peut être que des compilateurs sont capable de faire cette transformation tout seuls cela dit (je ne suis pas un spécialiste), mais je pense que le programmeur aura toujours une part de responsabilité dans l'optimisation.
# Microsoft doit se mordre les doigts
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Des déconvenues pour Microsoft. Évalué à 10.
Malgré les qualités intrinsèque de FireFox (et plus récemment de Chrome), il est clair qu'il a percé aussi parce que IE6, pourtant installé de base sur 90% des machines de bureau, est une vraie bouse. Je pense qu'en limitant la casse (en laissant une poignée ingénieurs sur le projet) afin de le rendre juste assez médiocre pour que la fuite des utilisateurs soit faible, IE serait encore en quasi monopole. Et du coup Bing serait sûrement bien moins à la traîne.
En somme pour économiser quelques dollars, ils ont craché à la figure de millions d'utilisateurs, et maintenant des milliards leur passent sous le nez. Ahah, bien fait !
[^] # Re: Les benchs c'est stupide...
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Gambas 3 est sorti le 31 décembre 2011. Évalué à 1.
C'était une boutade hein, je me doute que l'équipe de Gambas est petite et a mieux à faire. Ceci dit le typage statique de Gambas faciliterait peut-être la compilation, comparé à des langages comme JavaScript ou Python (mais ça reste un gros travail).
Ah ben ça c'est tout à fait normal. Du moment que tu dis aux gens d'utiliser ton logiciel, ils vont forcément se demander pourquoi le tien et pas un autre. C'est d'autant plus vrai pour un langage de programmation : il est assez facile de changer de navigateur Web ou de lecteur multimédia, mais quand on se lie à un langage cela a plus de conséquences. Ce n'est pas pour rien qu'il y a des tas de langages (libres) de qualité avec une faible communauté.
Il faudrait peut-être rentrer plus dans les détails sur ces qualités (être "vendeur", ce n'est pas péjoratif).
Pour avoir fait du python embarqué temps réel, je dirais que la façon de coder importe plus que le langage. Par exemple un langage rapide ne dispense pas de jouer avec l’asynchronisme pour rendre une application vraiment réactive.
# Les benchs c'est stupide...
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Gambas 3 est sorti le 31 décembre 2011. Évalué à 4.
... mais on aime ça! :)
Je me suis amusé avec le premier benchmark, dont voici le code original :
J'ai fait de très mineures modifications histoire que ça soit plus pythonique :
Je passe sur ma machine de 231.824s à 209.599s, soit presque 10% de gain. Gambas reste donc bien plus rapide, ce qui montre bien que le typage statique permet des optimisations intéressantes, même avec un simple interpréteur.
Puis j'ai rajouté ceci après le shebang:
Et (après avoir installé Psyco !) le code s'exécute en 84.306s, soit presque 3 fois plus rapidement. Évidemment Psyco c'est que x86 et plus trop maintenu, mais ça donne une idée de ce qu'on va avoir avec PyPy qui est annoncé comme 5 fois plus rapide que CPython.
L'équipe de Gambas relèvera-t-elle le défi en implémentant du JIT (le suspens est à son comble) ?? :)
J'en profite au passage pour féliciter ladite équipe pour son travail.
[^] # Re: Libre et business
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Logiciel libre et création d'entreprise : entretien avec 2 des créateurs de Hybird . Évalué à 2.
Comme le dit Zenitram au dessus, tu oppose libre et commercial, mais ce sont 2 concept orthogonaux. La double licence TrollTech, c'était libre vs propriétaire. Du moment que tu fais du libre, tu n'empêche pas les concurrents de faire du commercial ; tu peux juste les empêcher de faire du propriétaire (licences *GPL), mais même pas les obliger à contribuer avec toi.
Encore une fois la protection du code, pour nous qui vendons du service, n'est pas une problématique. Les mauvais payeurs sont un problème par exemple, pas les "voleurs" de code.
Mais admettons que tu n'aies pas fait la confusion propriétaire/commercial ; il est clair que TrollTech était confronté à un problème de business model dans le libre : ils pouvaient difficilement vendre du service autour de Qt. Ils en vendaient (support etc...), mais leurs utilisateurs sont des techniciens et n'en pas souvent besoin. Et c'est encore plus un problème dans le cas de produit pour le grand public ; il est clair qu'on ne peut transposer le modèle propriétaire classique dans le monde du libre, et c'est bien embêtant. Les réponses changent donc en fonction du type de logiciel ; mais encore une fois, pour beaucoup la "non-protection" n'est pas gênante.
[^] # Re: Libre et business
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Logiciel libre et création d'entreprise : entretien avec 2 des créateurs de Hybird . Évalué à 7.
Oui la question est intéressante. Une première réponse et après au dodo.
Faire du libre est déjà pour nous une démarche militante. Ce n'est pas une volonté issue d'une étude de marché pointue qui nous aurait démontré que dans notre cas c'est plus rémunérateur ; évidemment il n'est pas question non plus de partir au casse-pipe. Mais avant nous faisions de l'intégration VTiger (un autre CRM libre), et on a bien vu que sur ce marché très concurrentiel, en travaillant sérieusement nous arrivions à gagner notre vie.
La concurrence est déjà rude, et les CRM libres s'en sortent plutôt bien ; ça ne ferait qu'un concurrent de plus au final.
Pour le moment en tout cas, le fait que notre boite soit jeune et petite est le plus gros problème pour lutter face aux gros ; le fait de faire du proprio n'y changerait pas forcément grand chose (c'est discutable toutefois, car on aurait du coup peut-être accepté des financements qu'on refuse justement pour pouvoir garder le contrôle et rester libres). Du coup que des gens utilisent notre soft serait plutôt synonyme de publicité.
On a écrit la moindre des lignes de Creme, alors quand il faut le customiser nous sommes efficaces forcément. Si nous n'arrivons pas à nous démarquer face à un concurrent faisant du Creme "sauvage" c'est que nous devons nous améliorer (mais oui c'est plus rude que de vivre de rentes comme avec le proprio).
Au final je dirais que ce problème d'auto concurrence est un peu une chimère, mais c'est vrai c'est LA question que nous posent les gens habitués au monde propriétaire. À part nous empêcher un jour d'ériger un monopole (ce qui est une bonne chose, ils ne sont pas souhaitables), ça n'est pas un gros problème.