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 Black Fox . En réponse à la dépêche Les mythes du développement Open Source. Évalué à 10.
- 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é...