C'est une attitude que j'ai tendance aussi à avoir.
C'est le cas par exemple pour mon editeur XML wysiwyg basé sur Gecko, et diffusé sous licence libre. C'est quelque chose de complexe (validation temps réèl, hack de Gecko toussa) et donc, je n'ai pas de temps à perdre avec l'exterieur pour justifier mes choix techniques, pour justifier mes hacks sur Gecko, à répondre aux multiples questions qui ne manquerait pas d'y avoir sur un produit non utilisable. (inutilisable = questions pourquoi ça marche pas, forcement).
Bref, j'ai commencé à communiquer sur le logiciel qu'à partir du moment où on pouvait commencer à voir quelque chose d'utilisable, qui fonctionne "à peu prés". Mais je n'ai pas encore fait "la grosse pub" (cependant cela ne va pas trop tarder), car il y a encore pas mal de bug connu. Et j'ai pas envie d'avoir mon bugzilla pourri par des dizaines de doublons de déclarations de bugs.
J'ai fait la même chose aussi pour mon projet perso de framework PHP : j'ai bossé dessus tout seul, sans en parler à personne, histoire de bien reflechir sur les concepts que je voulais développer. Une fois que les bases étaient jétées, j'ai commencé à publier les sources. Et puis j'ai un peu plus de temps puisque le plus dur est fait, et du coup je suis plus receptif aux commentaires d'utilisateurs.
Bref, je pense que la façon de bosser de Novell est trés bien car elle permet effectivement une meilleur productivité.
Le seul problème peut être la review de code quand il s'agit d'intégrer des gros morceaux de code qu'on a développé ainsi en privé, dans un produit existant. Soit les responsables du projet font confiance. Soit il va leur falloir du temps pour valider le code produit et l'intégrer alors dans le tronc. (Par exemple, dans Mozilla, tout patch est revu au moins par deux personnes différentes : mes patchs pour l'editeur XML étant gros et complexes, une fois que je les aurais proposé, vont mettre quelques mois avant d'être intégrés dans le tronc, processus qualité oblige).
[^] # Re: Novell a raison
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Quand l'union ne fait pas forcement la force.... Évalué à 9.
C'est le cas par exemple pour mon editeur XML wysiwyg basé sur Gecko, et diffusé sous licence libre. C'est quelque chose de complexe (validation temps réèl, hack de Gecko toussa) et donc, je n'ai pas de temps à perdre avec l'exterieur pour justifier mes choix techniques, pour justifier mes hacks sur Gecko, à répondre aux multiples questions qui ne manquerait pas d'y avoir sur un produit non utilisable. (inutilisable = questions pourquoi ça marche pas, forcement).
Bref, j'ai commencé à communiquer sur le logiciel qu'à partir du moment où on pouvait commencer à voir quelque chose d'utilisable, qui fonctionne "à peu prés". Mais je n'ai pas encore fait "la grosse pub" (cependant cela ne va pas trop tarder), car il y a encore pas mal de bug connu. Et j'ai pas envie d'avoir mon bugzilla pourri par des dizaines de doublons de déclarations de bugs.
J'ai fait la même chose aussi pour mon projet perso de framework PHP : j'ai bossé dessus tout seul, sans en parler à personne, histoire de bien reflechir sur les concepts que je voulais développer. Une fois que les bases étaient jétées, j'ai commencé à publier les sources. Et puis j'ai un peu plus de temps puisque le plus dur est fait, et du coup je suis plus receptif aux commentaires d'utilisateurs.
Bref, je pense que la façon de bosser de Novell est trés bien car elle permet effectivement une meilleur productivité.
Le seul problème peut être la review de code quand il s'agit d'intégrer des gros morceaux de code qu'on a développé ainsi en privé, dans un produit existant. Soit les responsables du projet font confiance. Soit il va leur falloir du temps pour valider le code produit et l'intégrer alors dans le tronc. (Par exemple, dans Mozilla, tout patch est revu au moins par deux personnes différentes : mes patchs pour l'editeur XML étant gros et complexes, une fois que je les aurais proposé, vont mettre quelques mois avant d'être intégrés dans le tronc, processus qualité oblige).