L’écrivain Evgeny Morozov n’aime pas les visions bisounours des nouvelles technologies.

On se souvient qu’il y a deux ans il avait vertement critiqué le soit-disant pouvoir libérateur d’Internet, ce qui lui avait valu réponse de Cory Doctorow traduite par nos soins.

Il s’en prend aujourd’hui à l’usage immodéré de l’expression « open » qui, à force d’être utilisé à tous les sauces, prend le risque d’être vidé de son (noble ?) sens.

Ouvert et fermé

Open and Closed

Evgeny Morozov – 17 mars 2013 – NewYorkTimes.com (Opinion)
(Traduction Framalang)

« L’impression 3D peut-elle être subversive ? » demande une voix dans la vidéo la plus terrifiante que vous puissiez trouver sur Internet ce mois-ci. Il s’agit de la bande-annonce pour Defcad.com, un moteur de recherche pour des modèles imprimables en 3D de choses que les « institutions et les industries ont pour intérêt commun de garder loin de nous », incluant des « appareils médicaux, médicaments, biens, pistolets ».

La voix appartient à Cody Wilson, un étudiant en droit du Texas qui a fondé l’année dernière Defense Distributer, une initiative controversée visant à produire une « arme wiki » imprimable. Avec Defcad, il s’étend au-delà des armes, autorisant, par exemple, des passionnés de drones à rechercher des pièces imprimables.

M. Wilson joue la carte de « l’ouverture » de Defcad jusqu’à dire qu’elle est l’opium des masses armées d’iPad. Non seulement le moteur de recherche Defcad sera placé sous le signe de l’« open source » — la bande-annonce le clame à deux reprises — mais également de « l’open data  ». Avec une telle ouverture, Defcad ne peut pas être le Mal, n’est-ce pas ?

Personne n’a besoin de voir des projets tels que Defcad pour constater que « l’ouverture » est devenue un terme dangereusement vague, avec beaucoup de sex-appeal mais peu de contenu un tant soit peu analytique. Certifiées « ouvertes », les idées les plus odieuses et suspectes deviennent soudain acceptables. Même l’Église de Scientologie vante son « engagement envers la communication ouverte ».

L’ouverture est aujourd’hui un culte puissant, une religion avec ses propres dogmes. « Posséder des gazoducs, personnes, produits, ou même la propriété intellectuelle n’est plus la clef du succès. L’ouverture l’est », clame l’éditorialiste Jeff Jarvis.

La fascination pour « l’ouverture » provient principalement du succès des logiciels open source, du code informatique publiquement accessible auquel tout le monde peut contribuer. Mais aujourd’hui ce principe est en train d’être appliqué à tout, de la politique à la philanthropie ; des livres intitulés « The Open-Source Everything Manifesto » (le Manifeste du Tout Open Source) et « Radical Openness » (L’Ouverture Radicale) ont récemment été publiés. Il existe même « OpenCola » — un vrai soda pour le peuple.

Pour de nombreuses institutions, « ouvert » est devenu le nouveau « vert ». Et de la même façon que certaines entreprises « verdissent » (greenwash) leurs initiatives en invoquant une façade écolo pour cacher des pratiques moins recommandables, un nouveau terme vient d’émerger pour décrire ce besoin d’introduire « l’ouverture » dans des situations et environnements où elle existe peu ou pas : « openwashing » (« ouvertisation »).

Hélas, « l’ouvertisation », aussi sympathique que cela puisse sonner, ne questionne pas l’authenticité des initiatives « ouvertes » ; cela ne nous dit pas quels types « d’ouverture » valent le coup, s’il en est. Toutes ces ouvertures, ou prétendues ouvertures, ne se valent pas et nous devons les différentier.

Regardez « l’ouverture » célébrée par le philosophe Karl Popper, qui a défini la « société ouverte » comme l’apothéose des valeurs politiques libérales. Ce n’est pas la même ouverture que celle du monde de l’open source. Alors que celle de Popper concernait principalement la politique et les idées, l’open source concerne avant tout la coopération, l’innovation, et l’efficacité — des résultats utiles, mais pas dans toutes les situations.

Regardez comme George Osborne, le chancelier britannique a défini les « politiques open source » récemment. « Plutôt que de se baser sur le fait que des politiciens » et des « fonctionnaires aient le monopole de la sagesse, vous pouvez vous engager via Internet » avec « l’ensemble du public, ou du moins les personnes intéressées, pour résoudre un problème particulier ».

En tant qu’ajout à la politique déjà en place, c’est merveilleux. En tant que remplacement de la politique en place, en revanche, c’est terrifiant.

Bien sûr, c’est important d’impliquer les citoyens dans la résolution des problèmes. Mais qui décide des « problèmes particuliers » auxquels les citoyens doivent s’attaquer en premier lieu ? Et comment peut-on définir les limites de ce « problème » ? Dans le monde du logiciel open source, de telles décisions sont généralement prises par des décideurs et des clients. Mais en démocratie, les citoyens tiennent la barre (plutôt en délèguent la tenue) et rament simultanément. En politique open source, tout ce qu’ils font, c’est ramer.

De même, un « gouvernement ouvert » — un terme autrefois réservé pour discuter de la responsabilité — est aujourd’hui utilisé plutôt pour décrire à quel point il est facile d’accéder, manipuler, et « remixer » des morceaux d’informations du gouvernement. Ici, « l’ouverture » ne mesure pas si de telles données augmentent la responsabilité, mais seulement combien d’applications peuvent se baser dessus, et si ces applications poursuivent des buts simples. L’ambiguïté de l’ouverture permet au Premier Ministre britannique David Cameron de prôner un gouvernement ouvert, tout en se plaignant que la liberté d’expression « bouche les artères du gouvernement ».

Cette confusion ne se limite pas aux gouvernements. Prenez par exemple cette obsession pour les cours en ligne ouvert et massif (NdT : MOOC). Que signifie le mot ouvert dans ce cas? Eh bien, ils sont disponibles en ligne gratuitement. Mais il serait prématuré de célébrer le triomphe de l’ouverture. Un programme d’ouverture plus ambitieux ne se contenterait pas d’étendre l’accès aux cours mais donnerait aussi aux utilisateurs la possibilité de réutiliser, modifier et d’adapter le contenu. Je pourrais prendre les notes de conférence de quelqu’un, rajouter quelques paragraphes et les faire circuler en tant qu’élément de mon propre cours. Actuellement, la plupart de ces cours n’offrent pas cette possibilité : le plus souvent leurs conditions d’utilisation interdisent l’adaptation des cours.

Est-ce que « l’ouverture » gagnera, comme nous l’assurent ces Pollyanas numériques? Probablement. Mais une victoire pour « l’ouverture » peut aussi marquer la défaite de politiques démocratiques, d’une réforme ambitieuse et de bien d’autres choses. Peut-être faudrait-il mettre en place un moratoire sur le mot « ouvert ». Imaginez les possibilités que cela pourrait ouvrir !

Crédit photo : Pumpkincat210 (Creative Commons By)

Bientôt la dernière séance de traduction ! Jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction framalang : tcit, Julius22, Sky, lamessen, goofy, peupleLà, merlin8282, lamessen, Jej, Alpha

Le Logiciel Libre dans le secteur public

Till Adam

Issu du milieu de la musique et des sciences humaines, Till Adam a passé pas loin des dix dernières années dans le monde de la programmation. Il travaille au sein de KDAB où il dirige plusieurs services, dont celui qui est en charge des logiciels libres. Till officie aussi au sein du conseil d’administration de Kolab Systems AG, une entreprise dont le modèle économique repose entièrement sur les logiciels libres. Il vit avec sa femme et sa fille à Berlin.

Introduction

J’imagine que comme de nombreux autres auteurs de cette compilation d’articles, j’ai commencé à contribuer au logiciel libre lorsque j’étais étudiant. J’avais décidé relativement tard dans ma vie de poursuivre un cursus en informatique (ayant échoué à devenir riche et célèbre en tant que musicien). Je m’attendais donc à être légèrement plus âgé que mes pairs en obtenant mon diplôme. J’ai donc pensé qu’il serait bénéfique d’apprendre par moi-même la programmation, qui ne m’était pas trop enseignée à l’école, afin de d’avoir plus d’atouts aux yeux de futurs employeurs, en dépit de mon âge. Après quelques incursions dans diverses petites communautés, j’ai finalement trouvé ma voie dans le projet KDE et j’ai commencé à travailler sur l’application de courriel.

Grâce aux personnes extrêmement serviables et douées techniquement que j’y ai rencontrées, j’ai pu apprendre rapidement et contribuer de façon significative au code, ce qui m’a entraîné de plus en plus dans leur réseau social, mais aussi vers le domaine fascinant des problèmes techniques liés à la gestion de données personnelles.

Lorsque KDAB, une entreprise remplie de gens qui utilisaient KDE, m’a demandé si, dans le cadre d’un stage étudiant, je voulais les aider sur la partie commerciale d’un projet en cours, j’ai bien sûr été ravi de pouvoir gagner ma vie et bidouiller le logiciel KDE en même temps. Au fil des ans, j’ai été témoin de l’adoption et de l’utilisation des architectures de gestion des données personnelles de KDE par le secteur public, particulièrement en Allemagne, où j’ai pu y assister personnellement à la croissance économique de KDAB dans ce secteur géographique. Alors que j’évoluais vers des postes plus orientés sur le management, vendre et livrer des services issus du logiciel libre comprenant des produits de KDE à de grandes organisations, en particulier dans le secteur public, a finalement fait partie de mon travail.

Il faut noter que la plupart du travail sur le projet qui a inspiré ce texte était généralement fait en collaboration avec d’autres entreprises du logiciel libre, à savoir glOcode, un spécialiste de la cryptographie qui se charge du maintien de GNUPG, et Intevation, une entreprise de conseil qui se concentre exclusivement sur le logiciel libre ainsi que ses défis stratégiques et opportunités. Mention spéciale à Bernhard Reiter, l’un des fondateurs d’Intevation, qui a joué un rôle clé lors de la vente et de la conduite de bon nombre de ces projets. Les quelques fragments de sagesse contenus dans ce texte sont probablement issus de son analyse et des nombreuses conversations que j’ai pu avoir avec lui au fil des ans.

Donc, si Bernhard et moi pouvions revenir dans le temps, quelles pourraient donc bien être les idées que nous partagerions avec nos « nous »  plus jeunes et plus naïfs ? Eh bien, il s’avère qu’elles commencent toutes par la lettre P.

Personnes

Telles que sont les choses aujourd’hui, il est toujours plus difficile pour les gens de terrain des technologies de l’information et pour les décideurs d’utiliser du logiciel libre que ça ne l’est d’utiliser les alternatives propriétaires. Même en Allemagne, où le logiciel libre a un soutien politique relativement fort, il est plus facile et plus sûr de suggérer l’utilisation de quelque chose qui est perçu comme un « standard de l’industrie » ou comme « ce que tous les autres font » ; en d’autres termes, des solutions propriétaires.

Celui qui propose une solution en logiciel libre fera probablement face à de l’opposition de la part de collègues moins aventureux (ou ayant moins de vision), à un examen minutieux des supérieurs, à de plus grandes attentes par rapport aux résultats et à une pression budgétaire irréaliste. Il faut donc un type particulier de personnes souhaitant prendre des risques personnels, potentiellement compromettre l’avancée de leur carrière et combattre dans une bataille presque perdue d’avance. Ceci est bien sûr vrai dans n’importe quelle organisation. Mais, dans une administration publique, une ténacité particulière est requise car les choses bougent généralement plus lentement. Et une hiérarchie organisationnelle inflexible ajoutée à des options de carrière limitées amplifient le problème.

Sans allié à l’intérieur, faire envisager de façon sérieuse les options du logiciel libre peut s’avérer quasiment impossible. Si de telles personnes existent, il est important de les soutenir autant que possible dans leurs luttes internes. Ceci signifie leur fournir des informations opportunes, fiables et vérifiables sur ce qui se passe dans la communauté avec laquelle l’organisation entend interagir. Ces informations doivent contenir suffisamment de détails pour fournir une image complète tout en atténuant la complexité de la communication et du chaos de planification faisant parfois partie de la façon de travailler dans le monde du logiciel libre, de façon à ce que ça devienne plus gérable et moins effrayant. L’honnêteté et le sérieux aident à construire des relations fortes avec ces personnes-clés, qui sont la base du succès à plus long terme. Elles se reposent sur vous, en tant qu’intermédiaire avec le monde merveilleux et quelque peu effrayant des communautés du logiciel libre, pour trouver des chemins qui les mèneront elles et leurs organisations à leurs objectifs. Elles prennent également des décisions en se basant largement sur la confiance personnelle. Cette confiance doit être acquise et conservée.

Afin d’y parvenir, il est important de ne pas se concentrer uniquement sur les résultats techniques des projets, mais de garder en tête les objectifs plus larges, personnels et organisationnels que l’on doit atteindre lorsqu’on travaille sur ces projets. Le succès ou l’échec du projet en cours ne dépendra peut-être pas du fait qu’un responsable de projet au sein d’une agence soit capable de ne vanter que des fonctionnalités auxiliaires à ses supérieurs à des moments plus ou moins aléatoires du calendrier. Mais cela impactera peut-être le fait que le projet suivant se fasse ou ne se fasse pas. Lorsque vous avez peu d’amis, les aider à réussir est un bon investissement.

Priorités

En tant que technophiles, les gens du logiciel libre ont tendance à se concentrer sur ce qui est nouveau, excitant et qui paraît important au niveau technologique. En conséquence de quoi, nous mettons moins l’accent sur les choses qui sont plus importantes dans le contexte d’une administration publique (souvent vaste). Mais considérez quelqu’un désireux de changer tout un ensemble de technologies dans une structure qui a plutôt tendance à rester sur les mêmes technologies pendant une longue durée. Étant donné qu’un changement brusque est difficile et coûteux, il est de loin bien plus important d’avoir de la documentation sur les choses qui ne fonctionneront pas, de façon à pouvoir les éviter ou les contourner, que de savoir qu’une version à venir fonctionnera beaucoup mieux. Il est peu probable que cette nouvelle version soit jamais disponible pour les utilisateurs dpnt nous parlons ici. Et il est bien plus simple d’avoir affaire à des problèmes connus et anticipés plutôt que d’être forcé de faire face à des surprises. Le bogue documenté d’aujourd’hui est paradoxalement préférable à sa résolution de demain avec ses effets de bord imprévisibles.

Dans une grande organisation qui utilise des logiciels pendant une longue durée, le coût d’acquisition du logiciel, que ce soit par le biais de licences ou dans le cadre de développement sur mesure de logiciels libres par contrat, a peu d’importance en comparaison du coût de maintenance et de support. Cela mène à penser que moins de fonctionnalités, plus stables, ce qui induit une moindre charge pour le  l’organisme de support, auxquelles on peut faire plus confiance et qui ont moins besoin de maintenance intensive sont meilleures que de séduisantes nouveautés, complexes et sans doute moins matures.

Alors que ces deux sentiments vont à l’encontre des instincts des développeurs de logiciels libres, ce sont ces mêmes aspects qui rendent attractif pour le secteur public le fait de payer pour le développement de logiciels libres, plutôt que de dépenser de l’argent pour des licences de produits pris au hasard. En partant d’une large palette de logiciels gratuitement disponibles, l’organisation peut investir son budget dans le perfectionnement des parties précises qui sont pertinentes pour ses propres opérations. Elle n’a ainsi pas à payer (via les coûts de licences) pour le développement de fonctionnalités clinquantes et guidées par le marché dont elle n’a pas besoin. En soumettant tout ce travail à la communauté en retour, la maintenance à long terme de ces améliorations et du logiciel de base est partagée par un grand nombre de personnes. De plus, grâce au fait que ces améliorations deviennent publiques, d’autres organisations aux besoins similaires peuvent bénéficier de celles-ci sans coût supplémentaire. Cela maximise donc l’utilité de l’argent du contribuable, ce que toute administration publique souhaite (ou devrait souhaiter).

Politique d’approvisionnement

Si les budgets informatiques des agences gouvernementales sont clairement mieux utilisés dans l’amélioration du logiciel libre et dans son adaptation à leurs besoins, pourquoi est-ce si rarement ce que l’on fait ? L’équivalence des fonctionnalités pour les types de logiciels les plus utilisés a depuis longtemps été atteinte, la convivialité est la même, la robustesse et le coût total de possession aussi. La notoriété et la connaissance sont bien sûr toujours des problèmes, mais le véritable obstacle à l’acquisition de services en logiciel libre réside dans les conditions légales et administratives sous lesquelles cela doit se produire. Changer ces conditions nécessite du travail, au niveau de la politique et du lobbying. C’est rarement possible dans le contexte d’un projet individuel. Heureusement, des organisations telles que la Free Software Foundation Europe et sa sœur aux États-Unis font du lobbying en notre nom et font lentement changer les choses. Jetons un coup d’œil à deux problèmes centraux d’ordre structurel.

Des licences, pas des services

Beaucoup de budgets informatiques sont structurés de telle façon qu’une partie de l’argent est mise de côté pour l’achat d’un nouveau logiciel ou pour le paiement continu de l’utilisation d’un logiciel sous forme de licences. Comme il était inimaginable pour ceux qui ont construit ces budgets qu’un logiciel puisse être autre chose qu’un bien achetable, représenté par une licence propriétaire, il est souvent difficile ou impossible pour les décideurs informatiques de dépenser cette même somme d’argent pour des services. La comptabilité de gestion n’en entendra simplement pas parler. Cela peut mener à la situation malheureuse où une organisation a la volonté et l’argent pour améliorer un morceau de logiciel libre afin qu’il convienne parfaitement à ses besoins, pour le déployer et pour le faire tourner pendant des années et envoyer ses contributions à la communauté, en retour, mais où cela ne peut se faire tant que toute l’affaire n’est pas enveloppée dans une vente et un achat artificiels et non nécessaires d’un produit imaginaire basé sur une licence libre.

Pièges légaux

Les cadres légaux pour les fournisseurs de logiciels supposent souvent que quiconque signant la production d’un logiciel exerce le plein contrôle des copyrights, marques déposées et brevets afférents. L’organisation cliente attend une garantie contre des risques variés de la part du fournisseur. Dans le cas où une société ou une personne produit une solution ou un service basé sur du logiciel libre, cela est souvent impossible car il y a d’autres titulaires de droits qui ne peuvent pas être raisonnablement impliqués dans l’arrangement contractuel. Ce problème apparaît plus ostensiblement dans le contexte des brevets logiciels. Il est pratiquement impossible pour un fournisseur de services de s’assurer contre les risques de contentieux de brevets, ce qui rend très risqué pour lui d’endosser la pleine responsabilité.

Prix

Historiquement, l’argument le plus vendeur du logiciel libre donné au grand public a été son potentiel pour d’économie d’argent. Le logiciel libre a en effet permis des économies à grande échelle pour beaucoup d’organisations depuis de nombreuses années. Le système d’exploitation GNU/Linux a été le fer de lance de ce développement. Ceci en raison de sa libre disponibilité au téléchargement qui a été perçue en opposition frappante avec les licences onéreuses de son principal concurrent, Microsoft Windows.

Pour quelque chose d’aussi utilisé et utile qu’un système d’exploitation, il est indéniable que le bénéfice des coûts structurels vient des coûts de développement qui sont répartis sur de nombreuses parties. Malheureusement, l’espoir que ceci reste vrai pour tous les logiciels libres a mené à la pensée irréaliste que les coûts seront toujours réduits, largement et immédiatement. D’après notre expérience, ce n’est pas vrai. Comme nous l’avons vu dans les sections précédentes de cet ouvrage, il est très logique de tirer le meilleur parti de l’argent dépensé dans l’utilisation de logiciels libres et il est probable qu’au fil du temps et pour de nombreuses organisations de l’argent puisse être économisé. Mais pour une agence isolée qui cherche seulement à déployer un logiciel libre, il devra y avoir un investissement initial et un coût nécessaire associé pour obtenir le niveau de maturité et de robustesse nécessaire.

Alors que cela semble largement raisonnable aux professionnels des opérations informatiques, il est souvent plus difficile de convaincre de cette vérité leurs supérieurs avec le bilan financier. Surtout lorsque la potentielle économie de moyens financiers a initialement été utilisée comme un argument pour faire entrer le logiciel libre, il peut s’avérer très difficile de gérer efficacement les attentes futures. Plus vite les décideurs sauront exactement de façon claire combien et dans quoi ils investissent, mieux ils accepteront de le faire sur le long terme

Le meilleur rapport qualité-prix est toujours attirant et un fournisseur de services informatiques qui cessera d’être disponible à cause de la pression des prix et n’obtiendra pas suffisamment de réussite économique est aussi peu attractif dans le logiciel libre que dans les modèles économiques basés sur des licences propriétaires. Il est donc aussi dans l’intérêt des clients que les estimations de coûts soient réalistes et que les conditions économiques dans lesquelles le travail est effectué soient durables.

Conclusion

Notre expérience montre qu’il est possible de convaincre des organismes du secteur public de dépenser de l’argent dans des services basés sur des logiciels libres. C’est une proposition intéressante qui offre une plus-value et qui a un sens politique. Malheureusement, il existe encore des barrières structurelles. Mais avec l’aide de pionniers dans le secteur public, elles peuvent être contournées. Avec un soutien suffisant de notre part à tous, ceux qui travaillent pour le logiciel libre au niveau politique finiront par les surmonter. Une communication claire et honnête sur les réalités économiques et techniques peut favoriser des partenariats efficaces qui amènent des bénéfices à la communauté du logiciel libre, aux administrations publiques utilisant ces logiciels et à ceux qui les fournissent avec les services nécessaires dans un cadre viable et durable.

« Comment ma fille a fait son TPE grâce au Framapad », tel est le titre d’un court billet du blog de Nicolas Fressengeas, billet rédigé ici justement par sa fille.

Nous ne résistons pas au plaisir de le reproduire ici tant nous sommes fiers nous rendre ainsi utiles, à fortiori dans l’éducation.

Pour rappel TPE est l’acronyme de Travaux personnels encadrés et c’est l’une des rares fois où l’on se retrouve à travailler réellement en groupe au cours de sa scolarité.

Cette année, comme pour tous les élèves de première L, nous devions préparer un TPE. Un dossier d’une vingtaine de pages, sur le sujet de notre choix. Pour cela, le lycée nous prévoit environ six mois de travail. Alors lorsque l’on réalise, une semaine avant la date du ramassage des dossiers, qu’il reste la moitié du TPE à rédiger, on se retrouve un peu pris de panique.

Que faire alors ?

Plus le temps d’organiser des séances de travail collectives ! Heureusement, mon père m’a alors présenté le Framapad. Il m’a suffit d’envoyer l’adresse à mes deux coéquipières, pour pouvoir travailler ensemble, le Framapad étant relativement simple à utiliser, notamment grâce au chat, et au système de couleur ! Ainsi, en une soirée, notre dossier fut entièrement rédigé !

L’histoire ne dit pas quel était le sujet du TPE en question mais peut-être que mademoiselle viendra nous en faire confidence dans les commentaires 😉

Le ”community manager” de SourceForge se rebiffe : ce n’est pas parce que la plateforme héberge une foultitude de projets libres morts ou non actifs que SourceForge est lui-même en train de mourir.

On ne peut lui donner tort, mais la grande question reste en suspens : pourquoi tout le monde (ou presque) s’en va désormais sur GitHub ?

Peut-être trouvera-t-on réponse dans les commentaires 😉

Le mythe de la mort de SourceForge

The myth of the death of SourceForge

Rich Bowen – 07 décembre 2012 – Notes in the Margin (blog personnel)
(Traduction : tcit, Sky, goofy, KoS, Tr4sK, audionuma, Asta, Rudloff)

Je suis le community manager de SourceForge. À ce titre, je vois tous les jours des tweets annonçant la mort imminente de SourceForge. La preuve fournie est le nombre important de projets morts sur SourceForge.

Cela reflète une profonde ignorance de la façon dont l‘open source (et le développement logiciel en général) fonctionne.

Une des choses qui font du développement logiciel un hobby irrésistible est que cela ne coûte presque rien d’échouer. Vous avez une idée ? Chouette. Essayez-la. Ça a marché ? Non ? Bah, ce n’est pas une grande perte. Passez à la prochaine idée. Mais publiez donc ouvertement vos notes pour que d’autres personnes puissent y jeter un coup d’œil et voir si elles peuvent faire mieux.

La plupart des projets de logiciels échouent. Désolé. C’est la réalité.

Ainsi, le fait que SourceForge contienne de nombreux projets ayant échoué n’est pas une indication de la mort de SourceForge. Cela indique son âge. SourceForge a 12 ans. Github est encore un bébé et n’a donc encore qu’un petit nombre de projets morts. Attendez quelques années et nous entendrons dire que Github est l’endroit où vont les projets pour mourir et que le nouveau truc à la mode est beaucoup mieux.

Ceci est un non-sens et n’est donc pas un bon instrument de mesure. Les forges open source sont un endroit où vous pouvez essayer une idée, à peu de frais et, si nécessaire, trouver là où ça échoue. Il est rare de réussir.

Bien sûr, cela amène la question qui est toujours posée : pourquoi ne purgeons-nous pas tous les projets morts ? Eh bien, si vous y réfléchissez quelques minutes, vous verrez que ce n’est pas faisable. Qui suis-je pour déterminer quel projet est mort et lequel ne l’est pas ? J’ai un projet vieux de 10 ans, que je n’ai pas touché depuis 8 ans mais que j’ai l’intention de réécrire ce week-end. Que se passerait-il si nous l’avions effacé la semaine dernière ? Plus important, les notes et le code source de votre projet « mort » ou « loupé » mènent souvent à un fork qui lui, réussit. Purger les références historiques ne rend service à personne.

Pendant ce temps, je passe des heures chaque jour à faire la promotion des nouvelles versions et des développements de projets open source très actifs et très passionnés. Il ne se passe pas une semaine où, avec un tweet pour chacune des nouvelles versions, ma femme ne me dit pas « wow, tu tweetes vraiment énormément ! » Un tweet à peu près chaque heure, 24 heures par jour, chaque jour des 9 derniers mois. Ça fait un paquet de projets actifs. Pas morts du tout.

C’est un grand honneur d’être le community manager de SourceForge, de travailler avec des dizaines de milliers de projets vivants et passionnés. SourceForge reste un élément très important dans l’écosystème open source, avec de nouveaux projets créés chaque jour. Certains de ces projets sont destinés à devenir des succès, d’autres non. C’est juste comme cela que ça marche, et ça n’indique le déclin d’aucune des forges open source où cela arrive.

Crédit photo : Joiseyshowaa (Creative Commons By-Sa)

La question de savoir si oui ou non il y a aura des DRM dans le HTML5 est absolument fondamentale pour le Web de demain. Ce n’est pas une question tehnique, c’est une question de partage (ou pas).

C’est pourquoi nous vous avions proposé la cinglante réponse de Cory Doctorow à Tim Berners-Lee. C’est pourquoi aussi nous avons traduit cet article très clair de l’Electronic Frontier Foundation qui en appelle à se mobiliser, par exemple en signant la pétition lancée par la Free Software Foundation.

Défense du web ouvert : pas de DRM dans les standards W3C

Defend the Open Web: Keep DRM Out of W3C Standards

Peter Eckersley et Seth Schoen – 20 mars 2013 – EFF.org
(Traduction : tcit, ZeHiro, audionuma, goofy, audionuma, Asta)

Un nouveau front est ouvert dans la bataille contre les DRM. Ces technologies, qui sont censées permettre le respect du copyright, n’ont jamais permis de rémunérer les créateurs. Par contre, que ce soit volontairement ou par accident, leur véritable effet est d’interférer avec l’innovation, l’usage légitime, la concurrence, l’interopérabilité et notre droit légitime à posséder nos biens.

C’est pourquoi nous avons été consternés d’apprendre qu’une proposition est actuellement à l’étude au sein du groupe de travail HTML5 du World Wide Web Consortium (W3C) pour intégrer les DRM dans la prochaine génération de standards fondamentaux du Web. Cette proposition est dénommée Encrypted Media Extensions (Extensions pour les médias chiffrés, EME). Son adoption représenterait une évolution catastrophique et doit être stoppée.

Durant les deux dernières décennies, il y a eu un combat continu entre deux visions de la manière dont les technologies d’Internet doivent fonctionner. L’une des philosophies est que le Web doit être un écosystème universel basé sur des standards ouverts et que quiconque peut implémenter sur un pied d’égalité, n’importe où, n’importe quand, sans permissions ni négociations. C’est cette tradition technologique qui a produit HTML et HTTP pour commencer, et des innovations qui ont marqué leur époque comme les wikis, les moteurs de recherche, les blogs, les messageries sur le Web, les applications écrites en JavaScript, les cartes en ligne réutilisables, et une centaine de millions de sites Web que ce paragraphe serait trop court pour énumérer.

L’autre vision est incarnée par les entreprises qui ont essayé de s’approprier le contrôle du Web avec leurs propres extensions propriétaires. Cela s’est manifesté avec des technologies comme Flash d’Adobe, Silverlight de Microsoft, et des pressions venant d’Apple, des fabricants de téléphonie, et d’autres, en faveur de plateformes hautement restrictives. Ces technologies sont conçues pour n’être disponibles qu’auprès d’une seule source ou nécessiter une autorisation pour toute nouvelle implémentation. À chaque fois que ces techniques sont devenues populaires, elles ont infligé des dommages aux écosystèmes ouverts qui les entourent. Les sites Web qui utilisent Flash ou Silverlight ne peuvent en général pas être référencés correctement, ne peuvent pas être indexés, ne peuvent être traduits automatiquement, ne peuvent être consultés par les personnes en situation de handicap, ne fonctionnent pas sur tous les terminaux de consultation, et posent des problèmes de sécurité et de protection de la vie privée à leurs utilisateurs. Les plateformes et les équipements qui restreignent la liberté de l’utilisateur freinent inévitablement des innovations importantes et entravent les compétitions sur le marché.

La proposition EME est entachée par plusieurs de ces problèmes car elle abandonne explicitement la responsabilité de la question de l’interopérabilité et permet aux sites Web de requérir des logiciels propriétaires de tierces-parties, voire du matériel ou un système d’exploitation spécifiques (tout cela mentionné sous le nom générique de « content decryption modules » (« modules de déchiffrage du contenu », CDM), dont aucun n’est spécifié par EME). Les auteurs d’EME soutiennent que les CDM, ce qu’ils font et d’où ils viennent, est totalement hors du champ d’EME, et qu’EME ne peut être considéré comme un DRM puisque tous les CDM ne sont pas des DRM. Néanmoins, si l’application client ne peut prouver qu’elle exécute le module propriétaire spécifique que le site réclame, et n’a donc pas de CDM qualifié, elle ne peut afficher le contenu du site. De manière perverse, c’est exactement à l’opposé des raisons qui font que le W3C existe. Le W3C est là pour créer des standards lisibles, qui soient implémentables par le public et qui garantissent l’interopérabilité, et non pas pour favoriser une explosion de nouveaux logiciels mutuellement incompatibles et de sites et services qui ne sont accessibles qu’à certains équipements ou applications. Mais la proposition EME va justement apporter cette dynamique anti-fonctionelle dans HTML5, risquant même un retour au « bon vieux temps d’avant le Web » où l’interopérabilité était volontairement restreinte.

Étant donné l’extrême méfiance de la communauté des standards ouverts à l’encontre des DRM et de leurs conséquences sur l’interopérabilité, la proposition de Google, Microsoft et Netflix affirme que « aucun DRM n’est ajouté à la spécification HTML5 » par EME. C’est un peu comme dire « nous ne sommes pas des vampires, mais nous allons les inviter chez vous ».

Les promoteurs d’EME semblent affirmer que ce n’est pas un modèle de DRM. Mais l’auteur de la spécification Mark Watson a admis que « effectivement, nous nous intéressons aux cas d’utilisation que la plupart des gens appellent DRM » et que les implémentations nécessiteront par nature des aspects secrets qui sont hors du champ de la spécification. Il est difficile de soutenir que EME n’a rien à voir avec les DRM.

Les propositions sur les DRM au W3C sont là pour une raison simple : il s’agit d’une tentative d’apaiser Hollywood, qui est irrité par Internet au moins depuis que le Web existe, et a toujours réclamé qu’une infrastructure technique avancée permette de contrôler ce qui se passe sur l’ordinateur du public. Le sentiment est que Hollywood ne permettra jamais la distribution des films sur le Web s’il n’est pas possible de les accompagner de DRM. Mais la crainte que Hollywood puisse récupérer ses billes et quitter le Web est illusoire. Chaque film que Hollywood distribue est déjà disponible pour ceux qui veulent réellement pirater une copie. Une énorme quantité de musique est vendue par iTunes, Amazon, Magnatunes et des dizaines d’autres sites sans qu’il n’y ait besoin de DRM. Les services de streaming comme Netflix et Spotify ont réussi parce qu’ils proposent une expérience plus pratique que le piratage, pas parce que les DRM favorisent leur modèle économique. La seule explication raisonnable pour que Hollywood réclame des DRM est que les producteurs de films veulent contrôler comment les technologies grand public sont conçues. Les producteurs de films ont utilisé les DRM pour faire respecter des restrictions arbitraires sur leurs produits, comme l’interdiction de l’avance rapide ou des restrictions géographiques, et ont créé un système complexe et onéreux de « mise en conformité » pour les entreprises technologiques qui donnent à un petit groupe de producteurs de contenu et aux grandes sociétés du secteur des technologies un droit de veto sur l’innovation.

Trop souvent, les entreprises technologiques se sont lancées dans une course l’une contre l’autre pour bâtir un fouillis logiciel qui corresponde aux caprices de Hollywood, abandonnant leurs utilisateurs dans cette course. Mais les standards ouverts du Web sont un antidote à cette dynamique, et ce serait une terrible erreur pour la communauté du Web de laisser la porte ouverte à la gangrène anti-technologique de Hollywood dans les standards W3C. Cela minerait l’objectif principal de HTML5 : créer un éco-système ouvert alternatif à toutes les fonctionalités qui manquaient dans les standards Web précédents, sans les problèmes de limitations des équipements, d’incompatibilité entre plateformes et l’absence de transparence qui fut créée par des plateformes comme Flash. HTML5 était censé être mieux que Flash, et en exclure les DRM est exactement ce qui le rendrait meilleur.

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

Traduction Framalang : Ouve, Julius22, Sphinx, CoudCoud, grosfar, lum’, goofy, peupleLà, lamessen

Nous ne sommes pas fous… Nous organisons des conférences !

Gareth J. Greenaway

Gareth J. Greenaway s’est impliqué activement dans la communauté du logiciel libre et open source depuis 1997 après avoir découvert Linux. Sa contribution majeure a consisté à regrouper des gens ayant la même opinion pour apprendre et expérimenter de nouveaux éléments de logiciel libre et open source. Cette implication a débuté avec un petit groupe d’utilisateurs de Linux (un « GUL ») et s’est développée avec l’organisation de la « Southern California Linux Expo », aussi connue sous le nom de SCALE. En tant que membre fondateur de cet évènement, Gareth remplit actuellement deux fonctions importantes au sein de l’organisation. La première est la gestion des conférences et la seconde concerne les relations avec la communauté.

J’ai commencé à écrire cette section avec ce que je pensais être les besoins et les étapes pour organiser une conférence sur le libre et l’open source. Cependant, une grande partie de ce que je trouvais à dire avait déjà été abordé par Dave Neary, expert en gestion de communautés. Donc, pour éviter de répéter et de recouper ce que Dave voulait expliquer, j’ai décidé de partager différentes histoires de l’organisation de SCALE et les leçons que j’en ai tiré pendant ces années.

Trop d’énergie !

SCALE a commencé il y a maintenant neuf ans avec des membres de trois groupes locaux d’utilisateurs de Linux, ce n’était à l’origine qu’un modeste évènement régional organisé par l’un de ces groupes. La première expérience fut vraiment enrichissante. Beaucoup de leçons en ont été tirées. On courait un peu partout et l’évènement semblait se dérouler à une vitesse folle. Étant donné qu’aucun de nous n’avait encore organisé d’évènement où il fallait se soucier des risques de surtension ou de consommation électrique, nous n’y avons pas pensé, et, du coup, nous avons dû ré-enclencher les disjoncteurs de la salle plusieurs fois pendant l’évènement.

Ça va marcher… c’est sans fil !

Le deuxième SCALE a pris en compte un grand nombre de leçons apprises l’année précédente mais un nouveau lieu de rencontre allait donner de nouvelles leçons. Le centre de conférences de Los Angeles est le lieu où s’est tenu SCALE 2, il fournissait un espace bien plus grand pour installer l’évènement. Le nouveau lieu nous a aussi permis d’apprendre notre première leçon sur les contrats avec un grand organisme pour gérer les choses telles que l’équipement audio et vidéo, l’accès à Internet et le matériel d’exposition.

Compte tenu de la situation de l’évènement à l’intérieur du centre de conférences, nous avons dû positionner les comptoirs d’enregistrement dans une zone qui, tout en étant visible des participants qui arrivaient, se trouvait à une certaine distance du reste du salon. Nos possibilités pour fournir un accès réseau à la zone d’enregistrement étaient limitées car les règles de protection anti-incendie proscrivaient l’utilisation de câbles ; le sans-fil était donc l’unique option.

Tout a été mis en place très tôt le jour du salon et fonctionnait parfaitement bien, jusqu’à ce que cela cesse mystérieusement de marcher. La connexion sans fil, fournissant l’accès au réseau indispensable au comptoir d’enregistrement, a tout simplement disparu. Nous avons alors vécu beaucoup de tentatives de dépannages, beaucoup de déplacements d’équipements et d’antennes et beaucoup de frustration. « Ça devrait fonctionner. » était la seule conclusion à laquelle tout le monde pouvait parvenir, sans trop savoir pourquoi cela ne fonctionnait pas.

Soudain, un des membres de l’équipe, qui s’était tenu à l’écart de la séance de dépannage, a appelé tout le monde à venir à l’endroit où il se trouvait. En face d’une grande fenêtre qui surplombait un grand hall de réunion, nous avons tout à coup tous vu ce qu’il désirait nous faire voir. En-dessous de nous il y avait des dizaines de lumières clignotantes, tournantes et pulsantes qui nous regardaient. Des centaines d’appareils électroniques avec des lumières clignotantes, des sirènes et des panneaux à LED (diodes électro-luminescentes), interférant narquoisement avec les signaux sans fil de nos pauvres points d’accès. Nous avons soudain réalisé que nos heures de travail à tenter de résoudre ce problème de sans-fil avaient été vaines. Finalement, nous avons déroulé un câble Ethernet, l’avons scotché de la manière la plus sécurisée que nous avons pu, et nous avons dit une petite prière pour que le chef des pompiers ne fasse pas d’inspection surprise.

Soirées de gala, tireurs d’élite et disparition mystérieuse de mallette IBM

L’une des anecdotes les plus célèbres dans l’histoire de SCALE est sans doute celle des incidents et péripéties qui sont survenus pendant SCALE 3. Ces aventures sont bien connues, et si vous assistiez à SCALE cette année-là, vous n’avez pas pu y échapper.

Le troisième SCALE devait se dérouler encore une fois au centre de conférences de Los Angeles au L.A. Convention Center. Tout le travail de planification et d’organisation avait été mené en amont pendant de nombreux mois et tout s’annonçait bien. Trois semaines environ avant l’évènement, nous avons reçu des informations à propos de plusieurs routes qui seraient fermées autour du centre de conférences à cause d’une soirée de gala qui devait avoir lieu. À cause de ces fermetures de routes, il n’y avait plus qu’une voie d’accès pour accéder au centre et en repartir, ce qui est loin d’être idéal. Fort heureusement, nous avons eu le temps d’avertir tous ceux qui venaient à l’évènement et de leur indiquer les routes fermées à la circulation et les itinéraires alternatifs. Cette année-là, c’était aussi la première fois que SCALE devait se dérouler sur deux jours, dans l’espoir de répartir un peu les choses pour ne pas être autant dans la précipitation et la frénésie.

L’un des plus anciens sponsors et exposants de SCALE est IBM. Ils ont toujours été une plus-value appréciée, mais, malheureusement, leur participation s’est généralement accompagnée de quelques difficultés. La veille de l’évènement, comme d’habitude, avait été réservée à la mise en place pour permettre à l’équipe de SCALE de tout installer et aux exposants de préparer leurs stands. C’est également le jour de réception de tous les paquets envoyés par les exposants. IBM avait prévu de présenter une nouvelle ligne de serveurs sur le salon et avait fait expédier un de ces serveurs au centre de conférences ; malheureusement, il n’avait pas été livré sur leur stand et personne dans le centre de conférences ne savait où pouvait bien se trouver le colis. Malgré de nombreuses heures à chercher dans tous les endroits possibles à l’intérieur du centre de conférences, nous n’avions pas la moindre piste.

Il se trouve que le gala qui devait avoir lieu quelques jours plus tard avait loué un certain nombre de pièces pour en faire des bureaux et des espaces de stockage. Dans un éclair de génie, le coordinateur de l’évènement qui aidait à la recherche suggéra que nous pourrions chercher dans un de leurs espaces de stockage en espérant que la mallette d’IBM ait été livrée là par accident. La pièce en question était un petit placard de rangement dans lequel nous nous sommes trouvés face à des montagnes de boîtes, du sol jusqu’au plafond, remplies de tickets pour la soirée de gala à venir. Derrière ces boîtes, dans un coin, il y avait une grande mallette bleue avec le logo IBM bien visible. Crise évitée !

Le reste de l’évènement se déroula sans heurts et pratiquement sans incidents. Alors que l’évènement se finissait, une petite foule commença à se former près de grandes fenêtres donnant sur la rue. Alors que je passais à cet endroit, je pris conscience de ce que tout le monde était en train de regarder. Plusieurs silhouettes, toutes vêtues de noir, se déplaçaient sur les toits des bâtiments le long de la rue. Toutes ces silhouettes portaient des fusils de précision et étaient des membres de l’équipe du SWAT de la police de Los Angeles qui se préparaient pour la soirée de gala qui allait avoir lieu plus tard. Ce fut sans conteste une sortie mémorable du centre de conférences.

Pas de chambre à l’hôtel

Le quatrième SCALE a occasionné un nouveau changement de lieu. Cette fois-ci, nous sommes passés à un hôtel à la place d’un centre de conférences. Comme avec les années de plus en plus de personnes voyageaient pour assister à SCALE et séjournaient dans des hôtels proches, nous avons décidé d’étudier la possibilité que SCALE ait lieu dans un hôtel. Nous avons parcouru la région et avons fini par consulter un organisateur d’évènements pour trouver le bon endroit pour le nôtre. En nous installant dans un hôtel proche de l’aéroport de Los Angeles, la planification commença. Tenir l’évènement dans un hôtel nous a rapidement confrontés à de nouvelles problématiques propres aux hôtels. Une des plus importantes leçons que nous avons alors apprises a été de s’assurer que tous les contrats comportaient une clause convenue d’annulation.

À peu près cinq semaines avant l’évènement, nous avons reçu un appel des responsables du lieu qui nous informaient que leur entreprise annulait notre évènement pour attribuer le lieu à une autre manifestation. Cela a évidemment été un choc pour nous et nous a plongé dans la plus grande confusion. Le contrat avec l’hôtel ne comprenait pas une ligne sur les cas de résiliation pour changement de lieu, mais précisait seulement qu’ils pouvaient annuler la manifestation sans aucun motif.

Après un grand nombre de coups de téléphone et de tractations avec les responsables du lieu initial, ils ont fini par accepter de nous indemniser pour nous aider à migrer vers un lieu de remplacement. Lequel nous a consenti les mêmes conditions pour tout ce qui concernait l’électricité, l’accès à Internet et l’équipement audio et vidéo. Tout s’est bien passé et l’équipe de SCALE en a tiré une précieuse leçon sur la façon de négocier ses futurs contrats.

Rappel !

Tout compte fait, organiser une conférence est une entreprise gratifiante et un excellent moyen de rendre à la communauté ce qu’elle nous a apporté. Les conférences constituent un moment privilégié car elles permettent des échanges en personne dans un monde qui repose couramment sur des moyens de communication virtuels.

Voici les conseils que je donnerais à des organisateurs de conférences :

• commencez modestement, ne vous lancez pas dans un gigantesque évènement dès la première année ;
• saisissez les occasions, faites des erreurs, n’ayez pas peur de l’échec ;
• tout est dans la communication !

Il y a un an le développeur James Whittaker quittait Google et le faisait savoir dans un article cinglant qui en disait long sur l’évolution de l’entreprise, obnubilée par la publicité et la concurrence de Facebook.

Nous avons choisi de le traduire car les arguments nous semblent malheureusement tout aussi valables aujourd’hui.

Ah, oui, et où est-il allé ensuite ? Réponse ici : Why I joined Microsoft 😉

Pourquoi j’ai quitté Google

Why I left Google

James Whittaker – 13 mars 2012 – Blog personnel
(Traduction : ACA, VifArgent, KoS, Eijebong, Alpha, angezanetti, Penguin, audionuma, P3ter, KoS + anonymes)

Ok, je cède. Tout le monde veut savoir pourquoi je suis parti, et répondre individuellement n’est pas forcément évident, voici donc les détails de la version longue. Vous pouvez en lire un bout (je vais à l’essentiel au troisième paragraphe) ou la lire en entier. Mais avant, une remarque préalable : il n’y pas de drame, pas de grand discours, pas de critiques d’anciens collègues et rien de plus que ce que vous pouvez déjà présumer d’après ce qui se dit dans la presse ces jours-ci autour de Google et de son attitude envers la vie privée des utilisateurs et les développeurs. C’est simplement une analyse plus personnelle.

Quitter Google ne fut pas une décision facile. Durant mon séjour là bas je suis devenu passionné par l’entreprise. J’ai fait quatre présentations « Google Developper Day », deux « Google Test Automation Conferences » et j’étais un contributeur prolifique du blog Google test. Des recruteurs m’ont souvent demandé de les aider à embaucher leurs champions. Personne n’avait besoin de me demander deux fois de promouvoir Google et personne ne fut plus surpris que moi quand je fus incapable de continuer à le faire. En fait, les trois derniers mois que j’ai passé à travailler chez Google ont été une énorme déception durant lesquels j’ai essayé en vain de rallumer ma passion.

Le Google qui me passionnait était une société high tech qui poussait ses employés à innover. Le Google que j’ai quitté était une société publicitaire concentrée uniquement sur l’aspect financier.

Techniquement, je suppose que Google à toujours été une entreprise de publicité, mais pendant la majeure partie de ces trois dernières années, ça n’y ressemblait pas. Google était une entreprise de pub uniquement dans le sens où une bonne émission télévisée est une entreprise de pub : avoir un bon contenu attire les publicitaires.

Sous Eric Schmidt, les pubs étaient toujours à l’arrière plan. Google a été lancé comme une usine à innovations, incitant les employés à être entreprenants au travers les prix des fondateurs (NdT : prix accordés aux employés les plus méritants sous forme d’action Google, pour retenir les meilleurs employés à Google), les primes par les pairs et le fameux 20% du temps (NdT : Google permet(tait ?) à ses employés de consacrer 20% de leur temps de travail à des projets personnels). Nos revenus publicitaires nous ont donné de l’aisance pour réfléchir, innover et créer. Les plateformes comme App Engine, Google Labs et l’open source ont servi d’environnements de test pour nos inventions. Le fait que tout ça était payé par une machine à fric complètement bourrée de publicité a échappé à la plupart d’entre nous. Peut-être que les ingénieurs qui travaillent vraiment sur les pubs l’ont senti, mais le reste d’entre nous était convaincu que Google était une entreprise de technologie avant tout et par-dessus tout, une entreprise qui engageait des personnes intelligentes et qui faisait un gros pari sur leur capacité à innover.

De cette machine à innovation sont sortis des produits stratégiquement très importants comme Gmail et Chrome, des produits qui étaient le résultat de l’esprit d’entreprise au plus bas niveau de l’entreprise. Bien sûr, cette innovation emballée crée quelques ratés, et Google n’y a pas échappé, mais l’entreprise a toujours su perdre sans s’entêter et apprendre de ses échecs.

Dans un tel environnement, il n’est pas essentiel d’être au sein de l’exécutif pour réussir. Vous n’avez pas besoin d’être chanceux et d’atterrir sur un projet « sexy » pour construire une grande carrière. N’importe qui ayant des idées ou le niveau pour contribuer, pouvait s’impliquer. J’avais énormément d’opportunités pour quitter Google pendant cette période, mais il était difficile d’imaginer un meilleur endroit pour travailler.

Mais c’était le « bon temps » comme on dit, et ce temps-là n’est plus.

Il se trouve qu’il y a un point où la machine à innover Google a faibli, et ce point est crucial : concurrencer Facebook. Des efforts informels ont produit un duo antisocial avec Wave et Buzz. le réseau social Orkut n’a jamais marché en dehors du Brésil. Comme le dit le proverbe (« le lièvre trop confiant risque une courte sieste »), Google s’est réveillé de son rêve social en voyant son statut d’empereur de la pub menacé.

Google peut bien brandir des publicités à davantage de personnes, Facebook en sait beaucoup plus sur eux. Publicitaires et éditeurs chérissent ce genre d’informations personnelles, tant et si bien qu’ils mettent parfois plus en avant Facebook que leur propre marque. Démonstration n°1 : une entreprise avec la puissance et l’influence de Nike mettant sa propre marque après celle de Facebook ? Aucune entreprise n’a fait ça pour Google et Google en a pris ombrage.

Larry Page a pris lui-même le contrôle pour corriger cette erreur. Le social fut « nationalisé » au sein de l’entreprise, un plan appelé Google+. C’était un nom menaçant qui donnait le sentiment que Google ne suffisait pas. La recherche devait être sociale. Android devait être social. YouTube, jadis heureux de son indépendance, devait l’être… bon, vous avez compris. Encore pire, l’innovation aussi devait être sociale. Les idées qui ne réussissaient pas à mettre Google+ au centre de l’univers étaient une perte de temps.

Tout à coup, 20% signifiait incompétent. Google Labs a fermé. Les prix d’App Engine ont augmenté. Les APIs qui étaient gratuites depuis des années furent dépréciées ou devinrent payantes. Alors que les valeurs entrepreneuriales disparaissaient, un discours moqueur à l’égard de « l’ancien Google » et de ses tentatives ridicules de concurrencer Facebook est apparu pour justifier un « nouveau Google » qui promettrait de faire plus avec moins.

Les jours heureux où Google embauchait des gens intelligents et innovants pour inventer le futur étaient terminés. Le nouveau Google savait au-delà de tout doute à quoi devait ressembler le futur. Les employés n’avaient rien compris et l’intervention des dirigeants allait tout remettre en ordre.

Officiellement, Google a déclaré que « le partage sur le Web était en panne » et rien d’autre que la force cumulée de nos esprits autour de Google+ ne pouvait le réparer. Il y a de quoi admirer une entreprise qui a la volonté de sacrifier des idoles pour rallier ses talents afin de faire face à une menace à l’encontre de ses intérêts. Si Google avait eu raison, l’effort aurait été héroïque et beaucoup d’entre nous voulaient réellement être impliqués dans ce qui serait la solution. Je me suis laissé convaincre. J’ai travaillé sur Google+ comme responsable du développement et j’ai écrit un bout de code. Mais le monde n’a jamais changé ; le partage non plus, n’a pas changé. Dire que nous avons participé paradoxalement ) améliorer Facebook est discutable, mais tout ce dont je disposais n’était en fait que des tests comparatifs à la faveur de Facebook.

Il s’est avéré que le partage n’était pas en panne. Le partage fonctionnait bien et de manière efficace, Google n’en faisait simplement pas partie. Tout le monde autour de nous partageait et semblait plutôt content. Aucun exode des utilisateurs de Facebook ne s’est jamais produit. Je n’aurai même pas pu montrer Google+ une deuxième fois à ma fille, « la vie sociale n’est pas un produit » m’a-t-elle dit après que je lui ai fait une démonstration. « Un réseau social c’est des gens, et les gens sont sur Facebook ». Google était l’enfant-roi qui, après avoir découvert qu’il n’avait pas été invité à la fête, avait organisé la sienne de son côté.

Google+ et moi, ça n’aurait jamais pu marcher. En vérité, je n’ai jamais tellement été intéressé par la publicité. Je ne clique pas sur les pubs. Lorsque Gmail affiche des pubs basées sur les choses que je tape dans mes courriels, cela me fait flipper. Je ne veux pas que mes résultats de recherche contiennent les coups de cœur des abonnés de Google+ (ou de Facebook ou de Twitter). Lorsque je cherche « rue de la soif à Londres », je veux un meilleur résultat que la suggestion sponsorisée « Achetez une rue de la soif de Londres chez Carrefour ».

L’ancien Google a fait fortune avec les publicités parce qu’il proposait du bon contenu. C’était comme à la télévision : faites la meilleure émission et vous aurez le plus de revenus publicitaires des entreprises. Le nouveau Google semble surtout se concentrer sur les entreprises.

Peut être que Google a raison. Peut être que le futur c’est d’en apprendre le plus possible à propos de la vie privée des autres. Peut être que Google est le mieux placé pour savoir quand je devrais appeler ma mère et que ma vie serait meilleure si je fais les soldes chez H&M. Peut être que s’ils me harcèlent en constatant tout ce temps libre dans mon agenda je ferais plus de sport.

Peut être que s’ils affichent une publicité pour un avocat spécialiste du divorce à cause de l’e-mail que j’écris à propos de mon fils de 14 ans en train de rompre avec sa copine, j’aimerais assez cette publicité pour mettre fin à mon propre mariage. Ou peut-être que je réglerai tous ces trucs-là tout seul.

Le Google d’avant était un endroit génial pour travailler. Quid du nouveau ?

-1

Vous venez de crever et vous vous retrouvez malencontreusement sur le bord de la route pour changer votre pneu. Tout d’un coup un policier arrive et vous verbalise parce que vous enfreignez je ne sais quel copyright de la marque de votre véhicule stipulant que vous n’avez pas le droit d’y changer quoi que ce soit. C’est surréaliste et pourtant c’est bien la situation actuelle des téléphones portables.

Quid d’un monde sous contrôle où les objets ne nous appartiennent plus faute d’avoir le droit de les bidouiller ?

Oubliez la bataille du téléphone portable – Nous devrions pouvoir déverrouiller tout ce qui nous appartient

Forget the Cellphone Fight — We Should Be Allowed to Unlock Everything We Own

Kyle Wiens – 18 mars 2013 – Wired Opinion
(Traduction : Alpha, Sphinx, aKa, marc, lgodard, M0tty, jtanguy, Moosh, Floréal, K4ngoo, Texmix + anonymes)

Alors que le Congrès des Etats-Unis travaille sur une loi visant à ré-autoriser le déverrouillage des téléphones portables, regardons le vrai problème en face : les lois issues du copyright qui ont d’abord fait que le déverrouillage devienne illégal. À qui appartiennent les objets que nous possédons ? La réponse avait pour habitude d’être évidente. Dorénavant, avec l’électronique, omniprésente dans tous les objets que nous achetons, la réponse a changé.

Nous vivons dans une ère numérique, et même les produits matériels que nous achetons sont complexes. Le copyright impacte plus de monde qu’auparavant car la frontière entre logiciel et matériel, ente monde physique et numérique, s’amenuise.

Le problème ne se réduit pas seulement au déverrouillage des téléphones portables ; quand on achète un objet, n’importe lequel, nous devrions le posséder. Nous devrions être en mesure de soulever le capot, l’ouvrir, le modifier, le réparer, etc… sans demander la permission au fabriquant.

Sauf que nous ne possédons pas vraiment nos objets (enfin pas dans la totalité), les fabricants sont les vrais propriétaires. Parce que la modification d’un objet moderne requiert un accès à de l’information : du code, des documents de conception, des codes d’erreur, des outils de diagnostic… Les voitures modernes sont des mécaniques puissantes mais également des ordinateurs sophistiqués. Les fours à micro-ondes sont une combinaison de plastique et de microcode. Le silicium imprègne et alimente presque tout ce que nous possédons.

C’est un problème de droits de propriété, et les lois actuelles sur le copyright prennent ce problème à l’envers, transformant les gens ordinaires, comme les étudiants, les chercheurs et les patrons de petites entreprises, en délinquants. Par exemple l’entreprise de télécoms Avaya, qui fait partie du top 500 de Fortune, est connue pour poursuivre des entreprises de services en justice, les accusant de violer le copyright simplement parce qu’elles utilsent un mot de passe pour se connecter à leurs systèmes téléphoniques. Vous avez bien lu : rentrer un mot de passe est considéré comme : une « reproduction de matériel soumis au copyright ».

Les fabricants ont systématiquement utilisé le copyright en ce sens ces 20 dernières années pour limiter notre accès à l’information. La technologie a avancé trop vite par rapport aux lois sur le copyright, les sociétés ont exploité cette latence pour créer des monopoles de l’information à nos dépens et à leur bénéfice. Après des années d’expansion et de soi-disantes améliorations, le copyright a transformé Mickey Mouse en un monstre immortel.

Cela n’a pas toujours été ainsi. Les lois sur le copyright ont été créés à l’origine pour protéger la créativité et promouvoir l’innovation. Mais maintenant, elles font exactement le contraire. Elles sont utilisées pour empêcher les entreprises indépendantes de réparer les nouvelles voitures. Elles rendent presque impossible aux agriculteurs de réparer leur matériel. Et, comme nous l’avons vu ces dernières semaines, elles empêchent les particuliers de déverrouiller leurs propres téléphones portables.

Ce n’est pas juste un problème qui affecte seulement les spécialistes en informatique ; les fermiers sont également touchés. Kerry Adams, un agriculteur dans une ferme familiale de Santa Maria en Californie, a récemment acheté deux machines de transplantation pour la modique somme de 100000$ pièce. Elles sont tombées en panne juste après, et il a dû faire venir un technicien de l’usine pour les faire réparer.

Comme les constructeurs ont mis un copyright sur les notices techniques, les techniciens locaux ne peuvent pas réparer les appareils récents. De plus, les appareils actuels, remplis de capteurs et d’électronique, sont trop complexes pour être réparés sans la notice technique. C’est un problème pour les agriculteurs qui n’ont pas les moyens de payer les frais d’entretien élevés pour de l’outillage qui se détériore assez vite.

Adams a abandonné l’idée de faire réparer ses repiqueurs, c’était tout simplement trop cher de faire venir les techniciens en déplacement jusqu’à son exploitation. À présent, les deux repiqueurs sont à l’arrêt et il ne peut pas s’en servir pour subvenir aux besoins de son exploitation et de sa famille.

Dieu a peut-être donné vie à un fermier, mais les lois sur le copyright ne lui permettent plus de gagner sa vie.

Dans le proche domaine de la mécanique automobile, le copyright est aussi vu comme un étau, restreignant leur capacité à résoudre des problèmes. Les erreurs de code dans votre voiture ? Protégés. Les outils de diagnostic pour y accéder ? Des logiciels propriétaires.

Les nouvelles voitures se sophistiquent année après année, et les mécaniciens ont besoin d’un accès aux informations systèmes pour rester dans la course. Sous la protection du copyright, les constructeurs automobiles ont empêché l’accès des garagistes indépendants aux outils de diagnostic et aux schémas de fonctionnement dont ils ont besoin.

Les mécaniciens n’abandonnent pas pour autant. En septembre dernier, le Massachusetts a acté une loi sur le Droit à Réparer destinée à niveler le champ d’action entre les concessions et les garagistes indépendants. Sous le cri de ralliement de « C’est votre voiture, vous devriez avoir la possibilité de la réparer où vous le souhaitez », la loi a été adoptée à une très large majorité de 86%. Cette loi contourne le copyright, forçant les constructeurs à publier toutes les informations techniques aux propriétaires de véhicules du Massachusetts et aux techniciens système. L’agitation populaire se propage : les législateurs du Maine viennent de mettre en place une législation similaire.

Pendant ce temps, des progrès sont faits vers la légalisation du déverrouillage des téléphones portables. Avec des groupes locaux menant le combat, l’administration Obama a annoncé son soutien à l’annulation de cette interdiction la semaine dernière. Les membres du Congrès ont depuis rédigé pas moins de quatre projets de loi pour légaliser le déverrouillage.

C’est un pas dans la bonne direction mais ce n’est pas assez. Que les choses soient claires : réparer nos voitures, tracteurs, et téléphones portables ne devrait rien avoir à faire avec le copyright.

Tant que le Congrès se concentre simplement sur le déverrouillage des mobiles, il passera à côté du vrai problème. Les sénateurs peuvent adopter cents projets de loi sur le déverrouillage ; dans cinq ans, les grandes entreprises trouveront d’autres revendications de copyright pour limiter le choix des consommateurs. Pour vraiment résoudre le problème, le Congrès doit promulguer une réforme du copyright qui soit significative. Les bénéfices économiques potentiels sont significatifs, étant donné que l’information libre crée des emplois. Les informations techniques sont accessibles librement sur internet pour de nombreux smartphones sur iFixit (mon organisation) et d’autres sites. Ce n’est pas par hasard que des milliers d’entreprises de réparation de mobiles ont fleuri ces dernières années, exploitant les connaissances techniques pour éloigner les téléphones portables cassés des décharges.

Tant que nous serons limités dans notre faculté à modifier et réparer les choses, le copyright, pour tous les objets, entravera la créativité. Il nous en coûtera de l’argent. Il nous en coûtera des emplois. Et cela nous coûte déjà notre liberté.

Crédit photo : Håkan Dahlström (Creative Commons By)