Quand on spécifie un besoin et qu'on pose les bases d'une architecture, il est contre-productif d'être "le plus nombreux possible".
Il faut au contraire avoir une équipe resserrée, qui pourra définir une direction plus précise au projet.
C'est à dire trier les besoins par importance/pertinence, faire les recommandations techniques, coder l'architecture / les briques de base.
Une fois le projet lancé il est alors temps de s'ouvrir pour recueillir les avis, critiques et contributions. Mais la direction du projet a déjà été fixée et elle doit peu bouger.
Là en l'occurrence je vois mal comment Novell aurait pu ouvrir le code à la communauté au milieu du gué (c'est à dire sans démo du résultat final), puisque leur réalisation n'est pas une application mais plutôt un composant technique.
# C'est une bonne approche
Posté par Pierre Tramonson . En réponse au journal Quand l'union ne fait pas forcement la force.... Évalué à 3.
Il faut au contraire avoir une équipe resserrée, qui pourra définir une direction plus précise au projet.
C'est à dire trier les besoins par importance/pertinence, faire les recommandations techniques, coder l'architecture / les briques de base.
Une fois le projet lancé il est alors temps de s'ouvrir pour recueillir les avis, critiques et contributions. Mais la direction du projet a déjà été fixée et elle doit peu bouger.
Là en l'occurrence je vois mal comment Novell aurait pu ouvrir le code à la communauté au milieu du gué (c'est à dire sans démo du résultat final), puisque leur réalisation n'est pas une application mais plutôt un composant technique.