Bonjour à tous,
petite question qui s’adresse principalement aux techniques mais qui devrait intéresser les business.
A votre avis, sur le plan technique, qu’est-ce qui fait qu’un projet open source a plus de chances de réussir qu’un autre ? J’entends par là pourquoi un projet open source arrive-t-il a susciter plus d’intérêts (plus de développeurs, de contributions, etc.) qu’un autre ?
Le défi technique ? Les beaux yeux des « leaders » ? L’ambiance au sein de la communauté ?
A mon avis, et dans le désordre …
Des technologies populaires : S’il les technologies sont anciennes et pas vraiment populaires, le projet aura certainement du mal à prendre … Beaucoup de développeur contribuent en opensource pour améliorer leur compétence par la pratique, sur des technologies qui les intéressent et qu’ils n’ont pas toujours l’occasion de mettre en oeuvre dans le monde professionnel.
Un intérêt du développeur en tant qu’utilisateur : Le projet doit avoir un intérêt en soi pour le développeur. Ça sera compliqué pour d’éventuels développeurs de s’investir s’ils n’y trouvent pas eux-même un intérêt en tant qu’utilisateur. Quoi de mieux pour un développeur d’utiliser ce qu’il a codé ?
La réponse à un besoin des entreprises : Si le projet réponds aux besoins de certaines entreprises, elles affecteront peut-être des ressources pour contribuer. Cela peut accélérer énormément le développement d’un projet, et même l’orienter.
Rien avant le MVP : Le premier commit (ou bien le début de la communication autour du projet et l’appel aux contributions), doit se faire sur un socle technique complet, qui corresponds au MVP. Il doit également inclure le minimum de documentation pour que les nouveaux arrivants puisse comprendre quelque chose. Le projet doit vraiment être fonctionnel dés le début.
La qualité du code et les outils d’intégration : Il est important d’avoir une intégration continue pour que le projet soit fonctionnel en permanence. Un simple bug peut refouler certains contributeurs tout simplement parce qu’ils n’ont pas réussi à mettre en place l’environnement. Une bonne documentation développeur, avec un getting started par exemple. Une architecture par plugin est en général une bonne idée, car il est plus simple de raisonner par analogie avec des plugins existants, plutôt que d’aller trifouiller dés le début dans le cœur d’un projet. Il faut donc prendre un soin tout particulier à l’API exposée, pour que celle ci soit la plus simple possible à mettre en oeuvre.
Anglais uniquement : Tous les développeurs comprennent et savent écrire en Anglais. Donc, anglais uniquement.
Merci Rémi, top comme réponse 
Quelqu’un voit autre chose ?
J’ajouterais l’accompagnement des nouveaux contributeurs. Il faut avoir un stock de petites issues simples à régler et ne nécessitant pas une connaissance approfondie des entrailles du projet. L’idéal est de les tagger dans le bug tracker et de dédier un peu plus de temps aux primo-contributeurs. Ça réduit énormément la friction de contribution.