Les “mythes” du développement Open Source

Posté par  . Modéré par Nÿco.
Étiquettes : aucune
0
28
déc.
2003
Communauté
Cet article liste un certain nombre de "mythes" sur le développement Open Source.

Malgré quelques imprécisions, les arguments avancés sont souvent justes, et expliquent les travers potentiels du modèle de développement Open Source.

NdM : très bon complément à « La cathédrale et le bazar »

Aller plus loin

  • # Re: Les “mythes” du développement Open Source

    Posté par  . Évalué à 10.

    J'immagine que la NdM porte sur le second lien "La cathédrale et le bazar" mais je trouve la formulation peu claire. Pour ceux qui ne lisent pas l'anglais petit résumé des Légendes/Réalités de l'article :
    • Le fait que le code soit disponnible fait que les gens participent : Possible mais à part si le projet deviens un projet connu il ne faut pas trop y compter dessus.
    • Le fait d'avoir des periodes consacrés seulements à la correction de bugs est le meilleur moyen d'avoir des logiciels stables : C'est un moyen comme un autre mais le meilleur moyen est qu'il n'y ait pas de bugs dès le départ graçe à un test du code en permannence.
    • Le meilleur moyen pour un contributeur de rentrer dans le projet et de comprendre la structure du code est de commencer par de la correction de bugs : Le personne auras une vue des détails mais pas une vue globale du projet, des documents comme une roadmap peuvent plus aider.
    • Que le code soit disponnible est le plus important, plus que les outils de configuration ou d'installation : Faux un utilisateur qui n'arrive pas à commencer à se servir du logiciel (L'installer ou le configurer à ses besoins) ne reste pas. Il faut une installation claire et si il y as des dépendence des liens directs vers celles ci si possible sans obliger l'utilisateur à chercher entre les différentes versions, beta, alpha d'une dizaine de projets.
    • Les codes sales et mal écrits sont à jetter : Parfois réutiliser ce code en l'encapsulant peut être plus rapide. Surtout que ce code résout surement des bugs au quel vous n'avez pas encore pensés.
    • Il vaut mieux fournir des librairies complettes que des programmes qui règlent des problèmes : Souvent quand on veut aller trop loin on arrive nule part. Commencer par quelquechose qui marche puis généraliser plus tard.
    • J'ai mal codé cela précédement donc cette fois ce seras parfait : Non il faut du travail pour évoluer et si c'était mal codé la dernière fois et qu'il n'y as pas eu de réel effort entre temps ce seras différent mais pas "mieux".
    • Il est toujour pratique d'avoir d'afficher des warnings : Les utilisateurs seront distraits par eux et risquent d'en oublier les messages d'erreurs qui sont eux beaucoup plus importants !!!
    • Les utilisateurs utilisent le CVS si ils ont besoin d'une correction de bug ou d'une nouvelle fonctionalitée : Faux il faut addapter les corrections de bugs aux anciennes branches et publier des "stable" souvent, les utilisateurs n'aiment pas essayer du code possiblement instable.
    A mon avis ça enfonce des portes ouvertes mais c'est un bon résumé...
    • [^] # Re: Les “mythes” du développement Open Source

      Posté par  (site web personnel) . Évalué à 10.

      Je ne suis pas tout à fait d'accord avec la traduction, par exemple :

      Il est toujour pratique d'avoir d'afficher des warnings : Les utilisateurs seront distraits par eux et risquent d'en oublier les messages d'erreurs qui sont eux beaucoup plus importants !!!

      J'aurrai plutôt traduit par :

      Les warrings sont juste des avertissements et persones n'y prête attention : les avertissements peuvent cacher de vrais problèmes

      Enfin je ferais mieux de me taire, toi au moin tu à eu le courage d'un faire un résumé complet ;-)

      Sinon à par le 1er "myth" je ne vois pas ce qui est spécifique aux logiciels open sources...
      • [^] # Re: Les “mythes” du développement Open Source

        Posté par  . Évalué à 4.

        C'est une traduction rapide et je savais bien qu'elle serait imparfaite. Les patchs sont bienvenus mais ne sont pas applicables car on ne peut pas éditer les posts :p
      • [^] # warning

        Posté par  . Évalué à 2.

        l'auteur anglophone fais selon moi réfèrence aux avertissement du compilateur (quel qu'il soit) qu'on peut négliger car ils n'empèchent pas la production d'un exécutable, mais qu'il est en général malvenu de laisser trainer, pour 2 raisons :
        1 - ils peuvent masquer un réel problème, pas grave à la rigueur, on finit par s'en rendre compte/on en a conscience
        2 - ils peuvent évoluer assez mal dans le temps/ vers d'autres systemes

        Ce n'est pas spécifique du développement open source, par contre le mythe l'est peut etre.
    • [^] # Re: Les “mythes” du développement Open Source

      Posté par  (site web personnel) . Évalué à 5.

      Les codes sales et mal écrits sont à jetter : Parfois réutiliser ce code en l'encapsulant peut être plus rapide. Surtout que ce code résout surement des bugs au quel vous n'avez pas encore pensés.
      Ce n'est qu'un avis perso, mais je ne suis pas du tout d'accord. Utiliser du code sale et mal écrit (et ça englobe aussi le code non commenté) est à mon avis la meilleure façon d'introduire des bugs difficile à corriger. La seule manière d'introduire ce type de code est, je pense, dans des modules indépendants du reste, pour résoudre un problème particulier et en attendant de réécrire une version propre.
      • [^] # Re: Les “mythes” du développement Open Source

        Posté par  (site web personnel) . Évalué à 2.

        Pas bête de le mettre dans des modules indépendant du reste... En l'encapsulant quoi... :)
      • [^] # Re: Les “mythes” du développement Open Source

        Posté par  (site web personnel) . Évalué à 4.

        L'auteur fait ici reference aux a priori qu'on a sur le code des autres. Tres souvent beaucoup de projets rejettent de code existant parce qu'il est "sale ou mal ecrit".

        L'auteur ici inicite a regarder de plus pres l'option qui consiste a reutiliser du code et a ne pas s'arreter a quelques problemes initiaux.

        Il a raison dans la mesure ou on a tendance a tres vite rejeter le code des autres quand on demarre un projet.

        Cependant, la raison n'est pas qu'il est "sale ou mal ecrit" (bien que ca arrive) mais plutot que:
        - developper son propre code, c'est plus fun
        - comprendre le codes des autres, c'est difficile
        - souvent, des problemes d'architectures rendent la reutilisation impossible
        - coopererer n'est pas facile
        - deux projets peuvent avoir un but different ou des imperatifs incompatibles.
    • [^] # Re: Les “mythes” du développement Open Source

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      C'est étrange, certains paragraphes me font tout à fait penser à un excellent ouvrage de Steve Maguire: L'art du Code. C'est édité chez Microsoft Press, mais c'est vraiment bien à lire. Steve est un type qui sait se servir de son cerveau, je pense...

      http://test.vaboofer.com/index.php/L%27art%20du%20Code(...) pour la quatrième de couverture.
    • [^] # Re: Les “mythes” du développement Open Source

      Posté par  (site web personnel) . Évalué à 5.

      Je pense que l'auteur a oublie quelques mythes auxquels beaucoup de temps croient dur comme fer dans le monde open source:

      mythe: Un projet open source est intrinsequement plus securise qu'un projet proprietaire

      realite: La securite d'un projet depend de beaucoup de parametres et l'open source n'est pas une baguette magique qui va rendre un projet securise. Rappelons que:
      - beaucoup de projets open source sont codes par des debutants qui le font pour apprendre a programmer
      - securiser un projet demande une experience de la securite et une comprehension des attaques qui ne s'aquiert pas en 5 minutes. Il faut un audit d'expert pour valider la securite d'un projet
      - le source a beau etre ouvert, rien ne dit qu'il va etre audite par qui que ce soit
      - les audits de securite sont ausssi possible dans des projet close source (mais c'est la boite qui developpe qui doit s'en charger)
      - meme sans le source, on peut trouver plein de bugs de securite.
      - le source permet aussi aux crackers de monter plus facilement une attaque.

      En resume, ouvrir le source n'est qu'un parametre parmis beaucoup qui influe sur la securite d'un logiciel. Pour certains projets tres populaires, comme apache, le kernel linux ou nmap, on peut considerer que il ya eu des revues de code qui ont ameliore la securite. Pour mon_apppli_que_personne_connait, on peut rien dire.



      mythe: Parce que un projet est open source, les bugs sont corriges tres rapidement

      realite: certains projets open source qui ont une large communaute dediee corrigent des bugs tres rapidement (KDE, le kernel, Gnome, ...). Ceci est egalement le cas de certains projets close source. A l'inverse, des projets open-source cles sont tres lents a corriger des bugs ou a integrer des patchs: le kernel aussi, gcc, ...
    • [^] # Re: Les “mythes” du développement Open Source

      Posté par  (site web personnel) . Évalué à 3.

      Que le code soit disponnible est le plus important, plus que les outils de configuration ou d'installation : Faux un utilisateur qui n'arrive pas à commencer à se servir du logiciel (L'installer ou le configurer à ses besoins) ne reste pas. Il faut une installation claire et si il y as des dépendence des liens directs vers celles ci si possible sans obliger l'utilisateur à chercher entre les différentes versions, beta, alpha d'une dizaine de projets.

      C'est a mes yeux le mythe le plus dangereux dans cette liste.

      Je m'explique, tous les autres mythe découle d'une logique d'organisation du travail que tout le monde ici je pense a étudier ou appris sur le tas. Une grande partie des techniques d'organisation est délivrée dans les écoles ou les formations continues et disponible dans toute bonne librairie.

      Concernant la focalisation sur le fond (le code) au détriment de la forme (le package / notice/ installation / etc.) c'est nier l'importance a l'aspect marketing et communication dans un projet, libre ou pas d'ailleur. Laisser ces domaines au adepte du FUD est un grande erreur qui a longtemps pénalisé le monde du logiciel libre.

      Enjoy
      Ps: y'a t'il eu une étude sociologique sur le monde du logiciel libre ?
      • [^] # Re: Les “mythes” du développement Open Source

        Posté par  . Évalué à 1.

        Tout à fait daccord de plus c'est un aspect que les non-programmeurs ne voyent pas souvent quant ils veulent participer : Un des meilleurs moyens de participer à un projet si on ne sait pas programmer est celui là : Créer des installeurs, des outils de configurations, des tutoriaux : rendre la vie plus simple aux utilisateurs.

        Mais il est vrai qu'ils serait mieux que les programmeurs y pensent à la base (Sur ce point je plaide coupable).
        • [^] # Re: Les “mythes” du développement Open Source

          Posté par  . Évalué à 2.

          Faire des outils d'installation et de configuration, ça reste un boulot de programmeur.

          Par contre, les divers projets libres réclament depuis bien longtemps plus de gens pour rédiger de la doc, ou même pour traduire. Et là, indéniablement, pas besoin de savoir programmer.

          Aurélien.
      • [^] # Re: Les “mythes” du développement Open Source

        Posté par  . Évalué à 2.

        Ps: y'a t'il eu une étude sociologique sur le monde du logiciel libre ?

        Je me permets de signaler http://thomasbasset.net/dea.php(...) qui est l'étude de VideoLAN un projet libre par un sociologue.

        Sinon toute une série d'articles (bien que je trouve qu'il n'y ait pas vraiment de textes de terrains, ce qui est un défaut grave) sur http://opensource.mit.edu(...) Des sociologues et des économistes, en anglais.
      • [^] # Re: Les “mythes” du développement Open Source

        Posté par  (Mastodon) . Évalué à 2.

        «y'a t'il eu une étude sociologique sur le monde du logiciel libre ?»

        Pas tout à fait ce que tu demandes, mais une étude sociologique sur les hackers (dans le vrai sens du terme): "L'Éthique hacker ou l'esprit de l'ère de l'information" de Pekka Himanen, avec une préface de... Linus, et une postface de Manuel Castells.

        Bon c'est hors-sujet, mais c'est vachement intéressant.
  • # Re: Les “mythes” du développement Open Source

    Posté par  . Évalué à 5.

    A propos du developpement "Open Source", j'ai l'intention d'écrire un logiciel de Musique Assistée par Ordinateur (partiellement inspiré de Bars & Pipes sur Amiga) qui puisque correspondre à ce que j'attends de ce genre de soft. Le problème c'est que mes connaissances en programmation sont un peu justes (un peu de C, un peu de Gnome).
    Bon, je suis pas vraiment pressé, j'ai tout le reste de ma vie devant moi pour y arriver mais je suis conscient que la tâche sera ardue. Pensez-vous que ce projet ait des chances d'aboutir ou il vaut mieux que je me mette au jardinage ? Par quoi commencer ? Qui a déjà eu une expérience similaire avec des résultats satisfaisants ?
    Je pense que nombre d'entre vous ont été confrontés à ce problème et n'ont jamais osé franchir le premier pas ou se sont arrêtés au deuxième. Alors les réponses de tous, expérimentés ou non, sont les bienvenues.
    • [^] # Re: Les “mythes” du développement Open Source

      Posté par  (Mastodon) . Évalué à 6.

      Mon conseil serait de commencer par de petits programmes sans trop d'envergure, chacun faisant une partie de ce qui t'intéresse dans ton programme final. Comme ça tu auras une première expérience de chaque problème, et une bonne idée de ce dont tu as besoin pour le résoudre.

      Vouloir s'attaquer directement à la conception d'un "gros" logiciel, si tu n'es pas sûr de toi, risque de te mener à un logiciel "bricolé" à partir des erreurs de conception faites au départ, et donc difficile à étendre et maintenir.
      • [^] # Re: Les “mythes” du développement Open Source

        Posté par  (site web personnel) . Évalué à 3.

        En fait de "petits programmes", il vaut mieux écrire des bibliothèques, chacune dédiée à une tâche bien précise, avec un peu de code pour la tester. Cela facilite grandement la maintenance et le débogage. En outre, un développeur peut être intéressé par l'une de ces bibliothèques et donc y contribuer, sans être pour autant interessé par le logiciel dans son ensemble.

        Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

        • [^] # Re: Les “mythes” du développement Open Source

          Posté par  (Mastodon) . Évalué à 4.

          Oui, mais quand on veut faire une bibliothèque, il faut définir une API, et pour faire une API il faut déjà savoir où on va. À la limite je trouve plus difficile de (bien) faire des bibliothèques qu'un gros programme monolithique.

          Pour moi les bibliothèques seraient l'étape suivante: puisqu'on a fait plein de petits programmes pour chaque tâche, on sait plus précisément de quoi on a besoin, et on peut faire autant de bibliothèques.

          (Bien sûr, je ne donnerais pas le même conseil à quelqu'un qui aurait plus d'expérience et qui pourrait modéliser son problème complètement dès le départ)
          • [^] # Re: Les “mythes” du développement Open Source

            Posté par  . Évalué à 1.

            C'est comme il est dit dans l'article: on commence par ecrire son soft, et eventuellement quand il grossit on peut generaliser une partie pour en faire une bibliotheque (et pas une librairie).
    • [^] # Re: Les “mythes” du développement Open Source

      Posté par  . Évalué à 7.

      Commence par faire des recherches pour voir si un ou des projets proches n'existent pas dejà.

      Sinon lance toi et communique sur ton projet. Je n'ai qu'une petite expérience du développement OpenSource mais j'ai rapidement été épaulé par des gens sympathiques et parfois bien plus calés que moi qui ont apporté une contribution remarquable.

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Les mythes du développement Open Source

        Posté par  . Évalué à 5.

        Sinon lance toi et communique sur ton projet. Je n'ai qu'une petite expérience du
        développement OpenSource mais j'ai rapidement été épaulé par des gens sympathiques et
        parfois bien plus calés que moi qui ont apporté une contribution remarquable.

        Mais euh! Fais attention à ce que tu racontes, tu viens de directement contredire le premier point de l'article!
        De quoi on va avoir l'air si ça se sait?
        • [^] # Re: Les mythes du développement Open Source

          Posté par  . Évalué à 2.

          Pas tout à fait.
          Mon projet était un clone de PuyoPuyo donc un petit projet, aux objectifs bien définis et tout à fait ludique.

          Je ne suis pas sur qu'une obscure application verticale rencontre systématiquement le même succès.

          Quoi qu'il arrive il n'y a pas grand chose à perdre à essayer !

          BeOS le faisait il y a 20 ans !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.