Subject: De l'utilité des développements Libres
Les développeurs bénévoles de logiciels libres sont bénévoles, par définition. Et il est donc difficile d'exiger d'eux une qualité minimale, un comportement irréprochable, etc : ils font ce qu'ils veulent, et on y peut pas grand chose. C'est leur choix.
Pourtant, quand je travaille sur du Libre, j'essaie toujours d'en faire profiter le maximum de personnes. Je n'aime pas corriger un problème pour un groupe de personnes, sans faire la démarche nécessaire pour qu'il soit corrigé pour le reste du monde. Et les comportements égoistes et égocentriques de certains développeurs de logiciels libres ont tendance à très fortement m'agacer... par exemple :
* Les développeurs de distributions GNU/Linux qui ne font pas remonter les problèmes détectés et corrigés au développeur initial (certains paquets Debian sont ainsi des forks de la version upstream)
* Les auteurs de documentations qui préfèrent réinventer la roue plutôt que contribuer aux documentations existantes qui ont une vocation d'universalité, de préférence en publiant sur leur blog pour s'attirer tous les éloges
* Les développeurs de certaines distributions dérivées de Debian qui rechignent à faire remonter les patchs
* ...
Finalement, là où l'objectif des développeurs de logiciels libres devrait être de rendre le monde meilleur (!), j'ai l'impression qu'on dérive souvent vers une amélioration de son confort personnel/de ses proches...
Qu'en pensez-vous ? En faisant un peu d'auto-critique, comment jugez-vous vos propres travaux par rapport à ca ?
Journal De l'utilité des développements Libres
9
fév.
2006
# Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Qu'en pensez-vous ?
Posté par Misc (site web personnel) . Évalué à 10.
Entre un document et la pratique, il y a une différence.
On pourrait citer de la même maniére canonical face à debian, et voir que curieusement, même si canonical fait son possible, tout ne remonte pas :
http://kitenet.net/~joey/blog/entry/a_bad_taste_in_the_mouth(...)
Je jette pas la pierre aux autres devs, remonter un patch, ç'est pas aussi simple qu'on le croit.
Déja, faut que le patch soit utile à remonter. Les patchs de personnalisations ( genre mettre debian dans la banniére ssh ), ça rentre pas dans cette catégorie. Les patchs d'applications d'une policy refusé upstream ( je pense par exemple à perl ), pareil.
Ensuite, faut que le patch soit propre dans sa forme ( un fichier correct et pas un amoncellement de patch dans tout les sens comme le paquet cron ), que la patch soit claire lisible et pas trop porc( genre un gros coup de code commenté ).
Et la, faut ensuite que le dev réponde à son email ( et faut le trouver encore ), ou que le projet posséde un gestionnaire de bug, qui lui même nécessite souvent un login ( un jour, on aura surement un systéme d'authentification distribué, mais c'est pas encore le cas ), et la, tu peut commencer à envisager l'envoyer.
J'ai passer une bonne semaine à corriger des problémes gcc4 sur divers softs c++ libre, au cours d'un stage ( quasiment sur mon temps libre ).
Et pour la remonté des patchs, entre les "ah mais c'est pas sur la version cvs on prends pas", les "envoyez le patch sur la liste de diffusion", et le silence radio,il ne reste plus grand chose. Et encore, je passe sur le fait qu'il mets parfois~ 1 an à être appliqué, ton patch.
Surtout que la moitié des patchs était assez simple, et je pense que j'ai perdu plus de temps à remonter le patch, et l'auteur à le relire et à l'appliquer que de nous laisser bosser tout les deux dans un coin à corriger les erreurs g++.
J'essaye de remonter les patchs, mais je vais pas commencer à harceler les auteurs pour intégrer mon patch, ou pour prendre un bugzilla.
Et c'est vrai, il y a aussi des docs dupliqués de partout, certaines de basses qualités. Sans doute parce que c'est simplement plus facile à faire, il y a pas d'histoire de gloriole ou quoi que ce soit. Pour faire un howto pour le tldp, il faut apprendre docbook, pour faire ce que tu veut sur ton blog/site web, tu fait ce que tu veut comme tu le veut.
Cherche pas plus loin, il y a pas que les electrons qui suivent le chemin de moindre résistance.
[^] # Re: Qu'en pensez-vous ?
Posté par Lucas . Évalué à 1.
Pas du tout.
> La politique debian vis à vis de l'upstream me semble très claire :
Effectivement, c'est la "policy" de Debian. Mais comme le dit Misc, il faut faire la différence entre "policy" et pratique.
Concernant Debian, c'est un exemple que je connais bien, et c'est vrai que le nombre de paquets avec des modifications utiles non remontées esttrès faible (mais pas nul non plus).
Enfin le but de mon journal n'était pas de râler contre Debian de toute facon, ca n'était qu'un exemple parmi d'autres.
# upstream versus packageur
Posté par Colin Leroy (site web personnel) . Évalué à 8.
* mauvais packageur, râler sur ses packageurs. Notre packageur Debian fait du très bon boulot sur Sylpheed-Claws par exemple. Le seul patch qu'il ajoute, c'est parce qu'on l'a refusé.
* au maximum, ces gens perdent leur temps. Pas le tien...
* Hop un ptit troll Ubuntu pour la route !
j'ai l'impression qu'on dérive souvent vers une amélioration de son confort personnel/de ses proches...
Il est vrai que les rapports de bugs en provenance de ma copine se retrouvent souvent avec une priorité supérieure aux autres. J'ai honte de moi !
[^] # Re: upstream versus packageur
Posté par Lucas . Évalué à 1.
* mauvais packageur, râler sur ses packageurs. Notre packageur Debian fait du très bon boulot sur Sylpheed-Claws par exemple. Le seul patch qu'il ajoute, c'est parce qu'on l'a refusé.
Comme je l'ai dit plus haut, ce cas là ne concerne qu'un très faible pourcentage de packageurs Debian.
* Hop un ptit troll Ubuntu pour la route !
Boh, non, surtout que je fais partie de l'équipe d'Ubuntu à laquelle on reproche de ne pas toujours faire remonter les bugs/patchs.
> j'ai l'impression qu'on dérive souvent vers une amélioration de son confort personnel/de ses proches...
Il est vrai que les rapports de bugs en provenance de ma copine se retrouvent souvent avec une priorité supérieure aux autres. J'ai honte de moi !
C'est pas vraiment ce à quoi je pensais ;)
# licence
Posté par Sébastien TeRMiToR . Évalué à 4.
Comme cdrecord et d'autre ...
[^] # Re: licence
Posté par Lucas . Évalué à 0.
# Pas d'accord
Posté par hiphopmomo . Évalué à -5.
Nan nan, benevole n'implique pas "yalaaa!! c'est le fete de la saucisse de chateauroux, allez vous faire empapaouter quand ma nana a ses ragnagna et je fais les choses qu'a moitie".
Quand on s'engage a faire un travail, on l'assume jusqu'au bout, pas de "ouais, mais t'as vu, chui benevole", et ce qu'on soit paye ou pas.
[^] # Re: Pas d'accord
Posté par Vador Dark (site web personnel) . Évalué à 4.
Je propose qu'on évite sur LinuxFr ce genre d'image déplacé qui fait un peu ado en pleine crise de puberté.
[^] # Re: Pas d'accord
Posté par hiphopmomo . Évalué à -1.
Apres, si vous eussiez preferé que j'utilisasse un langage plat et sans conviction...
[^] # Re: Pas d'accord
Posté par Vador Dark (site web personnel) . Évalué à 1.
[^] # Re: Pas d'accord
Posté par hiphopmomo . Évalué à 2.
si empapaouter et ragnagna ca heurte ta sensibilite, tu vas avoir comme qui dirait des soucis dans la vraie vie..
Remarque, meme sur internet.
[^] # Re: Pas d'accord
Posté par Vador Dark (site web personnel) . Évalué à 2.
J'ai dis que ça pouvait heurter certaines sensibilités.
Ensuite, ces deux mots hors contextes ne veulent plus rien dire, donc forcément que ça heurtera personne.
Et enfin, c'est pas parce que dans la vrai vie et sur internet il y a ce genre d'images qu'on doit les accepter et soi-même les rependre. D'autant que sur internet autant que dans la réalité j'en vois assez peu: on ne doit pas consulter le même genre de sites et de gens.
M'enfin, on va pas s'éterniser là dessus. Aller, sans rancune? :)
[^] # Re: Pas d'accord
Posté par hiphopmomo . Évalué à 2.
pour les ragnagna si t'es jamais confronte au probleme, trouve toi une copine (ou change de bord. oups, ca va heurter la sensibilite ca ;-) )
# Chacun fait ce qu'il peut
Posté par Croconux . Évalué à 7.
Les mainteneurs de paquets sont parfois obligés de faire pas mal de modifs pour arriver packager des logiciels. Il ne s'agit pas à proprement parler de bugs mais d'adaptation à la ditrib. Les développeurs se soucient assez peu de packaging de leur softs prennent leur config comme référence. Sauf que quand on n'utilise pas exactement la même install, ça ne marche pas. J'ai récemment lutté pour empaqueter un programme qui crashait immédiatement au démarrage par un beau "segmentation fault". Après investigation, il s'est avéré que le programme cherchait d'office certains fichiers dans "/usr/local" quoi quoi qu'on ai passé en --prefix. Le chemin n'était même pas défini à un endroit : On supposait partout qu'il s'agissait de "/usr/local" et on faisait des concaténations de chaines dans tous les sens. Le dev s'en fout :"chez moi ça marche" (?). On notera aussi la robustesse de la gestion d'erreur: Je fait mon fopen et je me contre branle de la valeur de retour. Là on n'est plus dans le nettoyage de code que dans la correction de bug. Le pire c'est que quand on ose faire des suggestions (code à l'appui) les gars prennent souvent très mal le fait qu'on ai des commentaires à faire sur leur code.
Dans le cas de Debian, il y a aussi la problématique de libre ou pas. Beaucoup de gens utilisent du code récupéré d'on ne sais où sans trop se soucier de la licence (quand il y en a une), mixent du code libre et non libre, des licences incompatibles... Quand on ose poser des questions la licence de tel ou tel fichier, on se voit traitre de barbu intégriste.
Les auteurs de documentations qui préfèrent réinventer la roue plutôt que contribuer aux documentations existantes qui ont une vocation d'universalité, de préférence en publiant sur leur blog pour s'attirer tous les éloges
<reve>J'aimerais bien qu'il exite un vrai projet de doc universel</reve> Malheureusement c'est loin d'être le cas. Il y a bien TLDP mais il me semble qu'il regroupe plus une collection de doc "officielles". La forme encourage peu à participer. Un Wiki aurait sans doute plus de succès. Là où la doc me manque le plus, c'est sur le support matériel. Il y a plusieurs base de connaissances dans un état plus ou moins zombie mais aucune source centralisée de ce qui est supporté ou pas. Au final, il faut écumer les pages maison de différentes distributions, fouiller dans les docs du noyau et divers blogs pour se faire une idée. C'est moche.
Les développeurs de certaines distributions dérivées de Debian qui rechignent à faire remonter les patchs
Les distributions dérivées ont souvent divergé d'avec Debian. Ils peuvent sortir des patch de leur modifs mais ils ne seront à mon avis pas utilisable directement. C'est un peu comme pour KHtml/WebCore. Les patchs ça marche bien pour des modifs unitaires et à condition qu'on garde pour objectif de coller au plus près de la source.
Finalement, là où l'objectif des développeurs de logiciels libres devrait être de rendre le monde meilleur (!), j'ai l'impression qu'on dérive souvent vers une amélioration de son confort personnel/de ses proches...
Je ne suis pas convaicu que l'ojectif des développeurs soit d'améliorer la vie de la terre entière. Beaucoup développent les outils sont ils ont besoin ou des outils pour leur proches. C'est un peu mon cas. Lorsque le temps que j'estime que je passe trop de temps à faire quelque chose à la main (ou que je vois mon père sortir Excel à tout bout de champ), je me me fais une moulinette pour le faire à ma place mais je ne vais pas passer mes nuits à coder des trucs qui ne me serviront pas.
[^] # Re: Chacun fait ce qu'il peut
Posté par theocrite (site web personnel) . Évalué à 2.
De la doc, c'est clair qu'il en a beaucoup. Entre les site à la lea, les docs commes celles d'Alexis de Lattres, les docs propres à un logiciels ou à une distribution, les livres O'reilly en ligne sous GPL ou GFDL, les infos sur les mailing lists, les docs sur différents sites un peut partout sur le net, les docs pour flatter l'égo de leur(s) rédacteur(s), comme décrillé par l'auteur du journal etc...
Cependant, ça reste éparpillé, pas toujours à jours : les docs sont parfois abandonnées, quand elles ne le sont pas, elles n'ont pas toujours les dernières infos parues sur les ml, les chans irc etc et plus le projet/la doc est grand(e), plus c'est difficile à faire bouger/à contacter quelqu'un.
C'est clair qu'un wiki se serait presque l'idéal.
Je ne connais pas du tout TLDP, je vais regarder ce que c'est plus en détail. Cependant, je m'était fait une réflexion il y a quelques temps.
Wikipedia a de plus en plus de popularité. La croissance du nombre de contributeurs, d'articles, d'inscriptions... toutes sont exponentielles. Les premiers wikibooks complets pointent leur nez. Ils sont encore rares surtout dans les wikipedia non anglophones, mais c'est un bon début. Avec une hausse de sa popularité et une bonne image, wiki[pm]edia a les moyens d'attirer de nouveaux contributeurs en nombre et surtout de canaliser le flux de contributions dans un endroit unique.
Peut être que je me plante complètement et que je rève en 3D et en couleurs, mais j'espère secrètement que wikibooks va répondre à cette attente :)
http://fr.wikibooks.org/wiki/Wikilivres:Liste_de_tous_les_li(...)
http://en.wikibooks.org/wiki/Wikibooks:Computer_science_book(...)
http://en.wikibooks.org/wiki/Wikibooks:Computer_software_boo(...)
# C'est plus compliqué que cela
Posté par hervé Couvelard . Évalué à 5.
je suis sur debian sarge sachant que ce n'est pas la version en cours de dévellopement, quoi faire remonter ?
Lorsque on regarde des softs, pour les 'bugs' on a toujours la réponse sur les mailling list : is your version the cvs one ?
Donc pour remonter des modifications, il faudrait travailler sur la dernière version en cours, ce qui est, pour l'utilisateur normal rarement le cas.
Pour un cas plus générique, il y a une multitude de personnes qui répondent sur le net, dans des forums, sur des wikis, dans des install parties, et c'est cela aussi le libre.
Je ne contribue pas au libre car je ne suis pas un dieu du C ni du C++, je suis un graphiste euh.... pitoyable, je n'aime pas faire de la doc écrite (j'aime la formation en personne) MAIS j'installe autour de moi linux. Alors on peut penser que c'est le petit confort personnel de moi et de mes amis, mais c'est peut-être aussi important que celui qui ne fait rien autour de lui et qui envoie 50 patchs par mois pour 1 soft qu'il utilise et dont le bug impacte peut être que 3 personnes dans le monde.
Mon intervention sur les 20-30 personnes que je connais peut pousser 200-300 personnes et dans ces 200 personnes, il y a peut être 20 personnes de plus capable que moi.
Parfois les chemins sont détournés, et il ne faut regarder de trop pres l'évènement de peur de rater la conséquence à LONG terme d'un acte.
Peu importe qu'il y ait 50 000 pages du man rsync sur le net, l'essentiel est qu'il y soit. non ?
# ouahou
Posté par TImaniac (site web personnel) . Évalué à 10.
Et lorsqu'il y a un mix bénévoles/employés, ben les employés sont souvent les mainteneurs principaux qui peuvent "contrôler" la qualité.
Sinon d'une manière générale, les bénévoles cherchent avant tout :
- à se faire plaisir : donc bien souvent on réinvente la roue, pour le plaisir de réinventer la roue, avec bien souvent l'ambition de faire une plus belle roue.
- à ne pas se prendre la tête : plonger dans un truc existant (code ou doc), c'est relou.
- à faire plaisir à son égo : regarder les gens ce que j'ai fais, dites "ouaaaah"
Bref, rien de bien original, c'est dans la nature de l'homme. Si l'homme cherchait à rendre le monde meilleur ca se saurait, depuis le début de l'humanité, l'homme cherche à améliorer son confort et son plaisir :)
Tu viens de comprendre que les logiciels libres n'échappent pas à ce constat, ce qui aurait été bien surprennant.
PS : et tu sais, même ceux qui préconise un monde "meilleur" ou qui en rêve font avant tout ca pour eux même : parcqu'ils ont envie de vivre dans ce monde meilleur, bref, parcqu'ils sentent que pour eux même c'est mieux, des égoïstes quoi.
# Des outils ...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
D'où l'importance de la gestion des version décentralisée. Le noyau Linux sans doutes été le premier projet à en faire une utilisation aussi intensive, probablement parce que c'est un des packages les plus patchés par les distributions.
Il y a aussi malone qui est un gestionnaire de bugs capable d'aller chercher les bugs dans les bugtrackers des autres distribs. Par contre, dommage qu'il ne soit pas distribué. Tout dépend de la confiance qu'on a envers Canonical.
Mais comme tout outil, l'important, c'est comment on les utilise.
# reinventer la route...?
Posté par kowalsky . Évalué à 2.
pour une reinvention de la roue, c'est une tentative
d'optimisation...
J'ecris un logiciel qui se base sur le snmp. Des outils
existent deja, mais je me suis dis, je n'ai pas besoins
de toute les fonctionnalité snmp, (get, walk, bulkk, set),
et de plus se serait un super moyen pour bien connaitre
le protocol SNMP.
donc j'ai fais mon propre snmpget, snmpset.
Mais bon, finalement,net-snmp est mieux et plus stable,
c'est pas dur, j'avais fais un truc de porc...!!! :p
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.