Je me demandais comment obtenir des contributions à un nouveau produit open source que mon équipe développera. Nous sommes encouragés à obtenir autant de soutien de la communauté au sens large que possible, mais je peux également voir que cela absorbe beaucoup de temps en s'assurant que les tiers situés à l'extérieur de notre bureau sont sur la bonne voie en ce qui concerne la qualité du code. De plus, au début du projet, nous aurons probablement beaucoup de discussions informelles au sein de l'équipe centrale concernant la conception du système, les pics, etc. et les mettre en ligne pour permettre la participation de la communauté prendra beaucoup de temps et je peux imaginer que cela pourrait rendre le discussion moins efficace.
Il y a un côté plus humain à cela qui doit probablement être pris en considération: permettre à la communauté de participer au processus de conception peut également avoir ses avantages en ce qui concerne l'appropriation perçue du projet, et il y a toujours une chance qu'une implication précoce puisse relever des problèmes que le noyau l'équipe n'a pas remarqué.
Donc la question: à quelle étape d'un projet Open Source devriez-vous inviter des contributions de la communauté?
Réponses:
Au tout début! Vous voulez que la communauté ait le sentiment qu'elle a un véritable intérêt dans votre projet, sinon elle aura l'impression d'être utilisée comme main-d'œuvre gratuite.
Toute communication doit se faire via une liste de diffusion publique ou un forum, ce qui renforce encore l'idée de la communauté.
Vous pouvez atténuer le problème de «conception par comité» en exposant une vision claire dans vos messages initiaux à la liste de diffusion, par exemple
"Nous cherchons donc un modèle de domaine pour représenter notre animalerie (selon JIRA-4). Quelqu'un voit-il des problèmes majeurs avec ce modèle?"
Pour ce qui est d'accepter les contributions physiques réelles, vous devez commencer par accepter les correctifs et effectuer des révisions de code public à leur sujet. De cette façon, les contributeurs peuvent déjà voir publiquement à quel type de normes de codage ils doivent adhérer. Assurez-vous que vos validations sont également disponibles dans une liste de diffusion de validations - vous devez respecter les mêmes normes!
Il est également avantageux d'avoir des normes de projet sur un wiki ou un autre document de ce type.
Lisez http://www.producingoss.org pour plus de détails sur la façon de gérer un projet open source réussi.
la source
Cela a été longuement discuté dans le discours de Google IO Mythe du génie , par Brian Fitzpatrick et Ben Collins-Sussman de Subversion. En bref, ils ont conclu qu'il ne devrait pas être si tôt qu'il n'y a encore rien (c'est-à-dire "viens voir mon projet génial! Il n'y a pas vraiment grand-chose ici mais beaucoup de choses géniales sont prévues!") Ou trop tard donc toutes les décisions sont déjà prises (il est difficile d'obtenir un mot sur un projet solo.)
la source
Je suis d'accord avec Martijn Verburg . Vous devriez commencer à solliciter des contributions dès le début. J'ai déjà écrit un peu à ce sujet .
Le résumé de ce message est que le logiciel pourrit. Si vous voulez le garder frais, vous devez faire l'entretien. Et plus un projet est populaire, plus il y aura de bogues, plus de fonctionnalités seront ajoutées et plus cette tâche de maintenance vous gênera.
En fait, c'est un problème très courant. Il y a un grand discours de Fat intitulé Qu'est-ce que l'open source et pourquoi je me sens si coupable? Dans cette conférence (que je vous recommande fortement de regarder), il raconte l'histoire de l'un de ses projets OSS, et comment au fil du temps, il s'est retrouvé à passer la plupart de son temps libre à effectuer des tâches de triage et de gestion des tickets. Et il parle de la façon dont cela a été dommageable. C'est quelque chose que je peux complètement comprendre.
La solution, bien sûr, consiste à ajouter des personnes au projet tôt et souvent. Votre temps est limité et précieux. Investissez-le dans la croissance de votre base de contributeurs et le reste de vos problèmes commence à prendre soin d'eux-mêmes.
Comme je le dis à la fin de mon article: "Qu'est-ce qui est le plus important pour votre projet: fonctionnalités ou avenir? Choisissez-en un et hiérarchisez vos efforts en conséquence."
la source