Dans une récente conférence où il présentait Contributopia, le projet pluriannuel de Framasoft, sous son angle politique, Pierre-Yves Gosset s’attachait à déboulonner quelques mensonges avec lesquels se rassurent les libristes. Le nombre présumé des contributeurs et contributrices, en particulier, était ramené à sa juste proportion :

Bien sûr, tout le monde ne peut pas envoyer des commits de code, mais l’exemple est symptomatique : le Logiciel Libre c’est surtout des consommateurs et consommatrices.

C’est ce que souligne également Carl Chenet, plume invitée ci-dessous. Il pointe en particulier le risque sérieux d’étiolement voire de disparition pure et simple des équipes parfois minuscules qui maintiennent des FOSS (Free and Open Source Software, appellation œcuménique qui joint Les logiciels libres et open source). Il en appelle à une contribution minimale qui consisterait au moins à faire connaître les projets et encourager les créateurs à continuer. Chez Framasoft, nous sommes tout à fait en phase avec cet appel, voyez par exemple cet article sur le Contribution Camp qui propose quelques pistes pour « avancer ensemble vers la contribution ».

Logiciels libres et open source : le consumérisme passif tue la communauté
Par Carl CHENET

article aussi publié en anglais sur mon blog

En bref : ne soyez pas un consommateur passif de logiciels libres. Cela va tuer la communauté FOSS ou lui nuire. Contribuez de n’importe laquelle des manières décrites dans cet article, même la plus élémentaire, mais contribuez quotidiennement ou de façon très régulière.

Je suis ingénieur système depuis plus de 10 ans maintenant et je travaille presque exclusivement avec des systèmes GNU/Linux. Je suis aussi profondément impliqué dans la communauté des logiciels libres et open source (FOSS) depuis longtemps et je passe beaucoup de temps sur les réseaux sociaux (surtout Twitter et Mastodon ces jours-ci). Et certains comportements m’énervent toujours autant.

Le consommateur se croit plus intelligent et plus efficace que les autres

De nombreux professionnels de l’informatique qui utilisent les logiciels libres affichent un comportement de pure consommation dans leur relation avec les logiciels libres. Par exemple ils essaient souvent d’utiliser un logiciel dans un environnement très spécifique (version spécifique d’une distribution GNU/Linux, version spécifique d’un logiciel). Ils ne réussissent pas à l’utiliser dans cet environnement ? Ce logiciel est évidemment de la merde, il devrait fonctionner avec les paramètres par défaut, sinon il n’est pas convivial. La documentation est disponible ? Qui lit le doc ? J’ai besoin de réponses maintenant, je n’ai pas le temps de lire la documentation ! Et qui a écrit cette merde d’ailleurs ?

Si la réponse n’est pas le premier lien StackOverFlow de la première recherche Google, je laisse tomber cette merde. Mon temps est précieux donc je vais essayer un autre logiciel (et perdre 2 fois plus de temps) ou mieux le coder moi-même (100 fois plus de perte de temps) et de telle manière qu’il sera impossible de le réutiliser bien sûr.

Les consommateurs passifs n’envoient jamais un rapport de bogue. C’est une perte de temps, qui réclame des efforts. Qui a le temps de l’écrire sauf les pigeons ? Pas même un ping au mainteneur ou au développeur principal du projet (ils devraient savoir, ils ont écrit cette merde !) Ok, je l’ai appelé sur Twitter il y a 2 minutes. Les gens ne répondent pas en une minute ? Allez vous faire foutre, bande de losers juste bons à perdre votre temps ! Je m’en tape qu’il soit 2h du matin pour lui.

Ok, ok, ok, c’est bon, je vais écrire un rapport de bug si les ouin-ouins insistent : ÇA MARCHE PAS BOUGEZ-VOUS LE CUL BANDE DE CONNARDS, CORRIGEZ ÇA MAINTENANT !

Faire un don au développeur ou à la développeuse ? Pour quoi faire ?

Même avec des logiciels qu’ils aiment et utilisent tous les jours et qui fonctionnent parfaitement, avec des mises à jour régulières parfaites, la plupart des professionnels de l’informatique ont exactement ce même comportement de consommation passive.

Ça fait 5 ans que ce logiciel alimente toute l’informatique, ce qui aide l’entreprise à gagner beaucoup d’argent ? Tout à fait. Le développeur principal demande de l’argent / de la reconnaissance par le biais des réseaux sociaux ? Sale clodo ! Il a besoin d’argent ? Moi aussi ! Cette personne a-t-elle un Patreon ? On s’en fout ! Ce type me doit d’utiliser son logiciel, il me casse les pieds, il adore coder gratuitement de toute façon ce pigeon.

L’aider en achetant une licence professionnelle pour ce logiciel ? MDR pour quoi faire ? Mon patron va se marrer en entendant ça. Personne ne paie pour les logiciels (sauf les pigeons). C’est gratuit, comme dans bière gratuite bébé !

Je vais même lui demander de modifier la licence parce que je ne peux pas utiliser ce logiciel (qu’il maintient gratuitement le con) dans ma propre suite logicielle propriétaire. Il devrait me remercier de l’aider à développer son logiciel, ce futur Marc Zuckerberg. Je suis presque sûr qu’il a gagné masse de thunes de toute façon. Il en aura pas par moi, pas question.

Et bien sûr, ce comportement de consommation passive a des impacts négatifs sur l’écosystème des logiciels libres. Vraiment. Habituellement, après quelques années, le développeur principal abandonne le projet. À ce moment-là, vous pouvez généralement lire ce genre de commentaires furieux sur son blog ou dans les rapports de bug « Espèce de branleur t’as plus mis à jour ton logiciel depuis des années, feignant va, des gens sérieux l’utilisent, réponds ou je laisse des milliers de commentaires insultants ! J’ai tout misé sur ton code, tu devrais me remercier à genoux. Espèce de communiste branleur, j’enlèverais mon étoile sur ton repo Gihub/Gitlab si je l’avais mis en vedette. Mais bien sûr que non, je ne vais pas mettre en vedette tous les projets que j’utilise, qu’est-ce que tu crois ? Contribuer d’une façon ou d’une autre ? Allez, faut grandir un peu, et faire avec. La vie est dure. »

Promouvoir les projets que vous utilisez et interagir avec eux

Afin de ne pas ressembler aux tristes personnages décrits plus haut, merci d’aider les projets que vous utilisez. Si votre entreprise gagne de l’argent grâce aux FOSS et que vous êtes chef d’entreprise, financer ou bloquer du temps pour que vos développeurs donnent un coup de main pour au moins un projet que vous utilisez quotidiennement semble un objectif raisonnable et démontre une certaine compréhension de l’écosystème FOSS.

Si vous êtes un employé d’une entreprise utilisant des FOSS, une étape très importante est de faire savoir à votre chef ou votre patron que des parties de votre infrastructure mourront à court terme (quelques années) si vous n’aidez pas ce projet de quelque façon que ce soit.

99,9 % des projets FOSS sont des projets maintenus par une seule personne. Cette petite bibliothèque JavaScript que le frontend du site web de votre entreprise utilise ou ce petit script de sauvegarde de base de données dont tout le monde se fout mais qui vous a déjà sauvé la vie 2 fois.

Si l’argent n’entre pas en jeu dans votre utilisation des FOSS et si vous fournissez un service gratuit à d’autres personnes, faites savoir aussi largement que possible que vous utilisez des FOSS et n’hésitez pas à remercier certains projets de temps en temps. Le simple fait de dire aux personnes par le biais de Mastodon ou Twitter que vous utilisez leurs logiciels peut leur remonter sacrément le moral. Mettez en vedette leurs projets sur Gitlab ou Github pour leur faire savoir (ainsi qu’aux autres) que ce projet est utile.

Quelques manières de contribuer

Voici une liste d’excellents moyens de contribuer :

• Faites savoir aussi largement que possible via les réseaux sociaux que votre dernière mise à jour de tel ou tel logiciel s’est déroulée sans problèmes. Faites passer le mot autour de vous.
• Rédigez un billet de blog décrivant vos expériences et la valeur ajoutée que ce grand projet FOSS a apportée à votre entreprise ou à vos projets. Suivez les développeurs principaux de différents projets sur Mastodon ou Twitter et retweetez/likez/pouétez… leurs dernières nouvelles de temps en temps.
• Écrivez un commentaire de remerciement sur le blog du projet ou sur le blog du développeur principal. La lecture de votre commentaire sera un rayon de soleil dans la journée du développeur de ce projet.

Ne soyez plus un consommateur passif

Ne soyez plus un consommateur passif de logiciels libres et open source. Le niveau moyen nécessaire pour contribuer à un projet et les attentes des créateurs de logiciels libres et open source augmentent de jour en jour dans un monde où la complexité et les interactions s’accroissent rapidement. Il n’y a souvent qu’une toute petite équipe (d’une seule à 5 personnes) qui est au cœur du développement fondamental des FOSS.

Contribuez de n’importe quelle manière décrite dans cet article, même la plus élémentaire, mais contribuez quotidiennement ou de façon très régulière. Vous aurez ainsi une participation concrète et fournirez de bonnes vibrations et d’excellents apports aux projets FOSS. Vos contributions changeront vraiment les choses, encourageront et (re)motiveront les personnes impliquées. C’est bon pour vous, vous allez améliorer vos compétences, acquérir des connaissances sur la communauté FOSS et de la visibilité pour votre entreprise ou vos projets. Et c’est une bonne chose pour la communauté FOSS que d’avoir de plus en plus de personnes qui contribuent par n’importe quelle action positive.

À propos de l’auteur

Carl Chenet, passionné de logiciels libres, auteur du Courrier du hacker, la lettre d’information hebdomadaire résumant l’actualité francophone du Logiciel Libre et Open Source

Après Pyg et aKa nous avons décidé d’entreprendre une troisième embauche en cette rentrée pour faire face à la croissance continue de notre réseau.

Pour illustrer l’état actuel de Framasoft, une image parfois vaut mieux qu’un long discours.

Nous sommes fiers de ce résultat, parce que derrière ces chiffres se cache la réalité de notre action de promotion et diffusion du Libre. Mais le revers de la médaille c’est que le support, la maintenance technique et les tâches administratives sont devenus de plus en plus lourds à gérer. Tant et si bien que les bénévoles et les salariés doivent s’y employer au quotidien, trop souvent au détriment de la pérennisation et du développement de nos projets.

Ainsi par exemple, le secteur de nos libres services en lignes (Framapad, Framadate, Framacalc…) est en pleine effervescence actuellement et connaît un succès qui nécessite un redoublement d’attention.

C’est avant tout pour cela que nous avons décidé d’accueillir un troisième permanent. Pour fluidifier les processus, résoudre un maximum de petits détails et faire ainsi en sorte que les autres se dégagent plus de temps pour mieux se consacrer à leurs missions sur les projets.

Bienvenue à Aymeric donc, plus connu chez nous sous le pseudo JosephK !

Nous espérons que sa venue se traduira rapidement par un impact visible sur l’amélioration de nos projets.

L’équipe Framasoft

Aujourd’hui, tout le monde a le cloud à la bouche. C’est vrai que ne rien installer et avoir un logiciel collaboratif à portée de main, c’est pratique… Mais nous sommes de plus en plus nombreux à nous inquiéter de savoir où passent nos données…. qui gère les serveurs… comment être autonomes… Le Framacloud est né avec Framapad, un service connu et utilisé par de nombreuses personnes. Aujourd’hui, Framadate connait aussi un grand succès comme alternative libre aux « doodles ». Mais il existe d’autres services qui n’attendent que votre utilisation, vos retours, votre participation.

Tous les projets Framasoft, qu’ils soient culturels, cloudesques, logiciels ou les trois, demandent des lignes de code… Bien sûr, les salariés ainsi que des bénévoles enrôlé-e-s de force dans l’association mettent les mains dans la source. Mais, encore une fois, l’apport de la communauté est essentiel. C’est pourquoi Framasoft a ouvert un dépôt GitHub. Afin que chacun-e puisse étudier, reproduire, modifier et diffuser du code que nous créons ensemble… Mais laissons Quentin nous le présenter.

— Pouhiou

Framablog : Dis-moi, c’est quoi un GitHub ? A quoi cela peut-il servir pour le développeur en herbe ? La codeuse volontaire ?

Quentin : Je ne vais pas m’embêter et je vais reprendre la définition de Wikipédia : GitHub est un service web d’hébergement et de gestion de développement de logiciels, utilisant le programme Git. En fait, c’est un site web où les développeurs du monde entier peuvent héberger le code source de leurs applications et ainsi le partager s’ils le veulent avec le reste du monde. Chaque membre de GitHub peut faire des propositions pour de nouvelles fonctionnalités, ouvrir des bogues, les corriger et les soumettre au projet initial. Il peut également copier le projet pour travailler sur une copie de celui-ci. On appelle cela un « fork ».

Pour le développeur en herbe ou la codeuse volontaire, cela permet de lire du code écrit par d’autres, de pouvoir le modifier et ensuite, d’en faire part à l’équipe qui développe le projet. Celle-ci peut alors commenter ce qu’a fait ce nouveau développeur et lui dire ce qui est bien et ce qui n’est pas bon dans son code. C’est ainsi que l’on apprend… C’est également comme cela que se créé une communauté autour d’un logiciel, que ce dernier s’enrichit et devient de plus en plus stable. Toutes les contributions sont bénéfiques !

Mais un code, c’est pas un peu personnel ? Je veux dire, c’est facile de mettre le nez dans un projet développé par quelqu’un d’autre ?

Ce n’est pas toujours facile en effet de se plonger dans le code de quelqu’un d’autre, surtout s’il est mal documenté, comprend trop peu de commentaires… il ne faut donc pas hésiter à poser des questions, ni craindre de commettre des erreurs ! Les développeurs sont aussi là pour expliquer le fonctionnement de leur logiciel.

Chez Framasoft, le code n’a rien de personnel puisqu’il est développé soit par les bénévoles, soit par les salariés de Framasoft, il est donc normal qu’il soit mis à la disposition de tous.

Framablog : Du coup quelle est la meilleure méthode pour participer à l’amélioration d’un projet Frama présent sur GitHub ?

Il y a plusieurs façons de participer à un projet Frama, je vais aller de la plus basique (mais non la moins importante) à la plus complexe :

1. Dire merci. Oui, c’est tout bête, mais quand on utilise un logiciel libre qui nous plaît, il est très facile d’écrire un petit courriel pour dire merci. Ça ne coûte rien, ça fait plaisir à entendre et ça motive encore plus…
2. Remonter des bogues : c’est également quelque chose de simple, mais ce n’est pas souvent fait. Lorsque vous apercevez un problème sur l’une des applications Framasoft, n’hésitez pas à ouvrir un bogue (rubrique “Issues”) dans GitHub (si vous avez un compte sur ce site) ou tout simplement à nous contacter par courriel pour nous faire de votre problème
3. Proposer des améliorations : vous avez une idée pour améliorer les applications Framasoft, alors proposez-la (de la même façon qu’au point 2). Pour cela, il faut être un petit peu développeur c’est vrai, mais vous pouvez nous aider en corrigeant les bogues, en apportant votre savoir-faire sur tel ou tel langage, en codant une nouvelle fonctionnalités… Il vous suffit de « forker » les projets Framasoft présents sur GitHub, modifier le code et faire ce que l’on appelle un Pull request :  il s’agit une demande d’intégration du nouveau code soumis par le développeur dans l’application.

En conclusion, il n’y a pas de meilleure méthode pour participer, elles sont toutes intéressantes et permettent d’améliorer les applications.

Framablog : Quels sont les projets Frama disponibles sur notre dépôt Github ? Il y en a d’autres qui vont s’y loger bientôt ?

Donc sur GitHub, Framasoft est représentée par l’équipe Framasoft : si vous ouvrez le lien, vous voyez toutes les applications dont le code source est partagé avec la communauté.

On y trouve a par exemple le code source de Framapad ainsi que celui de Framadate.

…mais aussi d’autres projets qui sont principalement utilisés en interne dans l’association comme Gesdon qui comme son nom l’indique, nous permet de gérer les dons et l’envoi des reçus fiscaux. Pour le moment, il n’y a que quelques applications dont nous partageons le code source. Nous souhaitons bien sûr partager le maximum, mais le manque de temps ne nous a pas encore permis d’organiser et d’ajouter le code source d’autres applications.

Vous en voulez encore ? Découvrez aussi celles-ci :

Framacalc : Framacalc est à Framapad ce que Calc est à Writer. Il s’agit donc d’un tableur en ligne collaboratif. Même s’il est pour l’instant moins complet que Framapad, Framacalc est tout à fait fonctionnel et vous permettra de travailler à plusieurs et en temps réel sur une feuille de calcul.

Framindmap : Besoin de faire un brainstorming ? Framamind est l’outil qu’il vous faut. Avec sa prise en main intuitive, il vous permettra de structurer vos réflexions pour en faire une superbe carte heuristique. Choisissez les positions de vos idées, les couleurs, et repartez avec vos idées mises au clair, sous forme d’image ou de fichier exportable, que vous pourrez toujours importer plus tard, pour le modifier et le compléter.

Gégé (rien que pour le lulz) : S’il y a un outil du Framaverse qu’on a fait en se disant : « ce pourrait être un délire sympa de le faire », c’est bien celui-ci. L’idée est venue est voyant une démo sur le site de Mozilla (). Et si on faisait pareil avec les personnages de Gee ? Il a suffit de quelques personnalisations du CSS par Bouts et Gégé, le Générateur de Geektionerd, était né. L’outil, simple d’utilisation permet de créer simplement, sans talent de dessinateur, ses BD de Geektionerd en proposant des jeux de mots tellement pourris que même Gee n’aurait pas pu les écrire.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framablog : Sphinx, purplepsycho, Cyrille L., lamessen

Ce que je suis contente de ne pas avoir su

Alexandra Leisse

Alexendra Leisse a quitté une scène pour en rejoindre une autre. Elle a transformé son autre passion (les logiciels et le Web) en un métier. Après une période de transition de douze mois en freelance dans le logiciel et l’opéra — et noyée par de nombreuses heures d’activités dédiées à KDE, elle a rejoint Nokia et le développement de la plateforme Qt en tant que gestionnaire de la communauté Web. C’est la femme derrière le réseau de développement Qt et les activités de sa communauté sur la toile. Bien qu’elle soit diplômée en art lyrique, elle refuse la plupart du temps de chanter en public.

Introduction

Quand Lydia m’a demandé de rejoindre son projet de livre sous-titré « les choses que j’aurais voulu savoir », mon esprit est resté vide. Les choses que j’aurais voulu savoir mais que je ne savais pas ? Rien ne me venait à l’esprit.

Je ne dis pas que je n’aie pas eu besoin de savoir quoi que ce soit, au contraire. J’ai eu beaucoup à apprendre et j’ai fait un nombre incalculable d’erreurs. Mais les situations ou les erreurs que j’aurais voulu éviter ? Je n’arrive pas à y penser.

Nous avons tous cette fâcheuse tendance à regarder les choses que nous pourrions mieux faire, les choses que nous ne savons pas, et nous les voyons comme des faiblesses. Mais que dire des faiblesses qui sont des atouts ?

Voici ma propre histoire sur l’ignorance, la naïveté, les mauvaises impressions et comme je suis heureuse de ne pas en avoir eu la moindre idée.

Les noms

Je n’avais aucune idée de qui était ce gars que j’avais rencontré lors de mon premier jour de travail. Il est entré dans la pièce, s’est présenté et a commencé à poser des questions me donnant l’impression que tout ce que je penserais serait insensé. Il était apparemment bien renseigné sur ce que je faisais sur KDE et les personnes que je côtoyais. Cependant, nos points de vue sur le sujet semblaient différents. À un moment, ses provocations ont fini par me fatiguer et j’ai perdu patience. Je lui ai alors dit qu’avec les personnes, ce n’était pas toujours aussi facile que les ingénieurs l’imaginent.

Juste après son départ après une heure de discussion, j’ai cherché son nom sur Google : Matthias Ettrich. Ce que j’ai lu m’a expliqué pourquoi il avait posé ces questions. Si j’avais su avant qu’il était un des fondateurs du projet KDE, j’aurais débattu avec lui d’une manière bien différente, voire pas du tout.

Ces dernières années, j’ai dû chercher quelques noms et à chaque fois, j’ai été heureuse de le faire après le premier contact.

C’est probablement mon idée la plus importante. Lorsque j’ai rencontré toutes ces personnalités du Libre et de l’open source pour la première fois, je n’avais jamais entendu leurs noms auparavant. Je ne savais rien de leurs histoires, mérites ou échecs. J’ai approché tout le monde de la même façon : le contact visuel. En étant ignorante (ou naïve selon certains), je ne me sentais pas inférieure par rapport aux personnes que je rencontrais lorsque j’ai commencé mon aventure au sein du Libre et de l’open source. Je savais que j’avais beaucoup à apprendre mais je n’ai jamais eu l’impression d’avoir un rang inférieur aux autres en tant qu’individu.

« Projet de grande envergure »

Je n’avais pas suivi religieusement dot.kde.org ni PlanetKDE et encore moins ces innombrables publications liées au Libre et à l’open source, avant de commencer à m’intéresser à ce qui se passait sur les listes de diffusion KDE. Je voyais ces canaux avant tout comme moyen de communiquer avec un public choisi, principalement des utilisateurs et des contributeurs du projet en tant que tel.

Pendant un certain temps, je n’avais pas conscience que les articles que je publiais sur The Dot pourraient être repris par des journalistes. Je m’appliquais à les écrire parce que je voulais faire du bon boulot et non pas parce que j’avais peur de passer pour folle auprès du reste du monde. La liste de presse était maintenue par d’autres personnes et ce que j’écrivais ne me paraissait pas important non plus. Je voulais toucher certaines personnes. Pour cela les canaux officiels et mon propre blog me semblaient être les moyens les plus efficaces.

Être citée sur ReadWriteWeb après avoir annoncé sur mon blog que je commencerai un nouveau boulot fut un choc pour moi. Non pas parce que j’ignorais que des gens lisaient ce que j’écrivais (j’espérais bien qu’ils le lisent !) mais je ne m’attendais pas à ce que ça soit un sujet d’une telle importance. Ce n’était même pas pendant les vacances d’été. Encore heureux que personne ne me l’ait dit, je n’aurais pas été capable de publier ne serait-ce qu’une seule ligne.

L’œil étranger

Il y a quelque temps, quand j’ai assisté à ma première conférence, j’avais la ferme conviction que j’étais différente des autres participants. je me voyais comme une étrangère parce que je n’avais pas grand-chose en commun avec qui que ce soit à part un vague intérêt pour la technologie : je travaillais en freelance depuis quelques années déjà, après mon diplôme universitaire ; je n’avais aucune éducation pertinente dans le domaine, et j’étais mère d’un enfant de 10 ans. Sur le papier en tout cas, il ne pouvait pas y avoir plus éloignée des suspects habituels qu’on rencontre dans les projets FOSS.

En 2008 j’ai assisté à un sprint (NdT : phase de développement, généralement perçue comme intense, aboutissant à un produit fonctionnel) KOffice au sein de l’équipe promotion et marketing de KDE pour préparer la sortie de la version 2.0. L’idée initiale était d’esquisser une série d’activités promotionnelles autour de cette sortie afin de développer à la fois le support développeur et utilisateur. Pour celui-ci, nous étions trois à suivre un chemin parallèle à celui concernant les développeurs.

Nous avons essayé de comprendre comment nous pourrions positionner KOffice et adapter la communication au public ciblé. Très tôt dans le processus, nous avons découvert que nous devions faire marche arrière : à ce stade, le manque de maturité de la suite rendait impossible son positionnement comme option pour les utilisateurs non avertis. Nous devions nous en tenir aux développeurs et aux précurseurs. C’était difficile à vendre à certains développeurs, mais en tant qu’étrangers nous avions la chance de regarder le logiciel sans penser à tout le sang, la sueur et les larmes versés dans le code.

Pour beaucoup de projets, de n’importe quelle sorte, jeter un œil objectif à la situation donne du fil à retordre aux contributeurs principaux. Nous avons tendance à ne pas voir les grands succès quand nous sommes très concentrés sur des problèmes de détails et réciproquement. Parfois, nous manquons une occasion parce que nous pensons que ça n’a rien à voir avec ce que nous faisons (ou, pour commencer, parce que personne ne voudrait que ça ait quelque chose à voir).

Dans tous ces cas, les contributeurs extérieurs au projet ont le potentiel pour apporter des points de vue différents à la discussion, particulièrement quand il s’agit de déterminer un ordre de priorité. C’est encore plus utile quand ce ne sont pas des développeurs : ils poseront différentes questions, sans ressentir de pression face à la connaissance et à la compréhension de tous les détails techniques ; ils peuvent aussi aider pour les décisions ou la communication sur un plan moins technique.

Conclusion

L’ignorance est une bénédiction. Ce n’est pas seulement vrai pour les individus qui profitent de l’insouciance qui en résulte mais aussi pour les projets que ces individus rejoignent. Ils apportent différents points de vues et expériences.

Et maintenant, filez et trouvez vous-même un projet qui vous intéresse, indépendamment de ce que vous pensez savoir.