Bonjour,
Je n'ai pas toujours le temps de participer au forum (notamment d'aider les nouveaux utilisateurs) ,
mais j'ai lu dans la revue "INFLUX" un petit texte qui pourrait -peut-être - en intéresser certains, je prend le temps de vous le livrer, humblement donc :
LES 19 LECONS DU PHENOMENE LINUX
Dans son essai "La cathédrale et le bazar" publié en 1997, Eric S. Raymond liste les grandes leçons du mode de fonctionnement de la communauté Linux.
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 écrire et réutiliser.
3. "Prévoyez d'en jeter un, car de toute manière, vous le ferez" (Fred Brooks, "The Mythical Man-Month", chapitre 11).
4. Si vous avez la bonne attitude, les problème, les problème intéressants viendront à vous.
5. Quand un programme ne vous intéresse plus, votre dernier devoir est de le confier à un successeur compétent.
6. Traiter vos utilisateurs en tant queco-développeurs est le chemin le moins semé d'embûches vers une amélioration rapide du code et un débugage efficace.
7. Distribuez-tôt. Mettez à jour souvent. Soyez à l'écoute de vos clients.
8. Eténat donné un ensemble de bêté-testeurs et de co-developpeurs suffisamment grand, chaque problème sera rapidement isolé, et sa solution semblera évidente à quelqu'un. Ou, moins formellement, "étant donnés suffisamment d'observateurs, tous les bogues sautent aux yeux". C'est ce que j'appelle : "La Loi de Linus".
9. Il vaut mieux avoir des structures de données intelligentes et un code stupide que le contraire.
10. Il est presque aussi important de savoir reconnaître les bonnes idées de vos utilisateurs que d'avoir de bonnes idées vous-mêmes. C'est même préférable, parfois.
12. Bien souvent, les solutions les plus innovantes, les plus frappantes, apparaissent lorsque vous réalisez que votre approche du problème était mauvaise.
13. La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever.
14. Tout outil doit être utile par rapport aux utilisations qu'il a été prévu d'en faire. Mais on reconnaît un outil vraiment excellent au fait qu'il se prête à des usages totalement insoupçonnés.
15. 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'informations, à moins que la machine destinataire ne vous y oblige !
16. Quand votre langage est loin d'être Turing equivalent, un peu de "sucre syntaxique" ne peut qu'aider.
17/ Un système de sécurité n'est pas plus sûr que le secret (la clé) qui le garde. Gare aux pseudos secrets !
18. Pour résoudre un problème intéressant commencer par trouver un problème qui vous intéresse.
19. Pour peu que le coordinateur du développement dispose d'un moyen de comunicaiton au moin aussi bon que l'Internet, et pour peu qu'il sache comment mener ses troupes sans coercition, il est inévitable qu'il ya ait plus de choses dans plusieurs têtes que dans une seule.
Texte de Eric S. raymond
Traduction de Sébastien Blondel
linux-france.org/article/these/catherale-bazar/
--
______________________________
Nicolas Leduc
Webmestre / Responsable informatique
Reporters sans frontières
rsf@rsf.org - 01 44 83 84 58
http://www.rsf.org/