Leçons apprises —

L’Open Source est l’épine dorsale du développement logiciel moderne. En tant que personne profondément impliquée dans l’open source à la fois communautaire et dirigé par l’entreprise, j’ai eu le privilège de découvrir personnellement ses diverses approches. Cet article explore à quoi ressemble la création OSS (Open Source) moderne, en se concentrant sur les bibliothèques JavaScript frontales telles que TresJS et les outils auxquels j’ai contribué à Bloc d’histoire.

Mais laissez-moi être clair :

Il n’existe pas de manuel universel pour les logiciels libres. Chaque langage, framework et projet a ses propres flux de travail, règles et culture – et ce n’est pas grave. Ces variations sont ce qui rend l’open source si adaptable et diversifié.

L’art de la création de logiciels libres

La création d’un projet open source commence souvent par se gratter soi-même : résoudre un problème auquel vous êtes confronté en tant que développeur. Mais à mesure que votre « expérience » gagne du terrain, le défi se déplace vers la résolution de divers cas d’utilisation tout en conservant la simplicité et l’orientation de l’idée originale.

Prenons TresJS comme exemple. Tout ce que je voulais, c’était ajouter la 3D à mon portefeuille personnel Nuxt, mais à cette époque, il n’existait pas d’alternative maintenue et riche en fonctionnalités à React Three Fiber dans VueJS. J’ai donc décidé d’en créer un. Assez drôle, deux ans après le lancement de la bibliothèque, mon portfolio reste inachevé.

En continuant avec TresJS comme exemple de projet OSS piloté par la communauté, la communauté a fait partie intégrante de sa croissance, proposant des idées, déposant des problèmes (environ 531 au total) et soumettant des demandes de tirage (environ 936 PR), dont 90 % a finalement atteint la production. En tant qu’auteur, c’est la meilleure chose qui puisse arriver – c’est probablement l’une des principales raisons pour lesquelles je suis tombé amoureux de l’open source. La collaboration continue crée un environnement dans lequel de nouvelles idées peuvent évoluer vers des contributions significatives.

Cependant, cela comporte également ses propres défis. Plus les idées arrivent, plus il devient difficile de maintenir le projet centré sur son objectif initial.

En tant qu’auteurs, il est de notre responsabilité de garder claire la vision de la bibliothèque, même si cela signifie dire non aux grandes idées de la communauté.

Au fil du temps, certains des collaborateurs les plus constants sont devenus partie intégrante d’une équipe de base, aidant à partager la responsabilité de l’entretien de la bibliothèque et garantissant qu’elle reste alignée sur ses objectifs initiaux.

Un autre aspect crucial de la mise à l’échelle d’un projet, en particulier un projet comme TresJS, qui est devenu un écosystème de packages, est la capacité de déléguer. Plus le projet s’étend, plus il devient essentiel de répartir les responsabilités entre les contributeurs. La délégation aide à réduire le fardeau de la charge de travail massive et permet aux contributeurs de s’approprier de domaines spécifiques. En tant qu’auteur principal, il est tout aussi important de fournir les outils, les flux de travail CI et les conventions claires nécessaires pour rendre le processus de contribution aussi simple et efficace que possible. Une base bien préparée garantit que les collaborateurs, nouveaux et existants, peuvent se concentrer sur ce qui compte vraiment : faire avancer le projet.

Création de logiciels libres pilotée par l’entreprise : la perspective Storyblok

Maintenant que nous avons exploré les points positifs et les défis des logiciels libres pilotés par la communauté, passons à un autre domaine : les logiciels libres pilotés par l’entreprise.

J’avais de l’expérience avec l’inner-source et l’open-source dans des entreprises précédentes, j’avais donc déjà une compréhension du fonctionnement des logiciels libres dans le contexte d’un environnement d’entreprise. Cependant, mon expérience la plus significative viendra plus tard, plus précisément plus tôt cette année, lorsque je passerai de DevRel à celui d’ingénieur d’expérience développeur à temps plein, et je dis « à temps plein » car avant d’accepter ce rôle, je contribuais déjà à L’écosystème SDK de Storyblok.

À Bloc d’histoirel’open source joue un rôle crucial dans la manière dont nous interagissons avec les développeurs et dans la manière dont ils utilisent notre produit de manière transparente avec leur framework préféré. Notre objectif est de fournir la même expérience aux développeurs, quelle que soit la version, en rendant l’expérience d’utilisation de Storyblok aussi simple, efficace et agréable que possible.

Pour y parvenir, il est crucial de équilibrer les besoins de la communauté des développeurs – qui reflètent souvent les besoins des clients pour lesquels ils travaillent – ​​avec les objectifs plus larges de l’entreprise. L’une des choses que je trouve les plus difficiles est gérer les attentes. Par exemple, même si la communauté souhaite que les demandes de fonctionnalités et les corrections de bugs soient mises en œuvre rapidement, les priorités de l’entreprise peuvent dicter de se concentrer sur la stabilité, l’évolutivité et souvent sur les intégrations stratégiques. Communication claire et priorisation sont essentiels au maintien d’un alignement sain et d’une confiance entre les deux parties.

L’un des avantages uniques de l’Open Source piloté par les entreprises est la disponibilité des ressources:

• Temps d’ingénierie dédié,
• Infrastructure (que de nombreux auteurs de logiciels libres ne peuvent souvent pas se permettre),
• Accès aux connaissances des équipes internes telles que la conception, l’assurance qualité et la gestion des produits.

Cependant, cette configuration présente souvent le défi de gérer des bases de code héritées, généralement écrites par des développeurs qui ne sont peut-être pas familiers avec les principes des logiciels libres. Cela peut entraîner des incohérences dans la structure, les tests et la documentation qui nécessitent une refactorisation importante avant que le projet puisse s’aligner sur les meilleures pratiques open source.

J’aime considérer les logiciels libres axés sur la communauté comme étant comme la musique jazz : de forme libre, improvisée et profondément collaborative. En revanche, l’OSS, dirigé par une entreprise, ressemble à un orchestre, avec un chef d’orchestre guidant la performance et veillant à ce que toutes les pièces s’emboîtent parfaitement.

La vérité est que la plupart des projets OSS – voire la grande majorité – existent quelque part dans ce spectre. Par exemple, TresJS a commencé comme un projet purement communautaire, mais à mesure qu’il mûrissait et gagnait du terrain, des éléments de prise de décision structurée – plus typiques des projets menés par une entreprise – sont devenus nécessaires pour maintenir la concentration et l’évolutivité. En collaboration avec l’équipe principale, nous avons défini une vision et des objectifs pour le projet afin de garantir qu’il continue de croître sans perdre de vue son objectif initial.

Il est intéressant de noter que l’inverse est également vrai : les logiciels libres pilotés par l’entreprise peuvent bénéficier de manière significative de l’innovation rapide observée dans les projets pilotés par la communauté.

La plupart des améliorations que j’ai apportées au Écosystème Storyblok depuis notre arrivée, nous avons été inspirés par les idées explorées pour la première fois dans TresJS. Par exemple, la migration de l’écosystème TresJS vers pnpm workspaces a démontré comment une gestion rationalisée des dépendances pouvait améliorer les flux de travail de développement tels que les terrains de jeux et e2e – une approche que nous avons progressivement adaptée plus tard pour l’écosystème de Storyblok.

De même, la transition des tests Storyblok de Jest vers Vitest, avec ses performances améliorées et l’expérience des développeurs, a été influencée par la façon dont les tests sont abordés dans les projets communautaires. De même, notre passage de Prettier à la configuration plate v9 d’ESLint avec correction automatique a permis de consolider le peluchage et le formatage en un seul flux de travail, rationalisant ainsi la productivité des développeurs.

Des processus encore plus granulaires, tels que la modernisation des flux de travail CI, ont trouvé leur place dans Storyblok. L’évolution de TresJS d’une action de publication monolithique unique vers des étapes granulaires de peluchage, de test et de construction a fourni un modèle pour améliorer nos pipelines chez Storyblok. Nous avons également adopté des pratiques de publication continue inspirées par pkg.pr.newpermettant une livraison plus rapide des modifications incrémentielles et des tests de versions de packages dans des projets clients réels pour recueillir des commentaires immédiats avant de fusionner les PR.

Cela dit, TresJS a également bénéficié de mes expériences chez Storyblok, qui disposait d’un écosystème plus mature et éprouvé, notamment dans l’adoption de processus automatisés. Par exemple, nous avons intégré Dependabot pour maintenir les dépendances à jour et utilisé la fusion automatique pour réduire les interventions manuelles pour les mises à jour mineures, libérant ainsi du temps aux contributeurs pour un travail plus significatif. Nous avons également mis en œuvre un pipeline de versions automatiques à l’aide de GitHub Actions, inspiré des workflows de Storyblok, garantissant des versions plus fluides et plus fiables pour l’écosystème TresJS.

Les défis de la création OSS moderne

Tout au long de cet article, nous avons abordé plusieurs défis modernes des logiciels libres, mais si l’un d’entre eux mérite la couronne, c’est gérer les modifications avec rupture et maintenir la compatibilité. Nous savons à quel point la technologie évolue rapidement, en particulier sur le Web, et les utilisateurs attendent des bibliothèques et des outils qu’ils suivent les dernières tendances. Je ne suis pas le premier à dire que le développement à la mode peut être amusant, mais il est intrinsèquement risqué et n’est pas votre meilleur allié lors de la création de logiciels fiables et performants, en particulier dans des contextes d’entreprise.

Des changements radicaux existent. C’est pourquoi le versioning sémantique entre en jeu pour nous faciliter la vie. Cependant, il est tout aussi important de équilibrer innovation et stabilité. Cela devient plus crucial lors de l’introduction de nouvelles fonctionnalités ou d’une refactorisation pour de meilleures performances, en cassant les API existantes. Une leçon clé que j’ai apprise — en particulier pendant mon séjour chez Storyblok — est l’importance de communication claire. Les journaux de modifications, les guides de migration et les avertissements de dépréciation sont des outils inestimables pour faciliter la transition pour les utilisateurs.

Un exemple pratique :

Mon premier projet en tant qu’ingénieur d’expérience développeur consistait à introduire @storyblok/richtextune bibliothèque de traitement de texte enrichi qui (au moment de la rédaction) enregistre environ 172 000 téléchargements par mois. La bibliothèque a été conçue à l’époque où j’étais DevRel, mais la transition des utilisateurs vers celle-ci à partir de la précédente implémentation de texte riche dans l’ensemble de l’écosystème a nécessité une planification minutieuse. Étant donné que la bibliothèque deviendrait une dépendance du SDK JS fondamental – et à partir de là se propagerait à tous les SDK du framework – avec mon responsable, nous avons planifié une transition de plusieurs mois avec une période rétrocompatible avant la version majeure. Cela comprenait des campagnes de communication, une documentation complète et une adoption progressive pour minimiser les perturbations.

Malgré ces efforts, des erreurs se sont produites – et ce n’est pas grave. Au cours de la transition vers le texte enrichi, il y a eu des cas où les mises à jour n’arrivaient pas à temps ou où la communication et la documentation étaient temporairement désynchronisées. Cela a semé la confusion au sein de la communauté, que nous avons résolue en fournissant une assistance rapide sur les problèmes de GitHub et de Discord. Ces moments ont rappelé que même avec une gestion des versions sémantique, des architectures modulaires et une planification méticuleuse, la création de logiciels libres n’est jamais parfaite. Les erreurs font partie du processus.

Et cela nous amène au point suivant.

Conclusion

La création open source est un voyage d’apprentissage continu. Chaque faux pas offre une chance de s’améliorer et chaque succès renforce la valeur de la collaboration et de l’expérimentation.

Il n’existe pas de manière « parfaite » de créer des logiciels libres, et c’est là toute sa beauté. Chaque projet a son propre ensemble de flux de travail, de défis et de bizarreries façonnés par la communauté et ses contributeurs. Ces différences rendent l’open source adaptable, dynamique, amusant et, surtout, percutant. Peu importe si vous construisez quelque chose d’entièrement nouveau ou si vous contribuez à un projet existant, n’oubliez pas que le progrès, et non la perfection, est l’objectif.

Alors continuez à contribuer, à expérimenter et à partager votre travail. Chaque pull request, problème et idée que vous proposez apporte de la valeur non seulement à votre projet mais à l’écosystème plus large.

Bon codage !

(ouais)