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à.

J’ose espérer que notre lectorat dépasse l’Hexagone pour rencontrer de temps en temps la francophonie mais ce soir, difficile d’échapper à l’actualité, la France a donc un nouveau président.

Les électeurs, et c’est heureux, ne se sont pas déterminés en fonction des seules positions des candidats sur le logiciel libre et les libertés numériques, quand bien même nous savons que cela ait pu avoir une influence chez certains d’entre nous.

Il n’empêche que si l’on passe outre nos propres (et respectueuses) opinions pour se réfèrer uniquement à l’objectif principal de Framasoft qui est de faire connaître et diffuser la culture libre en général et le logiciel libre en particulier au plus large public alors force est de constater que ce n’était pas forcément a priori le meilleur des choix.

Ce n’est pas un procès d’intention. Il suffit pour s’en convaincre de parcourir et comparer les réponses des uns et des autres au questionnaire de Candidats.fr ou pour aller plus vite d’en lire la remarquable synthèse de Thomas Petazzoni sur son blog.

Pour moi cela signifie ni plus ni moins que le mouvement national de défense, reconnaissance et impulsion institutionnelles du logiciel libre et son état d’esprit va s’en trouver si ce n’est freiné du moins ralenti.

Cela signifie également que des réseaux associatifs comme le nôtre, qui n’ont pas attendu un quelconque soutien de l’Etat pour démarrer et agir, ont encore toute leur raison d’être.

La route est (peut-être un peu plus) longue, mais la voie est (plus que jamais) libre…

Pensez-vous par exemple que la pléthore de distributions GNU/Linux soit une qualité de l’OS et le témoignage de la vivacité de sa communauté ou bien au contraire qu’on aboutit à une situation confuse où trop de choix tue le choix ?

Sur cette thématique assez classique de la pertinence de la pluralité du choix, voici la traduction d’un article (un peu technique mais fort intéressant) d’un développeur américain James Turner sur le site d’O’Reilly.

Extrait :

Alors, quels sont les avantages d’une monoculture et pourquoi Microsoft gagne-t-il si souvent quand les gens doivent choisir une plateforme ? C’est en grande partie à cause de ce que la communauté open source voit comme une force mais que ceux qui essaient de faire leur boulot dans le monde réel voient comme une faiblesse. Nous célébrons la diversité de choix disponibles pour résoudre un problème et nous appelons cela la liberté. Les directeurs informatiques et les patrons de la branche informatique (IT managers et CIOs en anglais) y voient du chaos, de la confusion et des doutes.

Pour ceux qui comme nous sont attachés à la liberté, avoir le choix est bien entendu une valeur fondamentale. Mais il peut en aller autrement dans le monde pragmatique de l’informatique professionnelle où c’est souvent l’efficacité qui est privilégié. Et alors dans ce contexte Microsoft conserve de sérieux atouts avec ses offres monoculturelles sécures et rassurantes^[1].

Les vertus de la monoculture

The Virtues of Monoculture

James Turner – 24 avril 2007 – Opinion
(Traduction Framalang : Don Rico et Yostral)

Je ne dis certainement rien de nouveau ici, mais j’ai pensé que je pourrai partager quelques réflexions sur les raisons qui poussent les gens à suivre la voie Microsoft. J’ai récemment fait quelque chose dans mon travail de tous les jours auquel je pensais depuis longtemps, mais pour lequel je n’ai jamais vraiment pris la peine d’aller jusqu’au bout, je me suis inscrit pour participer à un projet Microsoft-centrique et pour apprendre le .NET.

J’avais fait des tentatives avortées par le passé pour apprendre à coder dans l’Univers Microsoft. J’avais fait un essai à la sale époque des COM, mais le nombre de numéros qu’on me demandait d’exécuter me demandait trop d’effort par rapport à ce que j’étais alors prêt à consentir. Depuis j’ai gardé ce mauvais goût au fond de la bouche et j’ai refusé d’ajouter une seul compétence Microsoft à mon répertoire, même si cela représentait parfois un vide dans mon curriculum vitæ.

J’ai souvent travaillé dans des environnements où il y avait ce Monsieur Microsoft, l’évangéliste qui vous répète sans cesse à quel point ça aurait été plus facile en .NET. Je les ai classés dans la catégorie adorateurs de Gates buveurs de Tang*. Mais, à la fin de la journée, je me suis dit que si je devais les critiquer je devais vraiment comprendre leur monde. Connais ton ennemi et tout ça.

J’ai passé la semaine dernière à apprendre dans l’ordre C#, .NET et VSTO (c’est Visual Studio Toolkit for Office, si les abréviations de Microsoft ne sont pas votre tasse de thé). J’ai utilisé le livre Learning C# de chez O’Reilly et j’ai fait quelque chose qui m’arrive rarement : je m’y suis mis de manière très méthodique (du moins pour la première moitié).

Et devinez quoi? Microsoft possède dans ses mains une suite de développement plutôt bonne. Pour être honnête, C# est vraiment ce que je ferai si je pouvais complètement ré-écrire Java sans me soucier de la compatibilité descendante. Il y a quelques fonctionnalités vraiment sympas, comme les mots-clés virtual, override, et new qui vous permettent de spécifier ce qu’il se passe lorsque vous transtypez une classe dans sa classe de base et que vous appelez une méthode qui est définie dans les deux.

Visual Studio est un outil habile qui vous permet vraiment de créer des applications (et avec VSTO des ajouts pour Office) en deux temps trois mouvements. ADO.NET n’est pas pire que JDBC et s’intègre de manière transparente dans Visual Studio. J’ai été capable, arrivé à la fin de la semaine, de développer des applications autonomes et des ajouts pour Office qui étaient capable de dialoguer avec les bases de données en n’ayant écrit que peu de code. D’après ce que j’en ai vu, ASP.NET réalise la même chose pour les applications web MVC (NdT : Model View Controller).

Alors, quels sont les avantages d’une monoculture et pourquoi Microsoft gagne-t-il si souvent quand les gens doivent choisir une plateforme ? C’est en grande partie à cause de ce que la communauté open source voit comme une force mais que ceux qui essaient de faire leur boulot dans le monde réel voient comme une faiblesse. Nous célébrons la diversité de choix disponibles pour résoudre un problème et nous appelons cela la liberté. Les directeurs informatiques et les patrons de la branche informatique (IT managers et CIOs en anglais) y voient du chaos, de la confusion et des doutes.

Est-ce que je devrais utiliser iBatis ou Hibernate? XFire ou AXIS? Perl, PHP ou Ruby? Debian, Fedora, Ubuntu ou Suse? Si vous prenez la mauvaise décision vous pouvez perdre énormément de temps, comme nous l’avons découvert sur un projet récent où nous avons gâché une semaine à essayer de faire marcher AXIS2 pour un projet de service web pour finalement nous rendre compte que XFire était ce qu’il nous fallait.

Pour Monsieur Microsoft cette confusion n’existe pas. Vous utilisez ADO.NET, ASP.NET, C# et Windows. Ils fonctionnent tous, ils sont tous bien documentés du point de vue des besoins des développeurs, sans un seul regarde le code source désobligeant. A chaque fois que je pensais que j’allais être bloqué il y avait une douzaine d’articles expliquant comment faire exactement ce que je voulais faire, avec un exemple de code qui était à jour avec les versions du logiciel que j’utilisais et qui répondait vraiment au problème que je cherchais à résoudre.

Microsoft apporte le confort de ne pas avoir à choisir. Avoir le choix n’est pas toujours bon et la communauté open source offre parfois bien trop de manières différentes de plumer un canard, des choix qui sont pris plus par fierté, ego ou entêtement que par une authentique nécessité d’avoir deux alternatives différentes. Je ne montrerai personne du doigt, tout le monde connaît des exemples.

En fait, à moins que vous ne pensiez que je me sois tourné vers le Côté Obscur, le GROS problème avec une monoculture, c’est que vous vendez plus ou moins votre âme pour la stabilité d’un ensemble de choix défriché pour vous. En empruntant le chemin .NET, en gros, vous vous y perdez à tout jamais, et ce malgré Mono. Vous travaillerez toujours sur une plateforme Windows. Vous avez le joli anneau en or, mais Sauron tire les ficelles et vous fait danser. Pour beaucoup d’entreprises, celles qui n’ont pas besoin de se soucier du déploiement dans un environnement hétérogène, c’est un pacte qu’elles sont plus que prêtes à conclure.

Voici ce que je retiens de toute cette réflexion : en quelque sorte, nous devons commencer à faire le tri. La massue de 350kg pour faire entrer certaines idées dans les têtes devrait être mise à disposition pour marteler les têtes de ceux qui fourchent (NdT : qui créent un fork une déviation indépendante d’un projet) pour la seule et unique raison qu’ils ne sont pas en accord avec la licence, ou de ceux qui prennent les décisions. Quand on entend parler de deux (ou plus) projets qui répondent à la même problématique, on devrait se demander « Pourquoi ne mettent-ils pas en commun leurs efforts pour fournir une très bonne solution? » plutôt que de célébrer la diversité uniquement pour l’amour de la diversité.

A-ton vraiment besoin de Ruby on Rails ET de Groovy on Grails? Quand ils ont annoncé le poisson d’avril de Python on Planes j’ai mis quelques secondes pour réaliser que c’était un canular, parce que c’est exactement le genre d’effort faire quelque chose pour l’amour de le faire qui fractionne la communauté des logiciels open source. Il n’y a aucun moyen d’empêcher les gens de commencer des projets en double, et nous ne le voudrions pas, mais bon sang, doit-on l’encourager activement ?

On passe beaucoup de temps à se plaindre des moyens démoniaques qu’emploie Microsoft pour s’imposer partout. En faisant cela, nous nous lavons automatiquement de toute responsabilité que nous pourrions nous-même porter pour leur succès ou nos échecs. Le fait est qu’il existe d’excellentes raisons pratiques qui poussent les gens dans les bras de la boîte à outil de Redmond et nous devons accepter ceci comme un fait et en tirer des leçons plutôt que d’agiter nos poings en blamant l’obscurantisme. Car nous avons trouvé notre ennemi et c’est nous, pas Microsoft, du moins pas tout le temps…

Traduction^[1] d’un article issu du blog des Cobra Punchers. Je suis loin d’adhérer à tout ce qui est dit mais je crois qu’aucun musicien aujourd’hui ne peut faire l’économie de s’interroger sur les évolutions liées à internet et aux nouvelles technologies. Quid des licences aposées à ma musique ? Quid de sa diffusion ? Quid des contrats avec les sociétés de gestion des droits d’auteur.(type SACEM) ? Quid des contrats avec les maisons de disques (type Majors) ?

Pour ce groupe très rock’n roll ça donne un témoignage que d’aucuns trouveront peut-être excessif voire naïf mais qui a cependant le mérite de poser de bonnes questions en proposant une alternative qui pourrait bien à l’avenir être de plus en plus crédible.^[2]

La nouvelle industrie musicale

The New Music Industry

Ce n’est plus un secret, l’industrie musicale va mal. Ils ont changé leur modèle économique, leur principale source de revenus n’est plus la vente de musique mais les procès intentés à leurs clients. Chacun peut voir que c’est un modèle économique ridicule. Pourtant, ceux qui devraient être les mieux informés à propos du bateau en perdition qu’est l’industrie musicale aujourd’hui ignorent complètement tous les signes et grimpent à bord du Titanic avec un abandon désespéré.

Je parle des groupes, ces pauvres groupes naïfs qui pensent toujours que signer d’un contrat est comme passer la ligne d’arrivée en tête et se voir offrir tous ses rêves sur un plateau d’argent. Ces pauvres groupes naïfs qui ne lisent pas les petits caractères et qui ne parviennent pas à comprendre la partie commerciale de l’industrie dont ils désirent tant faire partie. Ces groupes qui vendent deux millions d’albums et qui se retrouvent avec une dette de centaines de milliers de dollars envers leur maison de disque qui devait rendre tous leurs rêves les plus fous réalité.

Ce sont ces gens qui devraient apprendre la nouvelle première règle de l’industrie musicale. Ne signez pas chez une grande maison de disque. J’irai même jusqu’à conseiller de ne signer avec aucune maison de disque. Je ne pense pas en avoir besoin, mais je vois très bien en quoi de nombreux groupes tireraient profit d’un contrat avec un label indépendant plus petit. Tout musicien n’a pas forcément le sens des affaires et vice versa, mais je pense que nous entrons dans une ère de la musique où le pouvoir reposera uniquement dans les mains des musiciens qui peuvent voir leur musique différemment et voir comment gagner de l’argent en faisant ce qu’ils aiment.

Voilà quelques concepts que tous les musiciens aujourd’hui devraient comprendre

1. Les gens vont partager votre musique entre eux – Ne voyez pas le partage de fichiers comme du vol. La plupart de ceux qui téléchargent de la musique ne se voient pas comme des voleurs, ils ne se voient pas comme des pirates, ils veulent juste écouter votre musique. Le but final de l’industrie de la musique est que le plus de gens possible écoutent votre musique. Quand les gens échangent de la musique entre eux, ils rendent service à ce musicien en augmentant le nombre de personnes qui l’écoutent. C’est difficile de voir le partage de fichier comme un bienfait pour les musiciens puisque la plupart des musiciens voient leur musique comme un produit à vendre sous la forme d’un album. Si les gens partagent votre musique entre eux gratuitement, comment un musicien peut-il gagner sa vie ?

2. La musique n’est plus un produit, c’est un contenu – Lorsque la musique était liée au support qui la jouait, c’était un produit de la même manière qu’un lave vaisselle ou un aspirateur est un produit. Vous achetez un aspirateur parce que c’est un produit qui nettoie votre sol. Vous achetiez un CD parce que c’est un produit qui fait des sons plaisants.

Maintenant le contenu est séparé du produit. Vous n’avez désormais plus besoin du CD pour entendre les beaux sons. Maintenant que la musique est retirée du produit, la musique existe seulement en tant que contenu. Le dilemme de comment faire de l’argent à partir de la musique devient bien plus simple à résoudre une fois que vous voyez la musique comme un contenu et pas comme un produit. Beaucoup de médias différents ont utilisé du contenu pour faire de l’argent. Le meilleur exemple est l’industrie de la télévision qui a utilisé des contenus gratuits de qualité pour faire de l’argent pendant des années.

3. Soyez le fournisseur de votre propre contenu – Il y a des centaines de sites de torrent qui amassent des fortunes en fournissant du contenu gratuit. Ils passent de la pub aux milliers de gens qui visitent leurs site. Ils attirent des milliers de visiteurs en offrant du contenu gratuit. Du contenu créé par d’autres personnes.

C’est cet argent qui devrait arriver directement dans les poches des musiciens. Les musiciens devraient être moins énervés par le fait que les gens écoutent leurs chansons gratuitement que par le fait que le trafic se dirige vers les sites de torrent plutôt que vers leur propre site web.

Le meilleur moyen de récupérer l’argent de la publicité est d’entrer directement en compétition en proposant votre propre contenu gratuitement. Placé devant deux choix, celui de naviguer dans les eaux troubles des sites de torrent peu scrupuleux à la recherche de votre dernier single ou celui de le télécharger directement depuis le site de l’artiste gratuitement, le client téléchargera le contenu depuis votre site web de manière certaine.

4. Le contenu n’est plus limité par le produit lui-même – Un CD contient 70 minutes de musique. La plupart des CD sortis par les musiciens font environ 45 minutes et contiennent entre 10 et 15 chansons. Chaque CD est vendu avec une jolie couverture, une liste des chansons, des photos du groupe et les paroles. C’est le format que presque tous les groupes ont suivi depuis que je pouvais atteindre le bouton “Play” sur la chaine HiFi de mon père.

Puisque le contenu du CD n’est plus lié à ce disque brillant de 70 minutes, la façon dont la musique est commercialisée et vendue est maintenant libérée de ce vieux format usé. Je pense qu’iTunes a commencé à paver la route pour le retour des singles. Les groupes sortent leurs chansons à un rythme plus soutenu et constant, ils pondent une chanson tous les deux mois depuis l’intimité de leur maison.

L’artiste n’aura plus besoin de faire du “remplissage” pour allonger artificiellement la durée de leur album. Les fans n’auront plus à acheter 9 chansons qu’ils n’aiment pas afin d’en avoir 3 qu’ils adorent. Les fans n’auront plus à attendre des années entre deux albums. Les fans auront une nouvelle dose du groupe qu’ils aiment à chaque fois qu’il écrit une nouvelle chanson.

Ceux qui adopteront cette idée rapidement bénéficieront grandement du fait que leur groupe sera dans les médias plus souvent. Les groupes auront plus souvent l’occasion de faire leur promotion s’ils sortent une chanson tous les mois. Les singles profiteront aussi aux musiciens qui génèrent leurs revenus par les bénéfices de la publicité. S’ils sortent plus de chansons dans l’année, leur site web aura un trafic plus constant.

Beaucoup de musiciens et de maisons de disques grinceront des dents à l’idée de distribuer la musique gratuitement, mais cela ne peut pas être évité. Grâce à Internet, partager la musique que vous aimez est devenu plus simple que d’aller au magasin l’acheter. La prochaine étape pour les groupes est de rendre le téléchargement de leur musique encore plus aisé aux fans pour qu’ils puissent contrôler le contenu qu’ils créent et gagner de l’argent par la même occasion.

Naïfs que nous sommes…

Dans un récent billet j’annonçais un peu hâtivement le projet de faire un album sous licence Art Libre avec les fonds de tiroir d’une chanteuse que j’apprécie tout particulièrement et que je présentais dans un petit clip diaporama en guise de découverte.

Cela risque d’être un peu plus compliqué que prévu pour cause d’affiliation de la dite chanteuse à la SACEM (je subodorais cependant qu’il pouvait y avoir potentiellement un problème en me gardant bien de citer son nom). En fait cela risque même d’être tout simplement impossible à réaliser puisque le contrat SACEM est une cession de droits exclusifs pour le passé, le présent et le futur.

Et déjà rien que la mise en ligne du clip est illégale.

C’est d’autant plus dommage que ces fonds de tiroirs ne sont pas des morceaux au rabais. Ce sont des créations antérieures au groupe actuelle de la chanteuse (et antérieures à son inscription à la SACEM qui plus est). Elle ne comptait tout simplement plus les exploiter, les jouer et/ou les réenregistrer avec sa nouvelle formation et du coup elle m’avait contacté pour savoir si ça m’interessait de les verser dans le pot commun de la culture libre via Framasoft.

Vous m’en voyez contrarié (pour ne pas dire plus) parce que cela signifie que les morceaux vont rester définitivement dans les tiroirs contre la réelle volonté de leur auteur. Je veux bien que, comme ils disent, la SACEM protège les artistes et la création mais en ce moment, je ne sais pas si vous avez remarqué, plus on parle de nous protéger et plus on finit par nous vérouiller.

Allez, un dernier petit clip (toujours aussi illégal) en guise d’au revoir pour vous faire partager ma frustration.

Il s’agit d’une chanson traditionnelle irlandaise In search of a rose reprise notamment par The Waterboys. Les photos sont sous licence Creative Commons BY et ont toutes été faites dimanche dernier dans un parc à Rome.

Notre ami Ploum participant à la sortie prochaine d’un magazine sur Ubuntu s’est vu également offrir un encart publicitaire de son choix et il a gentiment pensé à nous.

Ni une, ni deux, un post sur Framagora et voici les trois sympathiques réalisations proposées par la communauté. Grand merci à eux !

Ces trois illustrations sont sous licence Art Libre. Vous trouverez des versions originales de plus grande taille en suivant le fil du forum.

Informatif by Restouble

Clairvoyant by Harrypopof

Grandiloquent by Pfelelep

J’en profite pour remercier Pfelelep pour le joli bandeau de ce blog. Même si j’ai un doute, mes proches le trouvent assez ressemblant !