Life Long Learning for Lebanon

Portail informatique formation d'ingénieur Liban

Supports, informations et actualités informatique ISSAE Cnam Liban et centres du Cnam Liban

Société et technologie

Fondateur et activiste Free (libre) Open Source Software Lebanese Movement OSLM

samedi 1 novembre 2014

La cathédrale et le bazar

Extrait de "La cathédrale et le bazar" Auteur : Eric S. Raymond ( esr@thyrsus.com) Traducteur : Sébastien Blondeel
Adptation et commentaire Pascal Fares 

l’open source, décrit pour la première fois dans La Cathédrale et le Bazar, s’attache aux avantages d’une méthode de développement au travers de la réutilisation du code source.

L'open source et le logiel libre ne sont pas tout a fait la même chose voir http://www.cofares.net/2014/11/le-libre.html

L'un, le Libre, est plutôt un modèle incluant un aspect social. L'autre l'open Source s’attache aux avantages d’une méthode de développement au travers de la réutilisation et la collaboration. Mais ces deux modèles se complète un peu comme "Une déclaration de principe" et "Des décret d'application" On parle alors de FLOSS (Free Libre Open Source Softwares)

L'open se baserait sur les Hacker ("Bidouilleur"?) Aux termes to hack, hacker, Eric S. Raymond a consacré un article complet. Il s'agit de l'action de comprendre comment les choses fonctionnent, de vouloir savoir ce qui se cache dans les mécaniques diverses, et de les réparer ou de les améliorer. En aucun cas, ce terme ne doit être confondu avec les pirates de l'informatique, ou crackers. l'auteur à choisi de traduire ce terme par ``bidouille'', et je vous demande de ne pas y attacher d’à priori négatif. Un bidouilleur construit des choses parfois très belles et très compliquées, alors qu'un pirate cherche à détruire.

Voici quelques principe issue ou permettant de définir l'Open Source

  1. Tout bon logiciel commence par gratter un développeur là où ça le démange. 
  2. Les bons programmeurs savent quoi écrire. Les grands programmeurs savent quoi réécrire (et réutiliser).
  3. On ne comprend souvent vraiment bien un problème qu'après avoir implanté une première solution. La deuxième fois, on en sait parfois assez pour le résoudre correctement. Ainsi, si vous voulez faire du bon travail, soyez prêt à recommencer au moins une fois.
  4. Si vous avez la bonne attitude, les problèmes intéressants viendront à vous.
  5. Quand un programme ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent.
  6. Traiter vos utilisateurs en tant que co-développeurs est le chemin le moins semé d'embûches vers une amélioration rapide du code et un débogage efficace.
  7. Distribuez tôt. Mettez à jour souvent. Et soyez à l'écoute de vos clients.
  8. Étant donné un ensemble de bêta-testeurs et de co-développeurs suffisamment grand, chaque problème sera rapidement isolé, et sa solution semblera évidente à quelqu'un.("Quelqu'un trouve le problème,'' , "et c'est quelqu'un d'autre qui le comprend. Je pousserai le bouchon jusqu'à dire que le plus difficile est de trouver le problème.'' Mais le principal est que ces deux événements se produisent en général vite) 
  9. Il vaut mieux avoir des structures de données intelligentes et un code stupide que le contraire.
  10. Si vous traitez vos bêta-testeurs comme ce que vous avez de plus cher au monde, ils réagiront en devenant effectivement ce que vous avez de plus cher au monde.
  11. Si vous traitez vos bêta-testeurs comme ce que vous avez de plus cher au monde, ils réagiront en devenant effectivement ce que vous avez de plus cher au monde.
  12. Bien souvent, les solutions les plus innovantes, les plus frappantes, apparaissent lorsque vous réalisez que votre approche du problème était mauvaise. (Il faut parfois essayer et se tromper pour mieux apprendre)
  13. `La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever.'' (c'est d’ailleurs le conseil que je donne a tous ceux qui rédige un mémoire avec moi) 
  14. Quand vous écrivez un logiciel jouant le rôle d'une passerelle quelconque, prenez soin de perturber le moins possible le flot de données -- et ne perdez *jamais* d'éléments d'information, à moins que la machine destinataire vous y oblige ! 
  15. Un système de sécurité n'est pas plus sûr que le secret (la clé) qui le garde. Gare aux pseudo secrets !
  16. Pour résoudre un problème intéressant, commencez par trouver un problème qui vous intéresse.