6 leçons que j'ai apprises en développant des projets Open Source

Le point de vue d'un data scientist

L'open source est un concept tellement incroyable ! En regroupant les sources, les compétences et les connaissances de toute une communauté, il est possible de créer des outils que nous n'aurions pas pu créer isolément. Les outils issus de ces collaborations sont véritablement plus que la somme de leurs parties.

En conséquence, nous, les data scientists, utilisons ce logiciel disponible gratuitement qui est à l'origine de nombreuses technologies, tout en ayant toujours la possibilité de participer à son développement.

Au cours des dernières années, j'ai eu la chance d'être impliqué dans l'open source et j'ai eu l'opportunité de développer et de gérer plusieurs packages !

Développer l’open source, c’est bien plus que simplement coder

Durant cette période, il y a eu de nombreux obstacles à surmonter et des leçons à tirer. Des dépendances délicates et des choix de conception d'API à la communication avec la base d'utilisateurs.

Travailler sur l'open source, que ce soit en tant qu'auteur, responsable ou développeur, peut être assez intimidant ! Avec cet article, je partage certaines de mes expériences dans ce domaine qui, je l'espère, aideront ceux qui souhaitent développer l'open source.

Lorsque vous créez un logiciel open source, vous ne créez généralement pas le package exclusivement pour vous-même. Des utilisateurs, issus de tous types d’horizons différents, utiliseront votre logiciel. Une documentation appropriée aide grandement ces utilisateurs à démarrer.

Cependant, ne sous-estimez pas l’impact que la documentation peut avoir sur l’utilisabilité de votre package ! Vous pouvez l'utiliser pour expliquer des algorithmes complexes, proposer des didacticiels détaillés, présenter des cas d'utilisation et même permettre des exemples interactifs.

Les logiciels liés à la science des données, en particulier, peuvent être difficiles à comprendre lorsqu'ils impliquent des algorithmes complexes. Aborder ces explications comme une histoire m’a souvent aidé à les rendre plus intuitives.

Croyez-moi, rédiger une bonne documentation est une compétence en soi.

Un autre avantage est que la rédaction d’une documentation solide réduit le temps consacré aux problèmes. Les utilisateurs ont moins de raisons de poser des questions s’ils peuvent trouver les réponses dans votre documentation.

Cependant, créer de la documentation ne se résume pas à simplement l’écrire. La visualisation de votre algorithme ou logiciel contribue grandement à le rendre intuitif. Vous pouvez apprendre beaucoup de choses de Jay Alammar lorsque vous souhaitez visualiser des principes algorithmiques dans votre documentation. Ses visualisations se sont même retrouvées dans le fichier officiel Numpy Documentation!

Votre base d'utilisateurs, la communauté, est un élément important de votre logiciel. Puisque nous développons des logiciels open source, nous pouvons affirmer sans risque de se tromper que nous souhaitons qu’ils soient impliqués dans le développement.

En vous engageant avec la communauté, vous l'incitez à partager des problèmes et des bugs, mais également des demandes de fonctionnalités et d'excellentes idées pour un développement ultérieur ! Tout cela aide à créer quelque chose pour eux.

La communauté open source est bien plus que la somme de ses parties

De nombreuses fonctionnalités principales de BERTopic, comme modélisation de sujets en ligne, ont été mis en œuvre car ils étaient très demandés par ses utilisateurs. En conséquence, la communauté est très active et a été d’une aide précieuse pour détecter les problèmes et développer de nouvelles fonctionnalités.

Que votre package soit utilisé des millions de fois ou seulement quelques-unes, en créer un est une excellente opportunité d'en apprendre davantage sur l'open source, le MLOps, les tests unitaires, la conception d'API, etc. J'ai appris davantage sur ces compétences en développant de l'open source. que je ne l'aurais fait dans mon travail quotidien.

Il existe également une énorme opportunité d’apprentissage en interagissant avec la communauté elle-même. Ce sont eux qui vous disent quels designs ils aiment ou non. Parfois, j’ai vu le même problème apparaître plusieurs fois au cours de quelques mois. Cela indique que je devrais repenser le design car il n’était pas aussi convivial que je l’avais prévu !

De plus, développer des projets open source m'a donné l'opportunité de collaborer avec d'autres développeurs.

Travailler sur vos propres projets open source en dehors du travail présente des inconvénients. Pour moi, le plus important est que gérer le paquet, répondre aux questions et participer aux discussions peut représenter beaucoup de travail.

Cela aide certainement si vous êtes intrinsèquement motivé, mais il faut encore un certain temps pour s'assurer que tout se déroule bien.

Heureusement, vous pouvez vous tourner vers votre communauté pour vous aider lorsque vous répondez à des questions, présentez des cas d'utilisation, etc.

Au cours des dernières années, j’ai appris à être un peu plus détendu lorsqu’il s’agit de changements brusques. Surtout lorsqu’il s’agit de dépendances, il y a parfois tellement de choses à faire !

Savoir à quelle fréquence votre package est utilisé est d’une aide précieuse pour comprendre sa popularité. Cependant, nombreux sont ceux qui utilisent encore les étoiles de Github pour assimiler un package à la qualité et à la popularité.

En tant que data scientists, nous devons d’abord comprendre ce que nous mesurons exactement. Les étoiles GitHub ne sont rien de plus qu'un utilisateur attribuant une étoile à un package. Cela ne signifie même pas qu’ils ont utilisé le logiciel ou qu’il fonctionne réellement !

Techniquement, je peux payer un millier de personnes pour démarrer mes dépôts. Au lieu de cela, je me concentre sur une variété de statistiques, comme les téléchargements et les forks, mais aussi sur le nombre de problèmes que je reçois quotidiennement.

Par exemple, c'est formidable si vos packages sont présentés sur Hacker Nouvelles mais cela ne vous dit pas s'il est systématiquement utilisé.

En tant que psychologue, j'ai tendance à beaucoup me concentrer sur la conception de mes emballages. Cela inclut des éléments comme la documentation et les didacticiels, mais cela se traduit même par la façon dont je code.

S'assurer que le package est facile à utiliser et à installer rend l'adoption beaucoup plus simple. Surtout lorsque vous vous concentrez sur des philosophies de conception telles que la modularité et la transparence, certains packages deviennent un plaisir à utiliser.

Adopter le point de vue d'un psychologue tout en développant de nouvelles fonctionnalités a permis de savoir beaucoup plus facilement sur quoi se concentrer. Que recherchent les utilisateurs ? Comment puis-je coder d’une manière qui explique l’algorithme ? Pourquoi les utilisateurs utilisent-ils réellement ce package ? Quels sont les inconvénients majeurs de mon code ?

Prendre le temps de comprendre l’utilisateur moyen stimule l’adoption

Tout ce qui précède conduit souvent à une règle fondamentale mais importante :
Gardez les choses très simples

Personnellement, si je trouve un nouveau package difficile à installer et à utiliser, je suis moins susceptible de l'adopter dans mon flux de travail.

Si vous êtes, comme moi, passionné par l'IA, la science des données ou la psychologie, n'hésitez pas à m'ajouter LinkedIn ou suivez-moi sur Twitter. Vous pouvez également retrouver une partie de mon contenu sur mon Site Web personnel.

Toutes les images sans crédit source ont été créées par l'auteur

6 leçons que j'ai apprises en développant des projets open source republiés à partir de la source https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 via https://towardsdatascience.com/feed

<!–

->