pour rappel, GIT le SCM du noyau fait par les dev du noyau ... a été fait en mode fermé avec une équipe super restreinte, puis l'équipe s'est partiellement ouverte et maintenant est totalement ouverte.
Je ne sais plus ou j'ai lu ou entendu cela, mais il semblerait que les reunions/commissions/groupes de travail augmente leur productivité de maniere significative jusqu'a 4-5 membres ... apres et jusqu'à 7 l'augmentation est de plus en plus faible ... à partir de 8, la productivité regresse de maniere exponentielle.
donc quand le comité doit "produire de zéro" un truc, ouvrir est une catastrophe de non productivité. par contre, quand il y a un existant solide, ouvrir permet de consolider et fluidifier les echanges puisque qu'il y a une base commune ou plusieurs petits groupes peuvent se former pour ne travailler que sur une petite partie de l'ensemble.
Ce que j'expose est aussi ressenti chez pas mal de codeurs réguliers dans de gros applis libres, ou beaucoup preferent discuter en privé, et fuient comme la peste les threads/listes où des personnes qui ne savent pas coder ou qui viennent d'apprendre essaie de les persuader que ce qu'ils ont fait jusqu'a présent ne peut pas marcher et qu'il faut faire autrement.
Cela se voit aussi dans l'inefficacité du management au niveau du projet Debian ( et je suis debianiste ). Debian peut etre vu comme une super commission de plusieurs milliers de mainteneurs. l'absence de leadership fait qu'il n'y a de release que quand les etoiles sont correctement aligné et que tout le monde est d'humeur a les considérés comme tel.
D'un autre coté, il faut voir l'autre pendant : trop d'utilisateurs trop tot. l'ouverture à tout le monde avant d'avoir un truc de réellement présentable, donne aux utilisateurs soit l'impression d'un produit incomplet et mal foutu, soit crée un engoument et génere des bug-report ou l'équipe de dev ne peut pas suivre ( le projet Mozilla s'est reveillé recemment pour des bugs génant que j'ai rapportée il y a plus de 2 ans et plus de 4 ans, je leurs est répondu qu'entre temps j'avais changé de boite et que je ne pouvais plus verifier ).
Donc, l'attitude de Novell comme de tant d'autres projets Open Source ( qui connaissait Zimbra avant l'annonce fracassante qui a eu lieu ? ) est tout a fait correct.
Release Often disait LBT à propos de son expérience, mais il ne faut pas oublier qu'avant de commencer à le faire, il a passé plus d'un an de silence entre ses deux annonces sur comp.os.minix pour pouvoir avoir quelque chose qui plaise.
# Novell a raison
Posté par Mouns . En réponse au journal Quand l'union ne fait pas forcement la force.... Évalué à 10.
Je ne sais plus ou j'ai lu ou entendu cela, mais il semblerait que les reunions/commissions/groupes de travail augmente leur productivité de maniere significative jusqu'a 4-5 membres ... apres et jusqu'à 7 l'augmentation est de plus en plus faible ... à partir de 8, la productivité regresse de maniere exponentielle.
donc quand le comité doit "produire de zéro" un truc, ouvrir est une catastrophe de non productivité. par contre, quand il y a un existant solide, ouvrir permet de consolider et fluidifier les echanges puisque qu'il y a une base commune ou plusieurs petits groupes peuvent se former pour ne travailler que sur une petite partie de l'ensemble.
Ce que j'expose est aussi ressenti chez pas mal de codeurs réguliers dans de gros applis libres, ou beaucoup preferent discuter en privé, et fuient comme la peste les threads/listes où des personnes qui ne savent pas coder ou qui viennent d'apprendre essaie de les persuader que ce qu'ils ont fait jusqu'a présent ne peut pas marcher et qu'il faut faire autrement.
Cela se voit aussi dans l'inefficacité du management au niveau du projet Debian ( et je suis debianiste ). Debian peut etre vu comme une super commission de plusieurs milliers de mainteneurs. l'absence de leadership fait qu'il n'y a de release que quand les etoiles sont correctement aligné et que tout le monde est d'humeur a les considérés comme tel.
D'un autre coté, il faut voir l'autre pendant : trop d'utilisateurs trop tot. l'ouverture à tout le monde avant d'avoir un truc de réellement présentable, donne aux utilisateurs soit l'impression d'un produit incomplet et mal foutu, soit crée un engoument et génere des bug-report ou l'équipe de dev ne peut pas suivre ( le projet Mozilla s'est reveillé recemment pour des bugs génant que j'ai rapportée il y a plus de 2 ans et plus de 4 ans, je leurs est répondu qu'entre temps j'avais changé de boite et que je ne pouvais plus verifier ).
Donc, l'attitude de Novell comme de tant d'autres projets Open Source ( qui connaissait Zimbra avant l'annonce fracassante qui a eu lieu ? ) est tout a fait correct.
Release Often disait LBT à propos de son expérience, mais il ne faut pas oublier qu'avant de commencer à le faire, il a passé plus d'un an de silence entre ses deux annonces sur comp.os.minix pour pouvoir avoir quelque chose qui plaise.