Petite traduction pédagogique sans prétention illustrant la paralysie qui affecterait Internet si le logiciel libre n’était plus là, permettant par là-même au grand public de se rendre compte par la négative de son importance et de sa diffusion^[1].

En fait si le logiciel libre n’existait pas il faudrait l’inventer…

A Day Without Open Source

William Hurley – 9 mai 2007
(Traduction Framalang : HL et Don Rico)

J’étais à une conférence quand deux techniciens entrèrent dans la salle de bar, l’un favorable au logiciel libre, l’autre résolument contre. Ils mirent le moulin en route après quelques verres et Mr Contre remarqua d’une voix forte : « Le logiciel libre, je voudrais bien que ça dégage ! Ça crée plus de problèmes que ça n’a d’avantages.» Déclarations avec lesquelles, de toute évidence, j’ai quelques difficultés. Bon, je sais que la plupart des gens ne comprennent pas le rôle du logiciel libre dans notre monde, ou ignorent combien de services que nous tenons pour acquis disparaitraient sans sa présence. Si vous êtes membre du club, vous voyez probablement où je veux en venir.

Imaginons qu’au douzième coup de minuit, tout logiciel libre s’évapore comme par magie. Qu’est-ce qui fonctionnerait encore demain ? Pour commencer, Internet « disparaîtrait » pour l’utilisateur moyen. La plupart des serveurs de nom de domaines (DNS) fonctionnent sous des logiciels libres comme BIND, qui transforme www.framablog.org en une adresse IP du serveur adéquat. On perdrait en route la majorité des utilisateurs de base d’Internet. Bien sûr, BIND n’est pas le seul logiciel libre pour les DNS. Et toutes les solutions logicielles pour DNS ne sont pas libres.

Mais supposons que les DNS fonctionnent toujours, ou que par hasard vous avez mémorisé 72.14.207.99 au lieu de www.google.com. Même si les serveurs de noms de domaines fonctionnaient, Google disparaîtrait complètement d’Internet. Google tourne essentiellement sous Linux – qui est sans doute le plus populaire des systèmes d’exploitation libres de la planète. Pas de souci. Vous n’avez qu’à aller voir chez Yahoo!, Pas vrai ? Eh bien non. Yahoo! est l’un des plus grands consommateurs d’un autre système d’exploitation très répandu issu du libre : FreeBSD. A présent, vous vous êtes résigné à essayer 207.68.172.246. Nous savons tous qu’ils n’utilisent pas de logiciel libre, et qu’ils s’échinent depuis un bout de temps sur cette fonction de recherche.

OK, MSN est là, paré à la manoeuvre, alors maintenant lançons une recherche. J’ai entendu un remix sympa de Shakira à la radio ce matin, c’est ce que je vais rechercher. MSN me renvoie une liste de sites qui proposent la chanson… Je clique dessus… et… rien. Pas de dance music ? Pas de rythmes latinos ? Plus de 60% des sites Internet tournent sous Apache, un serveur web issu du libre. Avant même que je ne clique sur un lien, mes chances de succès ont été réduites à 4 sur 10.

Sur les 118 023 363 sites recensés jusqu’à présent par NetCraft ce mois de mai, un petit peu plus de 70 millions ne fonctionneraient plus si le logiciel libre venait à disparaître. Certes, Apache n’est pas le seul seveur web issu du libre et… Vous connaissez la suite. Je pourrais continuer des heures et des heures sur vos transactions en ligne, qui ne pourraient être sécurisées sans OpenSSH et OpenSSl et tous les autres services auxquels des utilisateurs ont recours tous les jours et qui, selon ce scénario, n’existeraient pas.

Le logiciel libre n’est pas une nouvelle tendance. Ce n’est pas un phénomène de mode éphémère. Il est partout, que vous le reconnaissiez ou non. De Linux intégré aux nouveaux routeurs sans fil en passant par Firefox, le navigateur libre le plus utilisé au monde, le logiciel libre est la force motrice d’Internet et d’innombrables autres technologies.

Vous savez déjà que je suis un inconditionnel du libre, mais vous, qu’en pensez-vous ? J’aimerais connaître votre avis sur la façon dont la disparition du logiciel libre vous affecterait.

Notre rédaction a reçu hier une lettre (non sollicitée) du SNEP nous invitant à participer à un nouvel espace d’information discussion intitulé face/face. Je me suis permis de la recopier ci-dessous. On peut y voir une réelle volonté d’écoute et d’ouverture (avec un joli forum phpbb) mais on peut également y voir une volonté médiatique de redorer un blâson quelque peu terni ces derniers temps.

Lorsque vous vous rendez sur le site de l’opération, la page de garde (cf illustration ci-dessus) se termine sur cette phrase : La musique, telle que nous la connaissons aujourd’hui, est en danger et son avenir est menacée. Il y a, je crois, une ambiguïté liée à la mise entre virgules du telle que nous la connaissons aujourd’hui. si vous ôtez ces virgules ce n’est plus tant la musique qui est en danger et son avenir menacé que la musique telle que nous la connaissons aujourd’hui qui est en danger et son avenir menacé.

Ce n’est pas tout à fait la même chose… À qui veut-on faire croire que le déclin du vieil empire industriel musical va nécessairement entraîner dans son sillage celui de la création musicale ?

14 mai 2007

Bonjour,

Les sites de collectifs d’adeptes du peer-to-peer et de l’internet libre – dont celui que vous animez fait partie – exercent une influence incontestable sur internet. Mais le débat en ligne concernant l’avenir de la musique dans la société numérique – et ses enjeux technologiques, juridiques, économiques et artistiques – est souvent excessif et manichéen. Force est de constater que les professionnels de l’industrie musicale ont souvent été les grands absents de ces échanges.

C’est pourquoi nous sommes heureux de vous informer que le SNEP (Syndicat National de l’Edition Phonographique) ouvre un espace de discussion en ligne destiné à engager le dialogue entre TOUS les internautes concernés : passionnés de musique, de loisirs numériques, de technologies et adeptes (ou non) du peer to peer. Le SNEP invite également les professionnels de la musique à délivrer leur point de vue : pour la première fois, les collaborateurs des maisons de disque sont mobilisés pour venir débattre avec les internautes.

Dès maintenant, tous les internautes – dont les visiteurs et les contributeurs de votre blog ou site sont susceptibles de faire partie – sont invités à échanger leur point de vue avec les professionnels de l’industrie du disque sur le site participatif du SNEP : www.faceface.fr

Cordialement.

Hervé Rony
Directeur Général Snep

Merci d’avoir évoqué un internet libre et non gratuit. De plus ravi et honoré d’apprendre que nous faisons partie de ceux qui exercent une influence incontestable sur internet. Mais permettez-moi d’en douter.

Quant au débat en ligne qui serait excessif et manichéen, il est venu réveiller un vieux souvenir. Une campagne d’affichage du… SNEP qui n’était pas forcément un modèle de modération.

Mais comme on ne va pas se quitter comme ça, voici une nouvelle chanson de l’Inconnue de la Villa Mystère 😉

C’est notre ligne de front à nous. À Framasoft on n’est pas de gauche ou de droite mais on est clairement pour la défense des biens communs que certaines logiques économiques tentent de s’approprier à grands coups de lois et de brevets dont on ne me fera plus croire qu’ils sont nécessairement là pour protéger et favoriser l’innovation.

Le bien commun qui nous est cher c’est évidemment le logiciel libre mais fort de notre expérience et de notre culture, il est difficile de ne pas être également sensible aux autres champs qui sont mis à mal actuellement, à commencer par l’écologie qui sur le même modèle humaniste et résistant tente de préserver rien moins que notre planète.

La traduction que nous vous proposons aujourd’hui est une illustration aussi malheureuse qu’emblématique de ces trop nombreux jusqu’où iront-ils ? puisqu’on touche ici directement à notre patrimoine, à notre bien-être et à notre santé. Il s’agit d’évoquer les tentatives de captation marchande du… yoga, avec une pertinente mise en parallèle sur le situation de l’industrie pharmaceutique^[1].

L’occasion pour moi de rappeler la sortie en poche de l’excellent livre Du bon usage de la piraterie de Florent Latrive dont le sujet est au cœur même de ce qui est exposé ici et qu’il est donc tout à fait recommandé de parcourir pour aller plus loin et ne pas se réveiller un jour pour constater que nos moindres faits et gestes appartiennent désormais à un je-ne-sais-quel-obscur ayant droit !^[2]

Pouvez-vous breveter la sagesse ?

Can you patent wisdom?

Suketu Mehta – International Herald Tribune – 7 mai 2007
(Traduction Framalang : Mben, Penguin, Olivier et Daria)

J’ai grandi en voyant mon père se tenir sur la tête tous les matins. Il faisait le sirsasana, une position de yoga qui explique qu’il ait l’air si jeune à 60 ans passés. Maintenant il serait peut-être obligé de payer une redevance à un détenteur de brevet américain s’il enseignait le secret de sa bonne santé aux autres.

L’office des brevets et des marques américain a publié 150 copyrights liés au yoga, 134 brevets sur des accessoires de yoga, et 2315 marques de yoga. Il y a beaucoup d’argent à gagner en se tordant comme un bretzel — 3 milliards par an dans la seule Amérique. C’est un mystère pour la plupart des Indiens que quelqu’un puisse faire autant d’argent en enseignant un savoir qui n’est pas supposé être acheté ou vendu tel de vulgaires saucisses.

Le gouvernement indien prend la chose au sérieux. Il a mis en place une cellule qui est en train de cataloguer la connaissance traditionnelle, y compris les remèdes ayurvédiques et les centaines de poses de yoga, pour les empêcher d’être piratés et copyrightés par les revendeurs étrangers. Les données seront traduites à partir du Sanskrit ancien et des textes tamouls, stockées numériquement, et disponibles dans cinq langues internationales, de sorte que les offices des brevets des autres pays puissent voir que le yoga n’est pas originaire d’une communauté de San Francisco.

Il est important de remarquer que les premiers à breveter la sagesse traditionnelle indienne sont des Indiens, la plupart du temps à l’étranger. Nous savons saisir une occasion lorsqu’elle se présente et nous avons exporté des générations de gourous, experts dans la vente ambulante de l’épanouissement pour un dollar. Mais, en tant qu’Indiens, ils devraient savoir que l’idée même de faire breveter la connaissance est une grossière violation de la tradition du yoga.

En Sanskrit, « yoga » signifie « union ». Les Indiens croient en un esprit universel — brahman — dont nous sommes tous une partie, et qui médite éternellement. Chacun a accès à cette connaissance.

La connaissance dans l’Inde antique a été protégée par les règles des castes, et non celles de la loi ou de l’argent. Le terme « propriété intellectuelle » était un oxymore : l’intellect ne pouvant être la propriété de quiconque. Peut-être est-ce pour cette raison que les Indiens ne se sentent pas obligés de payer pour la connaissance. Des copies pirates de mon livre sont ouvertement vendues dans les rues de Bombay, pour le quart de son prix officiel. La plupart des intrigues et des musique des films de Bollywood sont tirées d’Hollywood.

Pourtant, les Indiens sont irrités à chaque fois qu’ils entendent les rapports – souvent pompeux – des Occidentaux volant leur sagesse ancienne à travers le mécanisme du droit d’auteur. Leurs craintes sont peut-être exagérées, mais elles sont répandues et reflètent l’expérience mitigée de l’Inde avec la mondialisation.

Les entreprises pharmaceutiques occidentales se font des milliards avec des médicaments qui ont souvent été au départ découvert dans des pays en voie de développement. Mais les plantes médicinales comme la margose ou le curcuma, qui sont connus pour être efficaces contre tout, du diabète aux hémorroïdes, ne rapportent rien aux pays dont les sages en ont en premier isolés les vertus. Le gouvernement indien estime que dans le monde, 2000 brevets basés sur des médicaments traditionnels indiens, sont déposés chaque année.

Les médicaments et le hatha yoga ont le même but : nous aider à mener une vie en meilleure santé. L’Inde a offert au monde le yoga gratuitement. Il n’est pas étonnant que beaucoup de personnes dans le pays trouve que le monde devrait rendre la politesse en rendant disponible à faible coût des médicaments pouvant sauver des vies, ou au moins laisser les entreprises indiennes fabriquer des génériques à faible coût. Si la position du lotus appartient à tout l’humanité, alors la formule du Glivec doit l’être aussi, le médicament pour la leucémie dont le brevet sert de base au procès d’une entreprise pharmaceutique Suisse contre le gouvernement indien.

Pendant des années, la loi indienne a autorisé ses entreprises pharmaceutiques à répliquer des médicaments brevetés en Occident et les vendre à un prix plus faible aux pays trop pauvres pour pouvoir se les offrir autrement. De cette façon, l’Inde a fourni la moitié des médicaments utilisés par les personnes séropositives dans les pays en voie de développement. Mais en mars 2005, le parlement indien, sous la pression de mettre le pays en accord avec les lois sur la propriété intellectuelle de l’Organisation Mondiale du Commerce, a voté une loi déclarant illégale la production de copie générique de médicaments brevetés.

Cela a mis des médicaments anti-rétroviraux pouvant sauver des vies hors de portée de la majorité des 6 millions d’Indiens qui ont le SIDA. Les multinationales du médicament qui protègent bec et ongles leur brevets s’opposent aux tentatives de l’Inde de modifier les règles de l’Organisation Mondiale du Commerce pour protéger leurs remèdes traditionnels. Il y a plus que simplement de l’argent dans la bataille. Il y a aussi la perception que le système commercial mondial est injuste, que les dés sont pipés en défaveur des pays en voie de développement. Si la copie des médicaments occidentaux est illégal, alors le brevetage du yoga doit l’être aussi. Il s’agit également de piratage intellectuel, ou alors la propriété intellectuelle marche sur la tête.

Suketu Mehto est l’auteur de "Maximum City: Bombay Lost and Found."

Partant du constat que l’absence de polices de caractère libres équivalentes aux trop célèbres polices propriétaires de Microsoft Times New Roman, Arial et Courier New était un handicap à la migration vers GNU/Linux, la société Red Hat a eu la très bonne idée de créer Liberation fonts un jeu de trois polices susceptibles de les remplacer.

Elles ont rigoureusement la même taille et le même espacement que les polices de Microsoft ce qui implique l’absence de décalage lorsque vous faites la conversion. Red Hat nous encourage du reste non seulement à faire cette conversion mais à adopter ces polices par défaut dans Thunderbird, Firefox et OpenOffice.org (mais aussi dans Microsoft Office, Microsoft Windows, Mac OS X, etc. si vous êtes encore sous OS propriétaire).

Ces polices sont sous licence GNU General Public License v.2 mais avec cette précision exception notable que tout document réalisé avec ces polices n’a aucune obligation (virale) à être lui aussi sous la même licence. Autrement dit ces polices portent vraiment bien leur nom.

Liberation Sans

Équivalent libre à Arial, Albany, Helvetica, Nimbus Sans L et Bitstream Vera Sans.

Liberation Serif

Équivalent libre Times New Roman, Thorndale, Nimbus Roman et Bitstream Vera Serif.

Liberation Mono

Équivalent libre à Courier New, Cumberland, Courier, Nimbus Mono L et Bitstream Vera Sans Mono.

Sur la page de l’annonce officielle vous trouverez les polices à télécharger en paquet archive .rpm (c’est normal on est chez Red Hat) mais également en archive .tar.gz (le .zip du libre que vous pouvez décompresser avec 7-zip par exemple si vous êtes sous Windows). Et Red Hat de conclure ainsi son annonce : This is just one way for Red Hat to say thank you to all our friends in the open source community for all you have done to make us successful.

C’est à notre tour de les remercier parce que les Liberation fonts nous ôtent une belle épine du pied et apportent toujours plus de confort au peuple migrateur que nous sommes.

Je ne sais si c’est un regret mais je ne suis pas développeur. Du coup ma connaissance du logiciel libre est exogène et non endogène et par là-même inévitablement partielle. C’est pourquoi je suis souvent à l’affût d’informations sur les modes opératoire des projets communautaires libres qui me permettent de combler certaines lacunes et parfaire ma culture en la matière. J’y trouve également des sources d’inspiration pour notre propre projet qui est celui d’animer collectivement le réseau Framasoft avec quelque part le même état d’esprit qu’une communauté de développeurs open source.

Tout ça pour dire que cette nouvelle traduction concerne avant tout ceux qui voudraient rejoindre pour la première fois la communauté d’un logiciel libre mais également tous ceux qui en fins observateurs souhaitent un peu mieux comprendre comment ça marche de l’intérieur. Parce qu’effectivement, et Framasoft est là pour en témoigner en aval, force est de constater que le logiciel libre ça marche et même plutôt bien 🙂

Nous avons conservé tout le long l’expression open source utilisée par l’auteur. Même si parfois sujet à précision voire controverse, elle est ici pour nous pleinement synonyme de logiciel libre (free software).

Je signale au passage que sur le même thème notre dynamique petite équipe de traduction (baptisée Framalang) a entrepris une autre chantier autrement plus ambitieux : traduire le livre de Karl Fogel Producing Open Source Software dont nous espérons la matérialisation en un joli Framabook dans le courant de l’été^[1].

10 règles d’or pour démarrer avec l’open source

10 golden rules for starting with open source

Tobias Schlitt – 19 avril 2007
(Traduction Framalang : Daria, Olivier et Yostral)

Êtes-vous nouveau en open source ? Si ce n’est pas le cas, vous rappelez-vous encore ce que c’était, quand vous avez commencé pour la première fois avec l’open source? J’ai récemment essayé de me rappeler ces jours… c’était en 2001, quand j’ai découvert PEAR et que, peu de temps après, j’ai commencé à travailler sur mes propres paquets pour PEAR…

Je suis presque sûr d’avoir violé au moins 9 des 10 règles que je vais essayer d’écrire ici, règles que vous devriez connaître et prendre à coeur si vous voulez faire partie de la communauté open source. En tout cas, vous devrez garder ces règles en tête si vous voulez entrer dans la communauté PHP, mais je suis presque sûr que cela s’applique aussi à d’autres communautés.

Si vous voulez vous lancer tout de suite dans le développement open source, soyez sûr de lire les règles suivantes avant d’aller plus loin. Je suis sûr que vous avez beaucoup, beaucoup de grandes idées à l’esprit et que vous ne pouvez pas attendre pour en parler et les réaliser. Mais, prenez d’abord une grande respiration et lisez les règles suivantes, pensez-y, prenez-les à coeur, puis recommencez et repensez-y encore…

1. Collez à votre niveau de Karma

L’open source n’est pas une démocratie. Vous avez entendu autre chose ? C’est faux. Gardez toujours à l’esprit : l’open source n’est pas une démocratie. Chaque développeur a un certain niveau de Karma (inexprimé et inexprimable), ce qui lui permet de décider (ou même de dicter) des choses et d’utiliser certaines infrastructures de la communauté (comme leur système de versionnage , leurs serveurs…). Pensez au Karma comme à votre niveau de points dans un jeu de rôle. Plus le nombre de niveau auxquels vous avez joué augmente, plus vous résolvez des énigmes, plus votre niveau de Karma s’élève. Mais prenez garde, il peut aussi baisser si vous n’agissez pas correctement.

Cela étant, si vous êtes nouveau dans cette communauté, votre niveau de Karma est de 0, par défaut. Vous devrez toujours garder cela en tête. Donc, qu’est-ce que c’est tous ces trucs autour du Karma ? Le Karma représente essentiellement la confiance que la communauté a en vous. Il n’est pas possible de mesurer le Karma avec un nombre ou même de le deviner, parce qu’il y a tellement de facteurs influençant votre Karma, et votre niveau de Karma est différent pour chaque individu de la communauté. Par exemple votre niveau d’expérience technique influence habituellement grandement votre Karma : plus vous en savez à propos du sujet de votre projet et au sujet de l’environnement technique, plus votre Karma sera élevé. Un autre facteur est la quantité de travail que vous investissez dans le projet : si vous êtes membre de ce projet depuis longtemps et que vous avez déjà passé des milliers d’heures à travailler dessus, votre Karma sera probablement élevé aussi.

Il y a beaucoup d’autres facteurs qui influencent votre Karma de développeur open source, comme vous allez l’expérimenter dans les prochaines semaines et prochains mois. Ce que vous devez avant tout vous rappeler est ceci : si vous êtes nouveau dans la communauté votre niveau de Karma est de 0 (ou proche). Pour augmenter votre Karma vous avez besoin de montrer à la communauté que vous êtes digne de confiance. Vous y parviendrez en respectant simplement les 9 règles suivantes.

2. L’information est le Karma

La première chose que vous voudriez probablement faire c’est poser une question ou proposer une idée cool à la communauté. Il y a de bonnes chances pour que vous le fassiez sur une liste de diffusion, qui est le moyen de communication le plus commun dans le monde de l’open source. Evitez de faire cela tout d’abord ! Les gens se fatiguent vraiment très vite si vous leur demandez quelque chose qui est évident à leurs yeux ou si vous proposez une idée/posez une question qui a été proposée/posée par d’autres avant (surtout si cela est déjà arrivé plusieurs fois).

Donc, que devrez-vous effectivement faire avant de poster une question ? Cherchez l’information ! Essayez Google, les sites des projets, les archives des listes de diffusion, la sphère des blogs du projet et toutes les ressources que vous pourrez imaginer. N’effectuez pas une seule recherche, mais affinez votre recherche pour voir s’il n’y a vraiment rien de relatif à votre question. Il n’y a rien? Essayez encore de chercher ! Il n’y a vraiment rien ? Ok, alors allez-y et écrivez votre billet. Mais soyez sûr de lire les 8 règles suivantes avant de le faire !

Et que faire si vous avez une idée ? Faites la même chose que ce que vous devez faire pour les questions ! Regardez si quelqu’un d’autre n’a pas eu la même idée ou une idée similaire. Vous ne trouvez rien ? Vraiment sûr ? Faites alors des recherches sur le sujet. N’écrivez pas simplement quelque chose comme « Ne serait-il pas cool de… » ou « J’ai eu l’idée de… ». Effectuez des recherches sur le sujet dont vous voulez parler avec pédantisme. Comment d’autres projets (peut-être dans d’autres langages ou sur d’autres systèmes d’exploitations) résolvent-ils la question ? N’y a-t-il rien de similaire qui existe ? Pensez aux autres besoins des utilisateurs. Est-ce que c’est quelque chose spécialement pour vous ? Alors commencez à écrire une prétendue proposition. Choisissez un sujet explicite pour votre billet (pas seulement « J’ai une idée » ou quelque chose comme ça). Commencez à écrire une spécification : quel est votre problème ? Quelle est votre idée pour le résoudre ? Comment cela s’intégre-t-il dans le projet ? Qu’est-ce qui est nécessaire pour le faire ? Soyez prolixe sur tout cela. Dans la plupart des cas, les autres personnes ont une perspective complètement différente de la situation globale.

3. S’y habituer

Un point très important avant que vous ne commenciez à devenir un « contributeur » est de vous habituer à ce avec quoi vous travaillez et au sujet dont vous parlez. Vous n’aurez probablement jamais utilisé certains des outils qui sont employés couramment pour le projet, ou bien les outils utilisés sont différents de ceux dont vous avez l’habitude. Habituez-vous à ces outils et, plus important encore, habituez-vous au projet lui-même. Connaître tous les processus qui sont mis en oeuvre dans votre communauté est un point important. Devenir un habitué des outils qu’ils utilisent l’est encore plus.

L’un des ces outils importants est GNU patch, un outil qui applique des modifications (communément appelé un diff pour difference) à une version existante du code. Générer un patch est en général réalisé avec l’outil GNU diff. Si vous voulez produire un patch pour du code, vous aurez probablement besoin de cet outil. Beaucoup de projets utilisent un système de versionnage pour archiver leur code source. Les programmes les plus courants sont CVS et son petit frère plus récent SVN. Habituez-vous à ces systèmes et utilisez les activement ! Ces deux systèmes vous autorisent à extraire (check out en anglais) une certaine version de la source, à la manipuler et automatiquement à génerer un diff pour vos changements.

Si vous avez déjà fait ça, continuez et lisez les 7 prochaines règles !

4. Ne vous surestimez pas

Vous êtes un geek cool. Vous faites du développement depuis des années et, dans votre entourage, vous êtes un des gars les plus intelligents. C’est super. Mais ne présumez pas que cela vaut aussi pour le projet que vous voulez rejoindre. L’open source est habituellement réalisée par des gens qui sont extrêmement intéressés par le sujet, qui sont parfois beaucoup plus intelligents que vous et qui ont probablement une centaine de fois plus d’expérience que vous dans ce sujet spécifique. Restez calme et soyez plutôt timide qu’arrogant. Réfléchissez aux réponses données par les membres du projet, même si vous les trouvez stupides de prime abord ou si elles vous semblent grossières. Etudiez les sujets dont les gens parlent avant d’écrire une réponse. Prenez les réponses à vos demandes sérieusement, même si elles peuvent vous sembler illogiques.

5. Agir signifie Karma

Comme dit auparavant, le Karma est une valeur appréciable, qui dépend d’une centaine de facteurs. Un de ces facteurs est la comparaison entre ce que vous dites et ce que vous faites. Si vous avez une idée pour un projet et que vous êtes capable de la réaliser : allez-y et mettez la en œuvre. Si vous avez besoin d’une fonctionnalité, vous la ferez probablement de toute façon et utiliserez votre patch pour votre usage personnel. Si cela fonctionne, allez à la règle 2 et attachez votre patch à la proposition que vous avez écrite ! Cependant, avant d’agir, finissez de lire les 5 règles suivantes.

6. Soyez amical et ouvert

La plupart des développeurs open source avec qui vous traiterez auront probablement fait de l’open source depuis des années. Ils sont déjà stressés par des utilisateurs qui attendent que quelque chose se passe mal et par les nouveaux développeurs qui ne collent pas aux règles que vous êtes en train de lire. Souvenez-vous de ceci quand vous lisez leurs mails. Ces gars ne sont pas inamicaux ou grossiers, ils sont seulement occupés et ennuyés. Vous arriverez dans un état, où vous aurez à lire 20 listes de diffusion avec des milliers de posts, garder un oeil sur le grand nombre de lignes de code, intervenir dans beaucoup de discussions et interagir avec beaucoup de personnes différentes. Quand vous lirez les mails, prenez juste l’essence objective des mots que vous lisez et ignorez la tonalité que vous pourriez ressentir.

7. S’énerver est mauvais !

Cette règle^[2] est presque la même que la règle 6, mais c’est toujours très important. Lisez chaque conversation avec attention. Je connais ce sentiment assez bien, lorsque vous pensez que votre interlocuteur « est un idiot ». Il ne l’est pas ! Il n’y a pas d’idiot ici. Il a juste un point de vue différent du votre, ou a une base technique différente. Restez calme, réfléchissez à votre réponse pendant quelques minutes/heures/jours, puis écrivez-la quand vous ne serez plus en colère. Essayez d’énoncer vos arguments avec des mots polis et expliquez en détails pourquoi vous avez une opinion différente. Si vous sentez votre colère revenir pendant que vous écrivez, gardez votre réponse et revoyez-la encore plus tard. Les discussions enflammées sont vraiment une mauvaise chose et polluent les canaux de communication de votre projet. Elles ne cesseront jamais d’être mais c’est ainsi. La seule chose que vous pouvez faire contre cela, c’est de ne pas y prendre part.

8. Respecter le code étranger

Chaque partie du code que vous verrez a été écrite dans un but précis. Si vous parcourez le code d’autres personnes, vous penserez souvent « Quoi !!! ». Ne changez pas immédiatement le code pour qu’il fonctionne comme vous l’attendez personnellement. Prenez contact avec le développeur qui a écrit le code (par exemple en utilisant « svn blame », voir la règle 3). Discutez de votre point de vue avec lui. Ne faites pas cela en public tant que cela n’affecte pas une grande partie du projet. Si vous le faîtes, référez-vous au système de communication générale de votre projet et annoncez le problème à cet endroit. Souvenez-vous à tout prix des règles 2, 3 et 4. Si vous ne pouvez pas décider si un problème y a sa place, prenez contact avec des gens du projet que vous connaissez déjà et demandez-leur de l’aide. Si vous êtes sympa et que vous leur décrivez ce que vous voulez, ils vous aideront sûrement.

9. N’attendez rien

L’open source signifie habituellement travailler sur la base du volontariat. Ces gens fournissent (pour la plupart) des logiciels gratuits, donc ils ne font pas d’argent avec ce qu’ils réalisent de leurs mains. Ils le font pour différentes raisons. Certains sont juste idéalistes, d’autres veulent simplement partager quelque chose, d’autres veulent se faire connaître, d’autres veulent faire de l’argent avec les services qu’ils fournissent en plus et d’autres encore ont tout en même temps à l’esprit ou encore d’autres raisons… Quelle que soit leur raison pour faire de l’open source, ils le font gratuitement. Gardez toujours cela à l’esprit quand vous leur soumettez une requête.

Par exemple « les demandes de fonctionnalités » sont une bonne chose. Elles donnent aux développeurs une idée de ce dont ils pourraient aussi avoir besoin. Cependant, la majorité des développeurs open source implémenteront seulement les fonctionnalités dont ils ont aussi besoin, ou dans lequel ils voient un défi technique intéressant. Ne soyez pas ennuyé s’ils refusent d’implémenter une fonctionnalité dont vous auriez besoin. C’est leur strict droit de le refuser, jusqu’à ce que vous les payez pour le faire. Si une demande de fonctionnalité est refusée ou n’est pas implémentée, allez-y, implémentez-la vous-même ou envisagez de payer un développeur pour son implémentation. Les développeurs open source ont aussi besoin d’argent pour vivre et ils ne refuseront probablement pas de vous fournir un patch en échange d’un salaire. Quoi qu’il en soit, ils pourraient encore ne pas inclure votre idée dans leur projet ou l’implémenter d’une façon différente. Ne soyez pas fâché ! Ils ont le droit de le faire ! Essayez de faire avec leur conclusion ou essayez de les convaincre de le faire différemment, mais souvenez-vous toujours de respecter les 8 règles précédentes quand vous le faites.

Peu importe ce qui a été décrit avant, reconsidérez toujours votre idée plusieurs fois. Attendre quelque chose d’un développeur open source n’est pas la manière dont les choses marchent habituellement. Le faire vous-même est ce qui habituel.

10. Apprendre est tout

L’idée la plus importante derrière l’open source est l’apprentissage. Les gens fournissent leurs sources de manière ouverte pour permettre à d’autres personnes d’apprendre de leurs sources et d’apprendre des contributions des autres. C’est la même chose pour n’importe quel savoir ou connaissance fourni à propos du projet. Regardez simplement cet article et réfléchissez aux raisons pour lesquelles j’ai pu l’écrire ? C’est exact, c’est parce que je veux partager mon expérience de la communauté open source avec toute personne la découvrant et parce que je veux avoir des retours des autres, pour voir où je pourrais encore avoir des faiblesses et ce à quoi je n’ai pas prêté attention, pour le moment.

Soyez sûr d’apprendre quelque chose de chaque ligne que vous lisez, que ce soit du code ou une conversation. Vous pouvez apprendre de tout le monde, même si cela vous permet seulement d’apprendre comment une chose ne doit pas être faite…

Pendant que j’écrivais ces 10 règles, que je considère très importantes à lire pour chaque nouveau développeur open source, j’avais déjà d’autres règles en tête. Mais restons en là avec ces 10 règles, pour donner un point de départ. Si je pense à d’autres choses qui s’avèreraient être un ajout réellement intéressant, je les ajouterai plus tard. Nous verrons. Merci pour tous vos retours et j’espère que ce billet sera utile à chaque nouveau…

Kore m’a aussi conseillé de me référer à De la bonne manière de poser les questions, qui lui a rappelé ce billet, lorsqu’il le relisait. Je n’ai pas lu cet article avant (mais peut-être un autre semblable), mais cela a vraiment l’air approprié. Si vous avez d’autres ressources, n’hésitez pas à laisser un commentaire !

Doit-on nous aussi (ab)user de la femme objet pour faire la promotion d’Ubuntu comme alternative à Windows ?^[1]

Edit : On a finalement trouvé d’où est issu le dessin original qui effectivement n’est certainement pas libre, il s’agit d’une illustration de Greg Horn du personnage d’Emma Frost. On remarquera qu’à la base, la madame brule une lettre d’amour !

Jeudi dernier, petite escapade vers Florence. Charmante bourgade si il en est mais difficile d’échapper à l’invasion touristique…

Comme il me reste en stock des chansons de l’Inconnue de la Villa Mystère^[1], je crains fort que vous n’ayez à subir un nouveau petit clip diaporama avec quelques photos prises autour de la Piazza della Signoria ce jour-là.

Voici une récente et vibrante allocution télévisée du président de la République… équatorienne qui invite tous les pays d’Amérique latine à utiliser le logiciel libre à l’occasion du FLISOL, Festival Latinoamericano de Instalación de Software Libre, qui a eu lieu le 28 avril dernier.

Pour ce qui concerne la France, je crains qu’il ne faille encore un peu patienter !

Traduction

Mes chers amis. Rafael Correa président de la République d’Équateur vous salue. Comme vous le savez, le temps est venu de l’intégration de l’Amerique latine à tous les niveaux, incluant entre autres la technologie et l’utilisation des technologies de l’information.

Pour cette raison, il est nécessaire que nous tous adoptions le logiciel libre aussi bien au niveau public que privé. De cette manière nous garantirons la souveraineté de nos états, nous dépendrons de nos propres forces et non de forces externes à la région. Nous serons producteurs de technologies et pas seulement des consommateurs. Nous posséderons le code source, et développerons ainsi de nombreux produits qui, par la mise en commun de nos efforts, pourront être d’une grande utilité pour les entreprises publiques et privées de la région.

Aussi, je vous invite tous à utiliser le logiciel libre. Le gouvernement équatorien l’a deja établi comme politique de gouvernement et d’État. Ceci constituera un pas important dans l’integration et, pourquoi ne pas le dire, – pour la libération de l’Amérique latine.

La vidéo est classiquement extraite de YouTube mais ce qui l’est moins, et c’est assez malin, c’est qu’elle vient du canal YouTube de la présidence équatorienne qui peut ainsi l’inclure dans son annonce officielle sur le site gouvernemental tout en permettant à l’info de se diffuser.

edit : merci à plakat pour la relecture de la traduction