La vie intime d’un projet open source comme Babylon.js

Le but de cet article est de vous proposer la vision de trois personnes sur une même question : comment gérer un projet open source (qui a un peu de succès).

Pour ce faire nous avons autour de la table les trois personnes suivantes :

• David Catuhe (@deltakosh) : Co-auteur de Babylon.js et Vorlon.js
• Étienne Margraff (@meulta) : Co-auteur de Vorlon.js
• David Rousset (@davrous) : Co-auteur de Babylon.js et Vorlon.js

Nous avons chacun écrit notre partie dans notre coin et vous donnant nos ressentis sur chacun des projets que l’on gère.

@deltakosh

Pour être complètement honnête, la première raison pour laquelle j’ai écrit Babylon.js, c’était parce que je suis un fan de l’écriture de moteurs 3D. C’est une passion comme une autre me direz-vous. Il s’est avéré par la suite qu’avec David (Rousset) nous avons su en parler aux bonnes personnes et finalement une communauté s’est construite autour du produit.

Dans mon esprit, la principale raison pour laquelle je voulais qu’un utilisateur choisisse Babylon.js devait être sa simplicité. Je considère que la vraie beauté, le vrai art du code, c’est quand l’on arrive à produire quelque chose de simple au-dessus de quelque chose de compliqué. Prenons WebGL par exemple. Ce n’est pas une API facile d’accès surtout si on rajoute par-dessus la compréhension des mathématiques euclidiennes ou encore l’écriture de shaders en GLSL. Babylon.js doit donc être là pour abstraire cette complexité et fournir à la place une API claire. (J’appelle cela la réussite du Petit Prince : avoir une API capable de faire Babylon.Draw("mouton", "juste là, à gauche")).

Avoir une ligne directrice est donc selon moi essentiel lorsque l’on gère un projet open source. Car si le début est toujours très rigolo avec ses commits et ses nouvelles fonctionnalités, vous allez vite devoir faire face à votre nouveau pire cauchemar : l’utilisateur.

Il existe toutefois plusieurs catégories d’utilisateurs. L’une des pires est, à mon avis, le « réformateur ». Ce dernier est un utilisateur qui veut faire un Pull Request non pas pour ajouter une fonctionnalité ou corriger un bug mais plutôt pour retourner votre architecture qu’il trouve « trop primitive ». « Tu n’utilises pas assez de design patterns à la mode. Il faut tout revoir. Je te propose de mettre en place un système a 18 niveaux d’interfaces pour prendre en compte le Klingon et le rendu au crayon gris. ». Il faut alors savoir garder le cap qui constitue l’essence même de votre projet et qui a fait de lui ce qu’il est aujourd’hui.

Il ne faut pas non plus tomber dans l’excès inverse et ne valider aucune demande ni modification. On ne peut pas avoir raison tout seul. Et je vous garantis que cela pose de vrais cas de conscience : dois-je valider ce Pull Request ? Il apporte une super fonctionnalité mais elle semble un peu pénible à mettre en œuvre. Dois-je demander une mise à jour ? La faire moi-même ? Bref, soyez prêt à vous prendre la tête.

Je reste toutefois persuadé que ce sont les utilisateurs qui sont la vraie richesse d’un framework. Ils vous forcent à adapter votre projet, à le confronter à la réalité. Si on prend le cas de Babylon.js, nous sommes arrivés en vrai outsider avec un Three.js massivement implanté dans le décor depuis au moins quatre ans. Nous étions deux à bosser dessus avec toutefois une idée en tête : faire simple mais efficace. Je voyais le repository de Three.js avec ses 440 issues ouvertes, cela me rendait malade. Pour moi, un bon projet doit avoir moins de 10 issues ouvertes sinon comment les utilisateurs peuvent-ils avoir confiance ? Il faut qu’ils se sentent soutenus, qu’ils sachent que s’ils ont un problème ça ne mettra pas vingt ans avant d’avoir une réponse.

Et finalement c’est là la vraie richesse et la vraie difficulté : garantir que votre projet vive. Ce n’est au final pas les fonctionnalités qui comptent. Seule compte la réactivité dont vous allez faire preuve sur votre forum ou sur votre repository. Car c’est là que vous pourrez changer le ressenti de vos utilisateurs passant de « projet de confiance » à « projet moisi en mode zombie » selon que vous arriviez ou non à leur insuffler votre vision.

D’ailleurs aujourd’hui, je suis un développeur heureux quand je vois sur le forum de Babylon.js : « La vraie force de babylon.js, c’est sa communauté et son forum ».

@meulta

J’ai découvert réellement l’open source en arrivant chez Microsoft. Ma première contribution et mes premiers pas ont étés avec Babylon.js lorsque j’ai implémenté le support des textures procédurales. À ce moment, je n’étais que contributeur et je ne me rendais pas vraiment compte de ce que signifiait gérer un projet open source. Quand on est contributeur, on essaye de coller à la vision et la direction donnée par l’équipe cœur du projet. On propose de petites touches qui, on l’espère, vont améliorer un peu plus le projet d’origine. Initier un projet est une toute autre histoire…

Mon expérience de création a démarré avec Vorlon.js. Avant de publier la première version, on passe des heures à imaginer le projet. Quand on pense qu’on va apporter quelque chose à la communauté, on code la première version et on la publie. À ce moment, on est partagé par plusieurs émotions : « Est-ce que les gens vont s’en foutre de mon truc ? », « Je suis méga content d’avoir publié ! », « J’espère qu’ils ne vont pas trop regarder le code… ».

Et finalement les premiers retours tombent. Dans le cas de Vorlon.js, on a eu la chance énorme d’être présentés en keynote de la conférence //BUILD. Les premiers retours étaient excellents ! Et… les issues ont commencé à arriver. Malgré son esprit d’ouverture, au début, on le vit un peu comme une agression : « Euh non, il a mal testé, y’a pas de bug là », « C’est quoi cette idée de fonctionnalité en mousse ? ». Et rapidement, on se détend un peu et on se rappelle qu’on est là pour la magie de l’open source : créer un projet avec des centaines de développeurs à travers le monde.

Avec chaque correction de bug, chaque nouvelle fonctionnalité implémentée et chaque Pull Request validée sur GitHub, notre vision du projet s’affine.

Avoir une vision dans un projet open source, ce n’est pas forcément être borné où vouloir garder le projet pour soi. C’est simplement donner la ligne directrice principale pour éviter que l’application ou le framework soit dénaturé. N’est-ce pas pour ça que les forks existent ? Si quelqu’un veut donner une vie parallèle à votre projet, super ! Il peut le faire en initiant une évolution différente. Quoi de mieux d’ailleurs de se dire que son idée en a générée d’autres ?

À chaque nouvel arrivant majeur dans le projet, c’est un nouveau challenge pour garder cette ligne directrice.

Chacun exprime son avis et c’est normal. Pour que tout se passe bien, il faut communiquer. Ne pas faire ses modifications dans son coin et plutôt agir comme une équipe. C’est pour ça qu’il y a toujours un cœur qui anime la communauté qui se créée tout en évitant de brider toutes les nouvelles idées. N’oublions pas que c’est cette communauté qui assure la réactivité du projet et sa pérennité !

C’est un chemin long et ça prend du temps. Mais quelle satisfaction quand vous croisez quelqu’un qui vous dit : « j’utilise ton truc, ça m’a vraiment aidé : merci ! »

@davrous

Babylon.js est mon premier projet open-source. Après quinze ans de boite, je fus assez rapidement surpris par cet univers en tant que « vieil » employé de Microsoft où la culture du « closed source » fut longtemps ma seule voie. Ainsi, le monde merveilleux tant vanté pendant des années par « l’autre camp » fut intéressant à découvrir.

La découverte la plus violente : en fait, globalement, personne n’en a rien à carrer de votre code ! Il est certes ouvert et lisible mais rares sont les personnes qui prennent le soin de le lire. C’est tellement plus simple de solliciter directement l’auteur pour qu’il ajoute un truc ou corrige une erreur à votre place. Les projets gratuits et libres sont souvent vus comme des biens de consommation comme d’autres. Les gens se servent comme des goinfres et auront peu de respect pour vous. N’espérez pas avoir de meilleurs êtres humains en face de vous grâce à l’open source. Ils n’hésiteront même pas à vous agresser si vous n’allez pas assez vite pour répondre à leur desiderata ! Bref, j’ai commencé par halluciner et être déçu.

Heureusement, nous avons réussi à prendre sur nous et à éviter d’envoyer balader les malotrus. La tentation fut grande pourtant, mais l’histoire nous a donné raison. En restant courtois et disponibles, nous avons fini par attirer d’excellents contributeurs. Après environ une année de galère à devoir tout faire : le site web, les problèmes d’hébergement, la mise en place du forum, la maintenance et optimisation du code pour nos utilisateurs, la magie a fini par opérer. D’autres personnes ont commencé à prendre le relais en répondant à notre place pour nous remercier. Puis l’apothéose fut la contribution de code à notre bébé ! Enfin, les gens lisaient et écrivaient du code pour nous aider. Ils contribuent même à l’écriture de la documentation ! Quelle joie cela procure. Réussir à créer une communauté. Il ne faut donc pas lâcher l’affaire mais il ne faut pas espérer qu’un projet open-source décolle magiquement immédiatement. Il faut le faire connaitre. Et s’il apporte quelque chose à la communauté, elle finira surement par vous le rendre.

L’impérieuse nécessité de conserver une vision et un leadership sur un tel projet est également vital. J’ai toujours eu une vision très claire de la direction à prendre et surtout des directions où je ne voulais surtout pas aller. Avoir beaucoup de contributeurs ou retours, c’est bien. Mais il ne faut pas se laisser embarquer à implémenter ou changer de cap sous l’impulsion de sa communauté, aussi top soit-elle, si cela dénature le projet initial. Garder une cohérence, une roadmap claire et pensée est indispensable, tant au niveau des fonctionnalités que de l’architecture. Aujourd’hui, nous sommes deux gardiens de l’esprit accompagnés d’une horde de joyeux copains. Cela semble plutôt bien fonctionner.

J’ai énormément appris grâce à ces projets open-source tant humainement que techniquement. Je suis très fier de voir qu’aujourd’hui des Ubisoft ou Xbox.com utilisent notre bébé jusqu’à parfois même contribuer au code ! Tentez l’aventure. C’est l’expérience la plus enrichissante qui m’ait été donnée jusqu’à présent.