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

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

  Posté par Alexis Muller (page perso, ) le 28/12/2003 à 18:12. (lien). É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 Black Fox (page perso, ) le 28/12/2003 à 18:36. (lien). É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 fragbait () le 28/12/2003 à 23:22. (lien). É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 jcs (page perso, ) le 28/12/2003 à 18:54. (lien). É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.

  --
  Hurd will be out in a year (or two, or next month, who knows)
  -- Linus Benedict Torvalds, 1991

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

    Posté par Wawet76 (page perso, ) le 28/12/2003 à 20:56. (lien). É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 Philippe Fremy (page perso, ) le 29/12/2003 à 09:02. (lien). É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.

    --
    phil.freehackers.org

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

  Posté par Thierry Boudet (page perso, ) le 28/12/2003 à 20:55. (lien). É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.

  --
  ( blog )

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

  Posté par Philippe Fremy (page perso, ) le 29/12/2003 à 09:17. (lien). É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, ...

  --
  phil.freehackers.org

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

  Posté par Karles Nine (page perso, ) le 30/12/2003 à 11:50. (lien). É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 Black Fox (page perso, ) le 30/12/2003 à 13:11. (lien). É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 Aurélien Le Provost - Ribaltch (Jabber id, page perso, ) le 30/12/2003 à 14:48. (lien). É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.

      --
      Encryption is not magic pixie dust to sprinkle on things to make them more secure.

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

    Posté par Goon () le 30/12/2003 à 14:46. (lien). É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 Yusei () le 30/12/2003 à 19:01. (lien). É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

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

  Posté par Yusei () le 28/12/2003 à 18:31. (lien). É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 Claude SIMON (page perso, ) le 29/12/2003 à 10:55. (lien). É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.

    --
    Projet Epeios (http://zeusw.org/epeios/) :
    Bibliothèques C++ généralistes et dédiées.

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

      Posté par Yusei () le 29/12/2003 à 11:04. (lien). É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 Erwan (page perso, ) le 29/12/2003 à 13:07. (lien). É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 Aurélien Girard () le 28/12/2003 à 18:35. (lien). É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 10 ans.

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

    Posté par imr () le 28/12/2003 à 18:58. (lien). É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 Aurélien Girard () le 28/12/2003 à 23:26. (lien). É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 10 ans.