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)

Sources :

• Le blocage des cookies dans Firefox fait polémique (Numerama)
• Ghostery (Extension Firefox)

Crédit : Simon Gee Giraudot (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, Garburst, goofy, peupleLà, audionuma, lamessen

Comment demander de l’argent

Selena Deckelmann

Selena Deckelmann est une importante contributrice de PostgreSQL. Elle donne des conférences dans le monde entier sur les logiciels libres, les communautés de développeurs et du trollage. Elle s’intéresse à l’ouverture des données publiques de la ville de Portland, aux poulets d’appartement et à la recherche de solutions pour permettre aux bases de données de fonctionner plus vite.

Elle a fondé Postgres Open, une conférence dédiée aux activités économiques autour de PostgreSQL et au bouleversement du secteur des bases de données. Elle a fondé et co-présidé Open Source Bridge, une conférence de développeurs pour les citoyens open source. Elle a fondé la Conférence PostgreSQL, une brillante série de conférences sur la côte Est et la côte Ouest des États-Unis pour PostgreSQL. Elle fait actuellement partie du comité de programme de PgCon, de la conférence des utilisateurs MySQL et de OSCON Data. Elle est l’une des contributrices au manuel du mentor des Google Summer of Code, et du Guide des Étudiants. Elle est conseillère pour l’initiative Ada et membre du conseil de la société Technocation.

Si je retrace mon parcours depuis la première fois où j’ai démarré un PC sous Linux en 1994, une chose ressort clairement de mon expérience avec l’open source : j’aurais aimé savoir comment demander de l’argent. Demander de l’argent est difficile. J’ai écrit des demandes de subventions, demandé des augmentations, négocié des salaires et des tarifs horaires de consultante et levé des fonds pour des conférences à but non lucratif. Après de nombreuses tentatives et échecs, j’ai développé une méthode qui fonctionne ! Ce qui suit est un condensé des trucs et astuces que j’ai utilisés durant ces cinq dernières années pour augmenter les fonds pour des non-conférences, des sprints de code d’une journée et des conférences de plusieurs jours à propos de la culture et des logiciels open source.

La méthode pour obtenir des fonds pour une conférence comporte six étapes :

1. identifier un besoin ;
2. en parler à quelqu’un ;
3. demander de l’argent ;
4. récupérer l’argent ;
5. dépenser l’argent ;
6. Remercier.

Identifiez un besoin

Votre première mission en tant qu’organisateur de conférences consiste à expliquer pourquoi vous mettez en place une conférence de plus, en quoi elle sera utile à ceux qui y assisteront et quel intérêt un sponsor aurait à vous financer. On appelle ça « écrire un dossier de présentation ». Les éléments principaux d’un tel dossier sont les suivants :

• l’objectif : en un paragraphe, expliquez pourquoi vous faites la conférence. Qu’est-ce qui vous a poussé à rassembler des gens ? Et qui seront les participants ? De quoi parleront-ils une fois là-bas ? Si vous avez un sujet ou un but particulier en tête, mentionnez-le. Expliquez également pourquoi vous avez choisi tel endroit pour l’événement. Y a-t-il un lien avec le sujet de la conférence ? Est-ce que les personnes intéressantes s’y trouvent ? Est-ce qu’il y a un sponsor ? Enfin, mettez à disposition les chiffres intéressants à propos des événements précédents, comme le nombre de participants et des informations pertinentes sur les intervenants ou des détails sur le lieux choisi ;

• les possibilités de mécénat et les bénéfices escomptés : cette partie du dossier va mettre en relief ce que les sponsors peuvent attendre de votre conférence. En règle générale, on y expose les retours sont évalués en termes financiers, mais on peut également y décrire des avantages comme des travaux en nature ou du bénévolat. Commencez simplement. Traditionnellement, les parrainages financiers des événements sont assurés par des services des ressources humaines qui cherchent à embaucher ou par des départements commercial-marketing qui cherchent à faire connaître leurs produits ou services. Voici, entre autres, le genre d’avantages que les sponsors en attendent : la mention du sponsor sur un site Web, dans les messages ou tweets pour les participants, l’accès à la liste des adresses électroniques ou aux informations sur les profils des participants, la présence des logos et des étiquettes sur les pochettes, tours de cou et autres gadgets distribués lors de la conférence, de même au moment des pauses cafés, des repas et casse-croûtes. Il leur faut aussi un stand sur la zone de la conférence et de l’espace publicitaire sur le programme de la conférence. Pensez aussi aux choses originales qui permettront de vous démarquer, à travers le déroulement et le lieu de la conférence. Par exemple, à Portland, il y a une boutique de beignets très populaire, avec un service de livraison. Nous avons trouvé un sponsor, et nous avons obtenu la permission d’amener le camion de livraison juste à l’endroit où nous étions et nous avons servi des beignets gratuitement pour le petit-déjeuner. Vous trouverez ci-dessous des liens pour des exemples de dossiers. Ils correspondent tous à de grosses conférences, donc vous n’obtiendrez peut-être pas le même résultat. J’ai déjà fait un dossier, avec une seule possibilité de parrainage, et l’accord était qu’en échange de la présence d’un de ses employés à la conférence, les organisateurs mentionnaient clairement l’entreprise et la remerciaient pour son soutien. Quelques entreprises : OSCON, Open Source Bridge, MeeGo San Francisco. 

• le contrat : toujours inclure un contrat avec votre dossier. Cela établit les attentes et les engagements ainsi que le calendrier et peut éviter beaucoup de problèmes en chemin. Je ne suis pas un avocat, donc ce qui suit relève plus de mon expérience que des conseils juridiques. Pour les événements plus mineurs, j’écris un contrat très simple qui expose mes attentes : les sponsors promettent de payer à une certaine date et je promets de tenir l’événement à une certaine date. Copier un contrat existant est quelque chose de délicat car les lois changent suivant les différents états et pays. J’ai consulté un avocat qu’un gestionnaire chevronné d’une communauté de l’open source m’avait recommandé. Le cabinet d’avocats a été assez agréable pour gracieusement créer des contrats et réviser des contrats entre nous et les hôtels. Le Software Freedom Law Center peut vous indiquer un avocat approprié si vous n’en avez pas.

Maintenant que vous avez créé le dossier de présentation, vous avez besoin de parler à quelques personnes.

Parlez-en

L’étape la plus difficile pour moi, c’est de faire passer le mot au sujet de mes événements ! Entraînez-vous à présenter votre événement en une ou deux phrases. Transmettez ce qui vous emballe et ce qui devrait emballer les autres.

Au fil des ans, j’ai appris qu’il fallait que je commence à parler SANS DÉLAI à mes connaissances plutôt que de m’inquiéter de savoir exactement quelles étaient les bonnes personnes à qui parler. Faites une liste des personnes à qui parler et que vous connaissez déjà et commencez à cocher cette liste.

La meilleure manière parler de votre projet est de le faire en personne ou au téléphone. Ainsi, vous ne spammez pas les les gens, vous captez leur attention et vous pouvez avoir un retour immédiat sur votre argumentaire. Les gens sont-ils enthousiastes ? Posent-ils des questions ? Ou bien trouvent-ils que c’est rasoir ? À qui d’autre pensent-ils que vous devriez en parler ? Demandez-leur ce qu’ils en pensent et comment vous pourriez rendre votre argumentaire plus attractif, plus intéressant, de sorte qu’ils en aient pour leur argent !

Une fois que vous aurez trouvé les mots-clés de votre argumentaire, écrivez-le et envoyez quelques courriels. Demandez des retours sur votre courriel et terminez toujours par un appel à agir avec une échéance pour la réponse. Gardez la trace des personnes qui répondent, de leurs réponses, et du moment favorable pour une relance de chacune d’elles.

Demandez de l’argent

Armé de votre dossier et de votre argumentaire réglé aux petits oignons, commencez à approcher des sociétés pour financer votre événement. À chaque fois que je lance une nouvelle conférence, je fais une liste de questions à son propos et je réponds à chacune avec une liste de personnes et de sociétés :

• Parmi les personnes que je connais, qui va trouver que c’est une idée géniale et faire la promo de mon événement  (supporters) ;
• Quelles sont les personnes dont la présence à la conférence serait vraiment sympa  (experts reconnus) ;
• Quelles sociétés ont des produits qu’elles voudraient promouvoir à mon événement  (marketing) ;
• Qui voudrait embaucher les personnes qui participent  (recruteurs) ;
• Quels projets libres et open source voudraient recruter des développeurs  (recruteurs open source)

En utilisant ces listes, envoyez votre brochure à travers le monde ! Voici un aperçu de la façon dont j’organise le processus de demande : je commence par envoyer les dossiers de présentation à mes supporters. J’en glisse aussi une copie aux experts, et je les invite à assister à la conférence ou à y intervenir. Je contacte ensuite les agences de publicité, les recruteurs et les recruteurs open source (parfois ça se recoupe !). En parallèle, j’ai généralement ouvert les inscriptions à la conférence et annoncé quelques allocutions ou événements spéciaux. Je croise les doigts pour que ça pousse à quelques inscriptions, que ça aide les sponsors à sentir que cette conférence va certainement avoir lieu et que tout va bien se passer.

Récupérez l’argent

Si tout se passe comme prévu, des sociétés et des individus vont commencer à vous proposer de l’argent. Lorsque cela se produit, vous aurez besoin de deux choses très importantes :

• un modèle de factures ou de devis ;
• un compte en banque pour recueillir les fonds.

Les modèles de factures sont simples à réaliser. J’utilise une feuille de calcul Google que j’actualise pour chaque facture. Vous pourriez facilement utiliser OpenOffice.org ou même TeX (si quelqu’un peut m’envoyer un modèle de facture LaTeX, merci d’avance !). On peut trouver des exemples de factures à l’adresse http://www.freetemplatesdepot.com.

Les éléments les plus importants d’une facture sont : le mot FACTURE, un numéro unique de facture, le nom et les informations de contact du sponsor, le montant que le sponsor est censé verser, les termes de l’accord (à quelle date le sponsor est censé payer, quelles sont les pénalités en cas de non-paiement) et le montant total dû. Il faut ensuite envoyer une copie de la facture à la société. Gardez une copie pour vous !

Certaines sociétés peuvent exiger que vous remplissiez des formulaires plus ou moins complexes pour vous reconnaître, vous ou votre organisation, comme un fournisseur. De la paperasserie. Beurk ! Les délais de paiement pour de grandes entreprises peuvent atteindre deux mois. Les exercices budgétaires des sociétés sont en général annuels. Regardez si une société a un budget disponible pour votre événement et si vous pouvez être inclus dans les prévisions budgétaires de l’année suivante, si vous avez manqué l’occasion pour l’année en cours.

Le compte en banque peut être votre compte personnel, mais c’est risqué pour vous. Pour un événement à plusieurs milliers d’euros, vous préférerez peut-être trouver une ONG ou une association loi de 1901 qui peut détenir et dépenser les fonds en votre nom. Si votre conférence est à but lucratif, vous devriez consulter un comptable sur la meilleure manière de gérer ces fonds. Trouver une organisation sans but lucratif avec laquelle travailler peut se résumer à contacter une fondation qui gère un projet de logiciel libre.

Maintenant, passons à ce qui justifie tout ce processus : dépenser les dons durement acquis !

Dépensez l’argent

Maintenant que vos sponsors ont payé, vous pouvez dépenser l’argent.

Créez un budget qui détaille vos postes de dépenses et quand vous aurez besoin de les dépenser. Je conseille d’obtenir trois devis pour les produits et services qui ne vous sont pas familiers, simplement afin de vous faire une idée sur ce qu’est un prix correct. Faites comprendre aux fournisseurs que vous contactez que vous faites jouer la concurrence.

Une fois que j’ai établi une relation avec une entreprise, j’ai tendance à faire des affaires avec eux d’un an sur l’autre. J’aime avoir de bonnes relations avec les fournisseurs et je trouve que même si je paie un peu plus que si je faisais jouer la concurrence chaque année, je finis par gagner du temps et par obtenir un meilleur service de la part d’un vendeur qui me connaît bien.

Pour les petits événements, vous pouvez garder une trace de vos dépenses dans un tableur assez simple. Pour les projets plus grands, demander à un comptable ou utiliser des logiciels de comptabilité peut être utile. Voici une liste des alternatives libres à Quicken (à différents niveaux et avec différents aspects !).

Le plus important est de garder une trace de toutes vos dépenses et de ne pas dépenser de l’argent que vous n’avez pas ! Si vous travaillez avec une organisation à but non lucratif pour gérer le budget de l’événement, demandez-lui de l’aide et des conseils avant de commencer.

Remerciez

Il existe de nombreuses manières de remercier les gens et les entreprises qui ont apporté leur soutien à votre manifestation. Encore plus important, suivez toutes les promesses que vous avez faites dans le dossier. Communiquez à chaque fois qu’un engagement est tenu !

Durant la manifestation, trouvez des moyens d’entrer en contact avec les sponsors, en désignant un bénévole pour les inscrire et de les inscrire eux-mêmes auprès de vous.

Après la manifestation, assurez-vous de remercier individuellement chaque sponsor et chaque bénévole pour sa contribution. Une association avec laquelle je travaille envoie des remerciements écrits à chaque sponsor en début d’année.

D’une manière générale, la communication est le terreau fertile de la levée de fonds. Porter attention aux sponsors et construire des relations authentiques avec eux aide à trouver plus de sponsors, et à construire votre réputation de bon organisateur de manifestations.

Leçons apprises

Après avoir créé et animé des dizaines de manifestations, les deux aspects les plus importants que j’en tire ont été de trouver des mentors et d’apprendre à bien communiquer.

Les mentors m’ont aidée à transformer des coups de gueule en essais littéraires, du fouillis en dossiers et des conversations difficiles en perspectives. J’ai trouvé des mentors dans des entreprises qui parrainaient mes conférences, et me faisaient des retours détaillés, parfois pénibles. Et j’ai trouvé des mentors parmi les bénévoles qui passaient des centaines d’heures à écrire du logiciel pour mes manifestations, à recruter des orateurs, à documenter ce que nous étions en train de faire, et à poursuivre la conférence après moi.

Apprendre à bien communiquer prend du temps, et c’est l’occasion de faire de nombreuses erreurs. J’ai appris à mes dépens que ne pas développer de relations avec les meilleurs sponsors signifie ne pas être financé l’année suivante ! J’ai aussi appris que les gens sont capables d’une formidable indulgence envers les erreurs, dès lors que vous communiquez tôt et souvent.

Bonne chance dans votre recherche de fonds, et merci de me dire si ce qui précède vous a aidé.

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