Je pourrais dire en exagérant à peine que n’importe qui peut contribuer au logiciel libre…
Bon… c’est vrai et un peu exagéré, mais pas tant que ça.
C’est un peu exagéré pour les raisons suivantes qui sont des sortes de prérequis (c’est mon avis personnel) :
- avoir compris ce que sont les logiciels libres (ses « 4 libertés » et ses vertus, versus les logiciels propriétaires)
- être bienveillant
- avoir un esprit d’équipe
- voir l’intérêt commun et non pas juste votre propre intérêt
Oui, même si cela semble être ridicule pour une partie de la population (mépris) :
- Vivre (correctement) du logiciel libre est possible
- Le logiciel libre n’est pas une utopie, mais quelque chose qui existe, qui marche et qui, même si je n’aime pas dire cela, car ce n’est pas le but, représente une solide manne financière en France, en Europe et dans le reste du monde (en constante progression)
- Développer des logiciels en plaçant l’Humain au centre des projets est possible, n’empêche pas d’en vivre et de générer des profits
- Les Humains, qui sont placés au centre des projets… sont tous ces vrais gens : Les utilisateurs, les développeurs et toutes autres personnes qui se trouvent derrière… et que l’on appelle, au sens large, une communauté.
J’en profite pour vous conseiller de visionner le documentaire suivant :
Autres prérequis d’importance (un peu cruels, mais souvent inévitables) :
Comme lu dans beaucoup d’annonces d’emploi … « Anglais apprécié » : Et oui, c’est peut-être là un frein qui risque de calmer beaucoup de monde… l’anglais est souvent nécessaire dans la contribution au logiciel libre ; ce n’est pas le cas à 100 %, mais très courant, car les projets de logiciels libres, sont par principe ouvert à tous, donc bien au-delà de nos frontières, bien au-delà de la francophonie.
Par conséquent, l’anglais est souvent, très souvent incontournable. Cela dit, je vous rassure, si votre niveau en anglais est scolaire, cela peu suffire :
- L’anglais utilisé n’est pas littéraire et ainsi plutôt basique… et puis le « jargon » technique, il se comprend, et s’apprend presque sans peine.
- On ne vous jugera pas que la qualité de votre anglais ; il suffit que vous vous fassiez comprendre (et puis par écrit, si vous avez un « accent de merde », ça ne se voit pas !)
- Les outils de traduction automatique en ligne peuvent bien vous aider (Excellente alternative à Google Translate : https://www.deepl.com/fr/translator)
Important à savoir :
Quelles sont les différentes manières de contribuer ?
Note : Vous verrez pour chaque type de contribution un tableau évaluant les facteurs budget, temps et difficulté technique. Il s’agit d’estimations « au doigt mouillé » pour comprendre ce que cela peut exiger.
💰 Dons
Budget | 🔴 ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 🔴 🔴 🔴 |
Temps | 🔴 ⚪ ⚪ ⚪ ⚪ |
Technique | ⚪ ⚪ ⚪ ⚪ ⚪ |
Faire un don est très accessible. Lorsque vous faites un don, vous en choisissez le montant. Les dons, selon à qui vous le faites et depuis où, peuvent être réalisés ponctuellement (one-time) ou mensuellement (monthly). Hormis le fait que la plateforme peut être en anglais, et donc que vous ayez quelques bases en anglais, vous n’avez qu’à saisir votre numéro de carte bancaire et à choisir la formule et le montant.
Quand vous faites un don, ce n’est pas un don à des « geeks nécessiteux marginaux qui bricolent dans leur caverne » ; ces dons soutiennent de :
- de « vrais projets de développement », petits ou grands, pilotés par des personnes morales ou physiques
- des associations / fondation qui soutiennent elles-mêmes le logiciel libre de manière générale (tout l’écosystème) ou ciblée (certains projets en particulier)
Les dons participent par exemple aux frais :
- d’hébergement (serveurs)
- d’équipement informatique
- de logistique
- de communication
- etc
Au-delà du simple aspect pécuniaire du don, si on est en mesure de le faire, c’est une manière de d’encourager le développement du projet, actuel et futur.
Quelques pages de donation parmi de très très nombreuses existantes sur internet :
- Distribution GNU/Linux appelée « Linux Mint » : https://www.linuxmint.com/donors.php
- Tibor Kaputa en Slovaquie, développeur d’applications sous licence libre pour smartphone Android : https://github.com/sponsors/tibbi
- Association APRIL (association de promotion du logiciel libre dans la francophonie) : https://www.april.org/association/dons.html
- Page de donation de la suite bureautique LibreOffice : https://fr.libreoffice.org/donate/
- Environnement de bureau KDE : https://kde.org/fr/community/donations/
- Logiciel de retouche graphique GIMP : https://www.gimp.org/donating/
- Free Software Foundation (FSF) : https://www.fsf.org/about/ways-to-donate
- Fondation Mozilla : https://donate.mozilla.org/fr/
👥 Milieu associatif
Budget | 🔴 ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 ⚪ ⚪ ⚪ |
Temps | 🔴 ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 🔴 ⚪ ⚪ * |
Technique | ⚪ ⚪ ⚪ ⚪ ⚪ |
Adhérer à une association axée sur le logiciel libre est un excellent moyen de mieux comprendre le logiciel libre en général, et la notion de communauté. Les associations d’utilisateurs de logiciel libres ou de promotion des logiciels libres (les deux notions se conjuguent en général) vous permettront de monter en compétence, de vous imprégner de la culture du logiciel libre, et de devenir vous-même acteur du logiciel libre en prenant part active dans la vie de l’association qui œuvre pour le logiciel libre (en faisant sa promotion de différentes manières, sans oublier l’opportunité d’intégrer son bureau si l’occasion se présente). Le montant de la cotisation est généralement abordable.
Il y a plusieurs types d’association :
- Déjà cité : Les associations de promotion du logiciel libre, comme, parmi les plus connues en France, l’APRIL et La Mouette
- Les groupes d’utilisateurs de logiciels libres (GULL) ; voir la liste des GULL, en France et au-delà.
- Les réseaux d’éducation populaire, dont certains militent beaucoup en faveur du logiciel libre, comme Framasoft
- Les « fablab » dont certains sont très orientés vers l’usage des logiciels libres
Signalement de bugs 🐞 et suggestions d’améliorations ergonomiques 🎨 (UX/UI)
Budget | ⚪ ⚪ ⚪ ⚪ ⚪ |
Temps | 🔴 🔴 🔴 ⚪ ⚪ |
Technique | 🔴 🔴 🔴 ⚪ ⚪ |
1. Trouver le projet
Pour signaler un bug, cela se fait en se connectant à la forge logicielle qui héberge le projet. GitHub et GitLab sont les plus connues. Il vous faudra dans tous les cas vous y créer un compte. Mais avant, il est nécessaire de savoir sur quelle forge logicielle se trouve le projet (le logiciel) auquel vous souhaitez contribuer en signalant le(s) bug(s) que vous avez recensés. Pour trouver le projet (et donc savoir sur quelle forge logicielle, vous devrez aller), vous pouvez le faire de plusieurs manières :
- En allant sur le site internet officiel du logiciel (site internet créé et maintenu, selon le projet, par une communauté de bénévoles, une association, une entreprise …) et en cliquant un lien arboré d’une icône GitHub ou GitLab … vous serez redirigé vers le dépôt du logiciel.
- En effectuant une recherche dans un moteur de recherche (sur Google, ou, mieux bien sûr, un moteur alternatif comme Qwant ou DuckDuckGo …). Exemple en tapant « GitHub Nextcloud Server », ou « GitHub Nextcloud Calendar » ou « GitLab Fdroid » … et si cela ne donnait rien, essayez en remplaçant « GitHub » par « GitLab » ou l’inverse.
- En effectuant une recherche au sein de GitHub et GitLab
2. Se connecter à la forge qui héberge le projet
Ensuite, connectez-vous à la plateforme (avec votre compte existant ou en créant un nouveau) et, sur la page du projet, cherchez la liste des « Issues ». Ce mot anglais signifie « Problème ». Une fois la liste de toutes les issues du projet trouvée, il vous suffit d’en créer une nouvelle (oui… je mets les « issues » au féminin, mais je ne sais pas si c’est pertinent) en cliquant sur le bouton « New issue ».
3. Bug ou fonctionnalité ?
Ensuite, vous devrez sélectionner le type d’issue, s’il en existe plusieurs (cela dépend du projet). On trouve par exemple pour Nextcloud Server : « Bug report » et « Feature ». « Bug report », qui nous intéresse ici, vous permettra de signaler un bug présumé ; « Feature » sera évoqué dans « Suggestions d’amélioration », juste après.
4. Code de conduite
Il ne suffit pas de dire « ça ne fonctionne pas (ou mal) » … et grosso modo « démerdez-vous » … car cela n’a aucune chance d’aboutir.
Déjà que sur une plateforme de support client de logiciel propriétaire, vous auriez peu de chance d’arriver à vos fins comme cela…, et bien là, pour un logiciel libre, il vous faudra un miracle pour être entendu de cette manière.
Quand on fait remonter un bug de logiciel libre, on doit « jouer le jeu du logiciel libre » et considérer cette action comme une contribution, qui rend service :
- aux développeurs
- aux autres utilisateurs
- à vous bien sûr aussi, mais avec une volonté de rendre service « à tous »
Lorsque vous souhaitez signaler un bug ou demander une amélioration, il faut vous impliquer.
Non, en face, ce ne sont pas des hippies, mais de réels développeurs (salariés ou bénévoles), qui méritent respect et bienveillance, comme tout un chacun.
Pour résumer : Il est indispensable d’avoir le bon état d’esprit en mettant les pieds ici.
Vous ne faites pas juste que « signaler un bug ». Vous faites bien plus que cela. Vous collaborez et rendez-service à tout le monde (les autres utilisateurs, les développeurs et vous), et faites partie d’un tout, d’un ensemble de gens qui collaborent « en bonne intelligence ».
Aucun contrat ne vous lie… vous n’êtes pas un donneur d’ordre (ni de leçon) et le(s) développeur(s) qui vous répondront, ne sont ni des « vos exécutants », ni vos supérieurs (bien que soit eux qui ont un pouvoir de décision, de prise en compte de vos demandes et signalement).
Tout le monde est sur un même pied d’égalité et doit respecter son interlocuteur.
5. Chasse aux doublons
Au préalable, vous devez vous assurer, qu’une issue évoquant le même bug n’existe pas déjà en menant quelques recherches. Si vous ne trouvez rien, cela ne veut pas dire qu’il n’y en a pas. Ce n’est pas toujours évident de trouver une issue parmi des centaines ou des milliers, ce qui arrive avec les gros projets. Si jamais, c’était le cas, il est probable que votre « issue » soit déclarée comme doublon d’une autre issue déjà créée auparavant. Elle sera dans ce cas fermé et mentionnée comme doublon de l’issue n°XXXX.
Deux intérêts à la recherche d’une issue déjà existante :
- Cela vous évitera tout ou partie du travail qui est décrit après
- Cela simplifia la tâche des développeurs
6. Fourniture d’informations de qualité
Ainsi, pour signaler le bug, il va falloir vous impliquer en fournissant des informations (en anglais), qui sont le plus souvent (dépendant du modèle de saisie imposé par champs titrés) :
- Description détaillée du bug et du contexte dans lequel il se produit et la description du problème que cela engendre ; vous allez donc aussi décrire ce qui fait que c’est un bug selon vous.
- Les étapes pas-à-pas pour reproduire le bug afin que les développeurs puissent, eux aussi, le reproduire sur leur ordinateur.
- Description du comportement attendu si le bug n’existait pas
- Détails de votre configuration
- Logs (journaux d’erreur) ; si vous ne savez pas les fournir et que vous ne les fournissez pas… et que l’on vous les demande malgré tout, une procédure vous sera éventuellement transmise pour y parvenir.
Une fois cette première étape franchie, il va falloir attendre que votre « issue » soit prise en compte.
Quelques conseils pour la rédaction de votre issue et son avenir (si celle-ci n’est pas prise en compte dans le délai que vous espériez) :
- Ne pas relancer (inutile)
- Ne pas mentionner des développeurs en tapant par exemple « @Jean_Dupont » comme cela se fait sur des réseaux sociaux. Si un contexte particulier le justifie, vous pouvez le faire à titre exceptionnel, mais ne harcelez pas les gens pour espérer passer par-dessus la pile, vous risqueriez même de provoquer l’inverse (car « pinger » à tout va, peu être perçu comme du harcèlement). Souvenez-vous de l’égalité évoquée entre tous les membres de la communauté (dont vous faites partie en vous impliquant), et entre les développeurs et vous. Si tout le monde commençait à vouloir passer avant ou par-dessus les autres, cela deviendrait rapidement le « bordel », à tous les niveaux, techniquement et humainement.
- N’hésitez pas à fournir une ou plusieurs captures d’écran qui ne pourront que rendre plus claires encore vos explications (et motiveront donc les personnes en face à considérer votre issue comme vous l’attendez). Dans ces captures d’écrans :
- n’hésitez pas à ajouter des encadrés, des flèches, etc … pour que tout soit le plus explicite possible
- floutez ou masquez toutes données personnelles
- Au risque de me répéter, rédigez votre issue avec le plus de soin possible, en gardant à l’esprit cette volonté de rendre service à tous, et bien sûr à vous. Une issue n’est pas une patate chaude ou malodorante qu’on balance aux développeurs.
- Au risque de me répéter une fois de plus, soyez courtois (c’est la base)
- Lorsque l’on vous répond, gardez la même implication tout au long de l’échange afin d’aboutir à quelque chose, dans les meilleures conditions
7. Le devenir de votre issue (principaux scénarios) :
- Elle peut directement susciter l’attention d’un ou plusieurs développeurs en fonction de son niveau de criticité, du travail qu’elle représente (quantité et complexité), de sa pertinence, etc. et/ou bénéficier du soutien d’autres utilisateurs (confirmation et apport d’informations supplémentaires selon les retours d’expérience des uns et des autres) ce qui lui donnera du poids et de la visibilité. Cela peut prendre des jours, des semaines, mois… avant d’attirer l’attention et déboucher sur une « Pull Request » (*) (**)
- Elle peut aussi « tomber dans l’oubli ». En fait, elle ne tombe pas vraiment ou officiellement dans l’oubli, mais, si le projet compte des centaines, voire des milliers d’issues et que la vôtre :
– n’est pas jugée assez claire
– n’est pas jugée assez détaillée
– n’est pas jugée pertinente (ne représente pas un bénéfice réel et/ou suffisant pour tous)
– n’est pas reproductible (s’il s’agit d’un bug), généralement par manque d’infos
– n’est pas jugée prioritaire par rapport à d’autres issues ou d’autres développements en cours
– est jugée trop utopiste ou exigeante et remet en cause trop de choses…
Tous ces critères de jugement sont forcément un peu subjectifs, mais vous vous devez de faire confiance à la communauté de développeurs et à leur capacité à évaluer les choses en fonction du contexte. En d’autres termes, il s’agit d’admettre que vous n’avez pas de visibilité sur les développements en cours, les priorités, les moyens humains en cours, etc.
Ensuite, si elle n’est pas jugée assez ceci ou cela et que personne ne vous le dit, il ne faut pas vous formaliser, et puis encore une fois, vous n’êtes pas sur une plateforme de support client avec une quelconque obligation de moyen ou de résultat. Dites vous en tout cas, que, statistiquement, plus votre issue sera claire, détaillée, et réellement pertinente (même si cela reste hyper subjectif), plus elle aura de chance d’être considérée comme vous le souhaitez. Concernant la pertinence, plus votre demande sera dans l’intérêt général, plus elle sera jugée pertinente. - Elle peut être « fermée » par un développeur, car considérée comme un doublon d’une ou plusieurs autre(s) issue(s) déjà existante(s) (que vous n’aviez a priori pas trouvée avant de vous lancer)
- Elle peut être prise en compte par un développeur qui va développer le correctif ou l’amélioration (Pull Request). Il se peut dans certains cas qu’il sollicite un autre développeur susceptible d’être mieux qualifié pour cette tâche. Votre issue sera donc fermée lorsque la « Pull Request » (*) sera validée et prête à être embarquée dans la prochaine version du programme (« merged »). (**)
* Une « Pull Request » (oui, car je mets aussi les « Pull Request » au féminin et je ne sais pas si j’ai raison) consiste pour un développeur à proposer qu’une modification d’une partie du code d’un logiciel libre dont il est contributeur, le but étant qu’elle soit prise en compte (adoptée) dans la prochaine version du logiciel (après passage de toute une somme de contrôles dont certains sont parfois en partie automatisés).
** Lorsqu’une issue a attiré l’attention et suscite un intérêt qui devrait ainsi déboucher sur un développement correctif ou évolutif, un développeur va en principe la catégoriser avec des labels (tags). Par exemple :
🇫🇷 Traductions
La traduction est un axe de contribution stratégique pour plusieurs raisons ; elle :
- permet aux francophones, à commencer par ceux qui ne parlent pas anglais, d’utiliser le logiciel confortablement.
- contribue très largement à l’ergonomie du logiciel (UX)
Quels problèmes posent les traductions non faites ou mal faites ?
- Si les traductions ne sont pas faites ou si elles ne sont que partiellement, faites, cela donne la désagréable impression que le logiciel n’est pas fini et peut laisser imaginer qu’il est de mauvaise qualité. Je dirais même que « partiellement » est parfois pire que « pas du tout » car cela peut donner l’impression que l’application est buguée.
- Si les traductions, bien que toutes faites, sont mal faites, cela nuit à la qualité globale du logiciel, car elle nuit à sa facilité d’utilisation (en supposant que l’UX/UI a été soignée en amont). Cela nuit aussi à l’image du logiciel et, pire encore, peut nuire à tous les logiciels libres, car ce genre de situation est du pain bénit pour les détracteurs du logiciel libre (je vous laisse imaginer pourquoi).
Un logiciel bien traduit, ce sont des termes :
- non traduits automatiquement, ultra littéralement ou sans réflexion
- cohérents avec les fonctionnalités logicielles qu’ils concernent respectivement (contexte d’usage)
- entre eux (cohérence transversale)
- bien orthographiés (l’orthographe et la grammaire doivent être irréprochables, car c’est une des toutes premières choses qui sera vue par l’utilisateur) : Imaginez, en tant qu’utilisateur, un bouton d’action nommé : « Affichier le fichier », « Afficher le fichiers », « Aficher le fichier » … ça fait saigner les yeux, hein ?!
Quelques conseils pour bien traduire :
- Indispensable : Vous devez avoir un niveau suffisant en anglais, pas obligatoirement un niveau bilingue, mais suffisant tout de même pour savoir traduire correctement une interface et savoir reconnaitre et traduire le jargon en lien avec le logiciel. Si par exemple, vous souhaitez traduire un logiciel de traitement photo, mais que vous ne connaissez pas le jargon français et encore moins anglais de la photographie, ne vous lancez pas !
- Ne jamais traduire une application que vous n’avez jamais utilisée ou, encore pire, dont vous ne savez pas à quoi elle sert
- Toujours traduire dans un environnement propice à la concentration, avec du temps devant vous
- À moins que vous soyez parfaitement bilingue, n’ayez aucune honte à vous appuyer sur un traducteur automatique, mais, ATTENTION, uniquement pour une première passe de traduction. ENSUITE, vous devez contrôler la traduction et vous assurer que le contexte, la signification des mots et expression n’ont pas été déformés, et que cette traduction soit aussi cohérente avec d’autres traductions si nécessaire. Autrement dit, utiliser un traducteur en ligne ne vous dispense aucunement d’avoir un niveau suffisant en anglais pour être certain que ce que votre traduction est correcte en tout point (bien qu’une traduction donnée soit toujours sujette à interprétation subjective quant à sa pertinence).
💻 Développement
Budget | ⚪ ⚪ ⚪ ⚪ ⚪ |
Temps | 🔴 🔴 🔴 ⚪ ⚪ à 🔴 🔴 🔴 🔴 🔴 |
Technique | 🔴 🔴 🔴 🔴 ⚪ à 🔴 🔴 🔴 🔴 🔴 |
En fait, là, je n’ai rien à dire ici… pourquoi ? Parce que si vous faites déjà du développement, vous en saurez forcément plus que moi et je n’aurai rien à vous apprendre. Je pars aussi du principe que si vous faites du développement pour des projets de logiciels libres, tout ce que vous lirez dans cette page, vous le savez déjà. J’ai détaillé ci-dessus la partie dédiée aux signalements de bugs, car il est possible, dans ce cas, de ne pas avoir de compétences en développements (selon le type de bugs signalés).
📢 Promotion
Budget | 🔴 ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 🔴 ⚪ ⚪ * |
Temps | 🔴 🔴 ⚪ ⚪ ⚪ à 🔴 🔴 🔴 🔴 🔴 * |
Technique | ⚪ ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 ⚪ ⚪ ⚪ * |
Promouvoir le logiciel libre est également utile et contribue à sa crédibilité et, en d’autres termes, à sa raison de vivre.
Le simple fait de témoigner de sa propre expérience auprès de son entourage personnel et/ou professionnel relève de la « promotion » car cela a pour effet d’éclairer sur l’existence d’alternatives viables aux logiciels propriétaires, dont ceux des GAFAM.
Associations de promotion du logiciel libre
Vous pouvez aussi témoigner de votre expérience dans le cadre associatif qui s’adresse au grand public, ou à des entreprises et organisme publics à travers des réunions et divers événements. Deux associations bien connues en France pour leurs actions de promotion généraliste du logiciel libre sont l’APRIL et Framasoft. Autre exemple, l’association « La Mouette » est plus spécialisée, car elle fait la promotion des suites bureautiques libres et de leurs formats ouverts.
« GULL » (Groupes d’Utilisateurs Locaux de Linux » (et/ou de Logiciels Libres))
Dans ces associations, un type d’événement est assez courant au sein des : Les « install party ». Au cours ces événements, vous pouvez bénévolement aider les primo-accédants à GNU/Linux (qui vous rendent visite sur le lieu de l’événement) à installer le système d’exploitation GNU/Linux sur leurs ordinateurs et/ou à répondre à diverses questions qu’ils pourraient avoir au sujet des logiciels libres en général.
📝 Enrichissement des données et publication d’œuvres
Budget | ⚪ ⚪ ⚪ ⚪ ⚪ |
Temps | 🔴 ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 🔴 🔴 🔴 |
Technique | ⚪ ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 🔴 ⚪ ⚪ * |
Il y a les logiciels d’un côté et les données de l’autre.
Vous pouvez aussi contribuer en mettant à jour, créant, enrichissant des données publiées sous certaines licences. Quelques exemples ci-après.
OpenStreetMap :
Vous pouvez contribuer aux données cartographiques d’OpenStreetMap, l’alternative vertueuse à Google Maps. Les données d’OpenStreetMap sont publiées sous licence Open Data Commons Open Database License (ODbL). Voir aussi ma rubrique : Contribuer à OpenStreetMap : Une mission valorisante, utile et accessible à tous.
Œuvres culturelles :
Vous pouvez aussi publier des œuvres (écrits, photographies…) sous licence « Creative Commons » afin qu’elles profitent au plus grand nombre (intérêt général), de façon pérenne : Choose a License
https://fr.wikipedia.org/wiki/Creative_CommonsCreative Commons (CC) est une association à but non lucratif dont la finalité est de proposer une solution alternative légale aux personnes souhaitant libérer leurs œuvres des droits de propriété intellectuelle standard de leur pays, jugés trop restrictifs. L’organisation a créé plusieurs licences, connues sous le nom de licences Creative Commons. Ces licences, selon leur choix, ne protègent aucun ou seulement quelques droits relatifs aux œuvres. Le droit d’auteur (ou « copyright » dans les pays du Commonwealth et aux États-Unis) est plus restrictif.
Musique :
Pour les musiciens, plus d’informations sur cette page Wikipédia dédié à la musique libre.
Wikipédia :
Vous pouvez aussi contribuer à Wikipédia.
💼 Faire du logiciel libre son métier
Budget | ⚪ ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 🔴 🔴 🔴 * |
Temps | 🔴 🔴 🔴 ⚪ ⚪ à 🔴 🔴 🔴 🔴 🔴 ** |
Technique | ⚪ ⚪ ⚪ ⚪ ⚪ à 🔴 🔴 🔴 🔴 🔴 *** |
** Dépendant de si vous avez une vie après le travail 😉
*** Selon votre poste
Si le logiciel libre vous intéresse… je reformule… si la philosophie du logiciel libre vous intéresse par opposition au logiciel propriétaire, vous pouvez en faire votre métier ! Eh bien évidemment, faire du logiciel libre son métier, c’est contribuer à sa raison d’être, et à son avenir. Bien sûr, aussi, vous pouvez travailler dans le logiciel libre en tant que développeur, mais aussi en tant que chef de projet, commercial, technicien support, formateur, … L’écosystème recrute, donc profitez en !
AVERTISSEMENT
De grâce, si vous n’en avez que faire de la philosophie du logiciel libre, que le fait travailler dans ce secteur précis ne crée chez vous aucune « excitation », passez votre chemin.
Ce que j’écris ici peut paraître brutal et même sectaire, mais sachez que le logiciel libre n’a d’intérêt et d’avenir que s’il est porté par des gens qui ont vraiment compris (ou envie de comprendre) ce que c’est et qui ont vraiment envie de s’y investir, non pas par effet de mode (car on parle beaucoup de logiciels libres actuellement que ça ferait très « hype » sur votre CV), mais par conviction !
Un détail a priori anodin… et pourtant : Si vous travaillez ou projetez de travailler dans une société spécialisée dans les logiciels libres, mais que, par exemple, chez vous, vous n’utilisez que des logiciels propriétaires, dites-vous qu’il y a déjà un problème et que vous allez forcément finir par vous sentir en décalage avec le reste de l’équipe (et ce décalage finira bien aussi par se sentir en face).
Idem pour les futurs entrepreneurs : Si vous créez votre entreprise spécialisée dans les logiciels libres uniquement par recherche de profit et par opportunisme, et qu’aucune des vertus du logiciel libre ne vous anime, vous serez vite repérés… les libristes (les vrais), bien qu’étant super sympas, ne sont pas idiots ! (On n’écrit pas bon avec un « c« )
Donc, non, ce n’est pas du sectarisme, mais juste une histoire de cohérence et surtout un bon conseil de ma part !