Archive for open-source

Je dédie tous mes rm -rf * à…

Hello,

La mésaventure du jour, un rm -rf * malencontreux, alors je pensais être dans un environnement chrooté… et hop quelques jours de travail perdu. C’est bien connu, une erreur seule n’a jamais aucune conséquence, mais deux consécutives (manque de sauvegarde et un rm -rf *), c’est parfois autre chose. Quelques instants, non pas de panique, mais d’inquiétude!

Heureusement, le pape est à Paris, ghantoos n’a pas voulu, par peur de l’affluence et des stations de métro fermées, profiter de son RTT prévu et est donc, au bureau, à mes côtés. Après deux heures d’efforts intensifs, un montage de mon disque sur une autre machine, la bien nommée Diodore, l’historien universel, l’utilisation de magicrescue (sudo apt-get install magicrescue), tout est rentré dans l’ordre, enfin presque, certains fichiers ne sont pas dans leur dernière version, mais les efforts pour les retrouver seront légers.

Un grand merci, donc, à ghantoos, en premier lieu, ensuite à Magicrescue, à Diodore de Sicile, et un peu au pape, et je suis sûr que plus aucun rm -rf * n’aura la même tonalité.

Posted in open-source | Leave a comment

L’open-source, rempart aux effets néfastes de l’orgueil du développeur…

Ambitieux comme titre, non?

L’objectif de cet article est de présenter un argument supplémentaire en faveur de la démarche du logiciel libre dans le cadre d’une exigence de qualité logicielle. Il n’est pas impossible que cet argumentaire ait déjà été tenu, mais je n’en suis pas au courant.

Tout d’abord, quelle est la différence entre développeur labélisé “logiciel libre” et un autre? De mon point de vue, ils peuvent avoir la même méthode de travail pendant toute la phase d’élaboration, de conception, de développement, de test unitaire et de validation. La différence réside essentiellement dans la méthode de publication du résultat de son travail. Le développeur open-source ne va pas seulement publier le résultat de son travail, il va aussi publier son code source et souvent une documentation associée versionnée. Quand je parle de développeur, je pense tout aussi bien à un individu en charge d’un développement qu’à une équipe de développement, pouvant elle-aussi être confrontée à la subjectivité.

Je distingue deux regards possibles sur un logiciel: ou je regarde simplement le résultat final qui correspondra bien en tant qu’utilisateur final à l’attente que j’en ai sans pousser plus son analyse, ou alors, je regarde en plus la technicité, la qualité de la réalisation, de la même certes un peu has-been, qu’on regardait la qualité d’une étoffe dans un vêtement, qu’on regardait les matériaux utilisés pour un meuble, qu’on regardait l’atelier de l’artisan, qu’on observait ses outils, sa patience, sa connaissance et son amour du mêtier.

Le développeur d’un code fermé peut avoir la tentation de ne s’attarder lui-aussi que sur l’effet final produit par son logiciel et non sur sa qualité. Le résultat attirera l’oeil par une belle interface utilisateur, le résultat pourra être clinquant, le manque de qualité d’un produit logiciel n’apparaîtra pas immédiatement au regard de l’utilisateur. Deux exemples: Windows Vista, qui perd de la bande passante quand on diffuse de la musique, pourtant stockée en local. L’utilisateur final standard ne notera probablement pas ce problème, mais on est en droit de se poser ce que ce défaut de qualité peut produire dans d’autres situations? On peut aussi citer l’exemple du Titanic, prestigieux navire sensé assuré aux concepteurs et armateurs une renommée extraordinaire à l’entrée dans un siècle qui s’annonçait être le siècle de l’image et du prestige, mais qui sombra en raison d’un défaut de conception majeur, causé par la négligence technique d’architectes plus tournés vers ce prestige que vers leur travail.

Je vous concède au passage que la citation simultanée de Vista et du Titanic n’est pas complètement innocente.

Il glissera vers ce comportement si son travail est plus porté par l’orgueil, c’est-à-dire par le regard que les autres vont porter sur le résultat que par la fierté d’un travail bien fait.

Qu’est-ce que la fierté d’un travail bien fait? C’est la satisfaction personnelle qui sera issue de la démarche adoptée pour élaborer son travail. Je me permets de citer Sénèque: “La conscience d’un travail bien fait est une récompense en soi”. La satisfaction arrive avant que l’autre n’ait porté un regard sur le produit final, et cette satisfaction pousse naturellement à coder, à documenter pleinement, à produire un travail abouti.

Le développeur d’un logiciel fermé peut avoir cette fierté d’un travail bien fait. Bien entendu. Loin de moi, l’idée d’associer un code fermé à un mauvais code.

Mais le développeur, quel qu’il soit, peut toujours être orgueilleux, et cet orgueil, nous l’avons vu plus haut peut être destructeur pour la qualité d’un produit.

Le développeur d’un code ouvert va non seulement publier son binaire, son logiciel final à destination de l’utilisateur final, il va aussi confronter sa méthode, sa documentation, son code source au regard de l’autre, au regard de ses pairs. Si la fierté, la conscience personnel d’un travail bien fait anime son travail, alors on peut être sûr que son travail sera réutilisable, portable, peut-être pas absent de bug, car la fierté n’évite pas les erreurs, mais il sera, de toute façon maintenable. J’ajoute à cela que le codeur fier de la qualité de son travail accepte la remise en question, puisqu’il a fait son travail consciensement mais qu’il a juste fait une erreur.

S’il est orgueilleux et qu’il expose son travail selon les règles de la communauté open-source, il doit évidemment produire un logiciel qui fonctionne, mais aussi une documentation et un source qui soit lisible et propre. Pour assouvir ce plaisir du regard de l’autre, de par l’élargisssement de son travail de publication, il doit travailler plus profondément et il sera confronté à plus de difficultés, car le regard des pairs est souvent plus strict et sévère que le regard de l’utilisateur final. Atteindre le plaisir du regard de l’autre est alors plus contraignant, le degré d’exigence est nettement plus élevé. Si ce n’est pas le cas et qu’il publie son travail sans atteindre un haut degré d’exigence, ses bugs, ses lacunes ne seront plus des erreurs, mais ce seront des fautes.

Je pense que la démarche d’un travail open-source, si elle n’est pas un gage de qualité absolue, est un sérieux atout pour un développeur, une entreprise qui souhaite produire un logiciel de qualité, car elle est un rempart supplémentaire aux méfaits de l’orgueil, et qui pourra nier n’avoir été animé une fois au moins par l’orgueil?

Peut-être que cette contribution n’a pas de réel intérêt, mais la réflexion sur cette thématique m’a personnellement pleinement intéressé, et pour information, elle est issue d’une discussion que j’ai eue hier avec un ami, à qui durant toute son enfance, on a interdit toute fierté, en confondant probablement de bonne foi, fierté et orgueil.

De même que le développeur open-source est heureux de confronter son travail à l’autre, je suis heureux de partager ce point de vue avec vous!

Posted in open-source | Leave a comment

Swedish Greys - a WordPress theme from Nordic Themepark.