Voici le plus long des chapitres de Des routes et des ponts de Nadia Ehgbal que nous traduisons pour vous semaine après semaine (si vous avez raté les épisodes précédents). Il s’agit cette fois-ci des institutions (ici nord-américaines) qui par diverses formes de mécénat, contribuent au développement et au maintien des projets d’infrastructure numérique open source parce qu’elles y trouvent leur intérêt. Pas sûr qu’en Europe et en France ces passerelles et ces coopérations bien comprises entre entreprises et open source soient aussi habituelles…

Traduction Framalang :  Opsylac, Luc, jums, xi, serici, lyn, mika, AFS, Goofy

Les efforts institutionnels pour financer les infrastructures numériques

Il existe des institutions qui s’efforcent d’organiser collectivement les projets open source et aider à leur financement. Il peut s’agir de fondations indépendantes liées aux logiciels, ou d’entreprises de logiciels elles-mêmes qui apportent leur soutien.

Soutien administratif et mécénat financier

Plusieurs fondations fournissent un soutien organisationnel, comme le mécénat financier, aux projets open source : en d’autres termes, la prise en charge des tâches autres que le code, dont beaucoup de développeurs se passent volontiers. L’Apache Software Foundation, constituée en 1999, a été créée en partie pour soutenir le développement du serveur Apache HTTP, qui dessert environ 55 % de la totalité des sites internet dans le monde.

Depuis lors, la fondation Apache est devenue un foyer d’ancrage pour plus de 350 projets open source. Elle se structure comme une communauté décentralisée de développeurs, sans aucun employé à plein temps et avec presque 3000 bénévoles. Elle propose de multiples services aux projets qu’elle héberge, consistant principalement en un soutien organisationnel, juridique et de développement. En 2011, Apache avait un budget annuel de plus de 500 000 $, issu essentiellement de subventions et de donations.

Le Software Freedom Conservancy, fondée en 2006, fournit également des services administratifs non-lucratifs à plus de 30 projets libres et open source. Parmi les projets que cette fondation soutient, on retrouve notamment Git, le système de contrôle de versions dont nous avons parlé plus haut et sur lequel GitHub a bâti sa plateforme, et Twisted, une librairie Python déjà citée précédemment.

On trouve encore d’autres fondations fournissant un soutien organisationnel, par exemple The Eclipse Foundation et Software in the Public Interest. La Fondation Linux et la Fondation Mozilla soutiennent également des projets open source externes de diverses façons (dont nous parlerons plus loin dans ce chapitre), bien que ce ne soit pas le but principal de leur mission.

Il est important de noter que ces fondations fournissent une aide juridique et administrative, mais rarement financière. Ainsi, être sponsorisé par Apache ou par le Software Freedom Conservancy ne suffit pas en soi à financer un projet ; les fondations ne font que faciliter le traitement des dons et la gestion du projet.

Un autre point important à noter, c’est que ces initiatives soutiennent le logiciel libre et open source d’un point de vue philosophique, mais ne se concentrent pas spécifiquement sur ses infrastructures. Par exemple, OpenTripPlanner, projet soutenu par le Software Freedom Conservancy, est un logiciel pour planifier les voyages : même son code est open source, il s’agit d’une application destinée aux consommateurs, pas d’une infrastructure.

Créer une fondation pour aider un projet

Certains projets sont suffisamment importants pour être gérés à travers leurs propres fondations. Python, Node.js, Django et jQuery sont tous adossés à des fondations.

Il y a deux conditions fondamentales à remplir pour qu’une fondation fonctionne : accéder au statut d’exemption fiscale et trouver des financements.

Réussir à accéder au statut 501(c), la loi américaine qui définit les organismes sans but lucratif, peut s’avérer difficile pour ces projets, à cause du manque de sensibilisation autour de la technologie open source et de la tendance à voir l’open source comme une activité non-caritative. En 2013, une controverse a révélé que l’IRS (Internal Revenue Service, service des impôts américain) avait dressé une liste de groupes postulant au statut d’exemption fiscale qui nécessiteraient davantage de surveillance : l’open source en faisait partie. Malheureusement, ces contraintes ne facilitent pas l’institutionnalisation de ces projets.

Par exemple, Russell Keith-Magee, qui était jusqu’à une époque récente président de la Django Software Foundation, a expliqué que la fondation ne pouvait pas directement financer le développement logiciel de Django, sans prendre le risque de perdre son statut 501(c). La fondation soutient plutôt le développement via des activités communautaires.

En juin 2014, la Fondation Yorba, qui a créé des logiciels de productivité qui tournent sous Linux, s’est vu refuser le statut 501(c) après avoir attendu la décision pendant presque quatre ans et demi. Jim Nelson, son directeur exécutif, a été particulièrement inquiété par le raisonnement de l’IRS : parce que leur logiciel pouvait potentiellement être utilisé par des entités commerciales, le travail de Yorba ne pouvait pas être considéré comme caritatif. Une lettre de l’IRS explique :

« Se contenter de publier sous une licence open source tous usages ne signifie pas que les pauvres et les moins privilégiés utiliseront effectivement les outils. […] On ne peut pas savoir qui utilise les outils, et encore moins quel genre de contenus sont créés avec ces outils. »

Nelson a pointé les failles de ce raisonnement dans un billet de blog, comparant la situation à celle d’autres biens publics :

« Il y a une organisation caritative ici à San Francisco qui plante des arbres pour le bénéfice de tous. Si l’un de leurs arbres… rafraîchit les clients d’un café pendant qu’ils profitent de leur expresso, cela signifie-t-il que l’organisation qui plante des arbres n’est plus caritative ? »

Les projets qui accèdent au statut 501(c) ont tendance à insister sur l’importance de la communauté, comme la Python Software Foundation, dont l’objet est de « promouvoir, protéger et faire progresser le langage de programmation Python, ainsi que de soutenir et faciliter la croissance d’une communauté diversifiée et internationale de programmeurs Python ».

En parallèle, certains projets candidatent pour devenir une association de commerce au sens du statut 501(c)(6). La Fondation jQuery en est un exemple, se décrivant comme « une association de commerce à but non-lucratif pour développeurs web, financée par ses membres ». La Fondation Linux est également une association de commerce.

Le deuxième aspect de la formalisation de la gouvernance d’un projet à travers une fondation est la recherche de la source de financement adéquate. Certaines fondations sont financées par des donations individuelles, mais ont proportionnellement de petits budgets.

La Django Software Foundation, par exemple, gère Django, le plus populaire des frameworks web écrits en Python, utilisé par des entreprises comme Instagram et Pinterest. La Fondation est dirigée par des bénévoles, et reçoit moins de 60 000 $ de donations par an. L’année dernière, la Django Software Foundation a reçu une subvention ponctuelle de la part de la Fondation Mozilla.

Parmi les autres sources habituelles de financement on trouve les entreprises mécènes. En effet, les entreprises privées sont bien placées pour financer ces projets logiciels, puisqu’elles les utilisent elles-mêmes. La Fondation Linux est l’un de ces cas particuliers qui rencontrent le succès, et ce grâce la valeur fondamentale du noyau Linux pour les activités de quasiment toutes les entreprises. La Fondation Linux dispose de 30 millions de dollars d’un capital géré sur une base annuelle, alimenté par des entreprises privées comme IBM, Intel, Oracle et Samsung – et ce chiffre continue d’augmenter.

Créer une fondation pour soutenir un projet est une bonne idée pour les projets d’infrastructure très conséquents. Mais cette solution est moins appropriée pour de plus petits projets, en raison de la quantité de travail, des ressources, et du soutien constant des entreprises, nécessaires pour créer une organisation durable.

Node.js est un exemple récent d’utilisation réussie d’une fondation pour soutenir un gros projet. Node.js est un framework JavaScript, développé en 2009 par Ryan Dahl et différents autres développeurs employés par Joyent, une entreprise privée du secteur logiciel. Ce framework est devenu extrêmement populaire, mais a commencé à souffrir de contraintes de gouvernance liées à l’encadrement par Joyent, que certaines personnes estimaient incapable de représenter pleinement la communauté enthousiaste et en pleine croissance de Node.js.

En 2014, un groupe de contributeurs de Node.js menaça de forker le projet. Joyent essaya de gérer ces problèmes de gouvernance en créant un conseil d’administration pour le projet, mais la scission eut finalement lieu, le nouveau fork prenant le nom d’io.js. En février 2015 fut annoncée l’intention de créer une organisation 501(c) (6) en vue d’extraire Node.js de la mainmise de Joyent. Les communautés Node.js et io.js votèrent pour travailler ensemble sous l’égide de cette nouvelle entité, appelée la Fondation Node.js. La Fondation Node.js, structurée suivant les conseils de la Fondation Linux, dispose d’un certain nombre d’entreprises mécènes qui contribuent financièrement à son budget, notamment IBM, Microsoft et payPal. Ces sponsors pensent retirer une certaine influence de leur soutien au développement d’un projet logiciel populaire qui fait avancer le web, et ils ont des ressources à mettre à disposition.

 

Un autre exemple prometteur est Ruby Together, une organisation initiée par plusieurs développeurs Ruby pour soutenir des projets d’infrastructure Ruby. Ruby Together est structuré en tant qu’association commerciale, dans laquelle chaque donateur, entreprise ou individu, investit de l’argent pour financer le travail à temps plein de développeurs chargés d’améliorer le cœur de l’infrastructure Ruby. Les donateurs élisent un comité de direction bénévole, qui aide à décider chaque mois sur quels projets les membres de Ruby Together devraient travailler.

Ruby Together fut conçue par deux développeurs et finance leur travail de  : André Arko et David Radcliffe. Aujourd’hui, en avril 2016, est également rémunéré le travail de quatre autres mainteneurs d’infrastructure. Le budget mensuel en mars 2016 était d’un peu plus de 18 000 dollars par mois, couvert entièrement par des dons. La création de Ruby Together fut annoncée en mars 2015 et reste un projet récent, mais pourrait bien servir de base à un modèle davantage orienté vers la communauté pour financer la création d’autres projets d’infrastructure.

Programmes d’entreprises

Les éditeurs de logiciels soutiennent les projets d’infrastructure de différentes manières.

En tant que bénéficiaires des projets d’infrastructures, ils contribuent en faisant remonter des dysfonctionnements et des bugs, en proposant ou soumettant de nouvelles fonctionnalités ou par d’autres moyens. Certaines entreprises encouragent leurs employés à contribuer à des projets d’une importance critique sur leur temps de travail. De nombreux employés contribuent ainsi de manière significative à des projets open source extérieurs à l’entreprise. Pour certains employés, travailler sur de l’open source fait clairement partie de leur travail. L’allocation de temps de travail de leurs salariés est une des plus importantes façons de contribuer à l’open source pour les entreprises.

Les grandes entreprises comme Google ou Facebook adhèrent avec enthousiasme à l’open source, de façon à inspirer confiance et renforcer leur influence ; elles sont de fait les seuls acteurs institutionnels assez importants qui peuvent assumer son coût sans avoir besoin d’un retour financier sur investissement. Les projets open source aident à renforcer l’influence d’une entreprise, que ce soit en publiant son propre projet open source ou en embauchant des développeurs de premier plan pour qu’ils travaillent à plein temps sur un projet open source.

Ces pratiques ne sont pas limitées aux entreprises purement logicielles. Walmart, par exemple, qui est un soutien majeur de l’open source, a investi plus de deux millions de dollars dans un projet open source nommé hapi. Eran Hammer, développeur senior à Walmart Labs, s’est empressé de préciser que « l’open source, ce n’est pas du caritatif » et que les ressources d’ingénierie gratuites sont proportionnelles à la taille des entreprises qui utilisent hapi. Dion Almaer, l’ancien vice-président en ingénierie de Walmart Labs, a remarqué que leur engagement envers l’open source les aidait à recruter, à construire une solide culture d’entreprise, et à gagner « une série d’effets de levier ».

En termes de soutien direct au maintien du projet, il arrive que des entreprises embauchent une personne pour travailler à plein temps à la maintenance d’un projet open source. Les entreprises donnent aussi occasionnellement à des campagnes de financement participatif pour un projet particulier. Par exemple, récemment, une campagne sur Kickstarter pour financer un travail essentiel sur Django a reçu 32 650 £ (environ 40 000 €) ; Tom Christie, l’organisateur de la campagne, a déclaré que 80 % du total venait d’entreprises. Cependant, ces efforts sont toujours consacrés à des projets  spécifiques et les infrastructures numériques ne sont pas encore vues communément comme une question de responsabilité sociale par les entreprises de logiciel à but lucratif. Cela laisse encore beaucoup de marge aux actions de défense et promotion.

L’un des programmes d’entreprise les plus connus est le Summer of Code de Google (été de programmation, souvent nommé GSoC), déjà mentionné dans ce livre, qui offre de l’argent à des étudiant⋅e⋅s pour travailler sur des projets open source pendant un été. Les étudiant⋅e⋅s sont associé⋅e⋅s à des mentors qui vont les aider à se familiariser avec le projet. Le Summer of Code est maintenu par le bureau des programmes open source de Google, et il a financé des milliers d’étudiant⋅e⋅s.

Le but du Summer of Code est de donner à des étudiants la possibilité d’écrire du code pour des projets open source, non de financer les projets eux-mêmes.

L’an dernier, Stripe, une entreprise de traitement des paiements, a annoncé une « retraite  open source », offrant un salaire mensuel d’un maximum de 7500 dollars pour une session de trois mois dans les locaux de Stripe. À l’origine, l’entreprise voulait uniquement offrir deux bourses, mais après avoir reçu 120 candidatures, le programme a été ouvert à quatre bénéficiaires.

Ces derniers ont été enchantés par cette expérience. L’un d’entre eux, Andrey Petrov, continue de maintenir la bibliothèque Python urllib3 dont nous avons déjà parlé, et qui est largement utilisée dans l’écosystème Python.

À propos de cette expérience, Andrey a écrit :

« La publication et la contribution au code open source vont continuer que je sois payé pour ou non, mais le processus sera lent et non ciblé. Ce qui n’est pas un problème, car c’est ainsi que l’open source a toujours fonctionné. Mais on n’est pas obligé d’en rester là. […] 

Si vous êtes une entreprise liée à la technologie, allouez s’il vous plaît un budget pour du financement et des bourses dans le domaine de l’open source. Distribuez-le sur Gittip [Note : Gittip est maintenant dénommé Gratipay. Le produit a été quelque peu modifié depuis la publication originelle du billet d’Andrew] si vous voulez, ou faites ce qu’a fait Stripe et financez des sprints ambitieux pour atteindre des objectifs de haute valeur. 

Considérez ceci comme une demande solennelle  de parrainage : s’il vous plaît, aidez au financement du développement d’urllib3. »

La retraite open source de Stripe peut servir de modèle aux programmes de soutien. Stripe a décidé de reconduire le programme pour une deuxième année consécutive en 2015. Malgré la popularité de leur programme et la chaude réception qu’il a reçue chez les développeurs et développeuses, cette pratique n’est toujours pas répandue dans les autres entreprises.

Les entreprises montrent un intérêt croissant pour l’open source, et personne ne peut prédire au juste ce que cela donnera sur le long terme. Les entreprises pourraient régler le problème du manque de support à long terme en consacrant des ressources humaines et un budget aux projets open source. Des programmes de bourse formalisés pourraient permettre de mettre en contact des entreprises avec des développeurs open source ayant besoin d’un soutien à plein temps. Alors que les équipes de contributeurs à un projet étaient souvent composées d’une diversité de développeurs venant de partout, peut-être seront-elles bientôt composées par un groupe d’employés d’une même entreprise. Les infrastructures numériques deviendront peut-être une série de « jardins clos », chacun d’entre eux étant techniquement ouvert et bénéficiant d’un soutien solide, mais en réalité, grâce à ses ressources illimitées, une seule entreprise et de ses employés en assureront le soutien.

Mais si on pousse la logique jusqu’au bout, ce n’est pas de très bon augure pour l’innovation. Jeff Lindsay, un architecte logiciel qui a contribué à mettre en place l’équipe de Twilio, une entreprise  performante de solutions de communication dans le cloud, livrait  l’an dernier ses réflexions dans une émission :

« À Twilio, on est incité à améliorer le fonctionnement de Twilio, à Amazon on est incité à améliorer le fonctionnement d’Amazon. Mais qui est incité à mieux les faire fonctionner ensemble et à offrir plus de possibilités aux usagers en combinant les deux ? Il n’y a personne qui soit vraiment incité à faire ça. »

Timothy Fuzz, un ingénieur système, ajoute :

« Pour Bruce Schneier, cette situation tient du servage. Nous vivons dans un monde où Google est une cité-état, où Apple est une cité-état et… si je me contente de continuer à utiliser les produits Google, si je reste confiné dans l’environnement Google, tout me paraît bénéfique. Mais il est quasi impossible de vivre dans un monde où je change d’environnement : c’est très pénible, vous tombez sur des bugs, et aucune de ces entreprises ne cherche vraiment à vous aider. Nous sommes dans ce monde bizarre, mais si vous regardez du côté des cités-états, l’un des problèmes majeurs c’est le commerce inter-étatique : si on doit payer des droits de douane parce qu’on cherche à exporter quelque chose d’Austin pour le vendre à Dallas, ce n’est pas un bon modèle économique. On pâtit de l’absence d’innovation et de partage des idées. On en est là, aujourd’hui. »

Bien que l’argument du « servage » se réfère généralement aux produits d’une entreprise, comme l’addiction à l’iPhone ou à Android, il pourrait être tout aussi pertinent pour les projets open source parrainés. Les améliorations prioritaires seront toujours celles qui bénéficient directement à l’entreprise qui paie le développeur. Cette remarque ne relève pas de la malveillance ou de la conspiration : simplement, être payé par une entreprise pour travailler à un projet qui ne fait pas directement partie de ses affaires est une contrainte à prendre en compte.

Mais personne, pas plus Google que la Fondation Linux ou qu’un groupe de développeurs indépendants, ne peut contrôler l’origine d’un bon projet open source. Les nouveaux projets de valeur peuvent germer n’importe où, et quand ils rendent un service de qualité aux autres développeurs, ils sont largement adoptés. C’est une bonne chose et cela alimente l’innovation.

Aide spécifique de fondation

Deux fondations ont récemment fait part de leur décision de financer plus spécifiquement l’infrastructure numérique : la Fondation Linux et la Fondation Mozilla.

Après la découverte de la faille Heartbleed, la Fondation Linux a annoncé qu’elle mettait en place l’Initiative pour les infrastructures essentielles (Core Infrastructure Initiative, CII) pour éviter que ce genre de problème ne se reproduise. Jim Zemlin, le directeur-général de la Fondation Linux, a réuni près de 4 millions de dollars en promesses de dons provenant de treize entreprises privées, dont Amazon Web Services, IBM et Microsoft, pour financer des projets liés à la sécurité des infrastructures pour les trois ans à venir. La Fondation Linux s’occupe également d’obtenir des financements gouvernementaux, y compris de la Maison-Blanche.

La CII est officiellement un projet de la fondation Linux. Depuis sa création en avril 2014, la CII a sponsorisé du travail de développement d’un certain nombre de projets, dont OpenSSL, NTP, GnuPG (un système de chiffrement des communications) et OpenSSH (un ensemble de protocoles relatifs à la sécurité). La CII se concentre en priorité sur une partie de l’infrastructure numérique : les projets relatifs à la sécurité.

Au mois d’octobre 2015, Mitchell Baker, la présidente de la Fondation Mozilla, a annoncé la création du Programme de soutien à l’open source de Mozilla (Mozilla Open Source Support Program, MOSS) et a promis de consacrer un million de dollars au financement de logiciels libres et open source. Selon Baker, ce programme aura deux volets : un volet « rétribution » pour les projets qu’utilise Mozilla et un volet « contribution » pour les projets libres et open source en général. Grâce aux suggestions de la communauté, Mozilla a sélectionné neuf projets pour la première série de bourses. Ils se disent également prêts à financer des audits de sécurité pour les projets open source importants.

Enfin, certaines fondations contribuent ponctuellement à des projets de développement logiciel. Par exemple, la Python Software Foundation propose aux individus et aux associations des bourses modestes destinées pour la plupart aux actions pédagogiques et de sensibilisation.

Autres acteurs institutionnels

Il existe plusieurs autres acteurs qui apportent diverses formes de soutien aux infrastructures numériques : Github, le capital-risque et le monde universitaire. Si Facebook est un « utilitaire social » et Google un « utilitaire de recherche », tous deux régulant de facto les corps dans leur domaine respectif – alors Github a une chance de devenir « l’utilitaire open source ». Son modèle économique l’empêche de devenir un mastodonte financier (contrairement à Facebook ou Google dont le modèle est basé sur la publicité, alors que Github se monétise par l’hébergement de code pour les clients professionnels, et par l’hébergement individuel de code privé), mais Github est toujours un endroit où aujourd’hui encore l’open source est créée et maintenue.

Github s’est doté de grandes aspirations avec une levée de fonds de capital-risque de 350 millions de dollars, même si l’entreprise était déjà rentable. Si Github assume pleinement son rôle d’administrateur du code open source, l’organisation peut avoir une énorme influence sur le soutien apporté à ces projets. Par exemple, elle peut créer de meilleurs outils de gestion de projets open source, défendre certaines catégories de licences, ou aider les gestionnaires de projets à gérer efficacement leurs communautés.

Github a subi de grosses pressions venant des développeurs qui gèrent certains projets, ces pressions incluent une lettre ouverte collective intitulée « Cher Github », principalement issue de la communauté Javascript. Cette lettre explique : « Beaucoup sont frustrés. Certains parmi nous qui déploient des projets très populaires sur Github se sentent totalement ignoré par vous ». La lettre inclut une liste de requêtes pour l’amélioration de produits, qui pourrait les aider à gérer plus efficacement leurs projets.

Github se confronte de plus en plus à des difficultés largement documentées dans les médias. Auparavant, l’entreprise était connue pour sa hiérarchie horizontale, sans aucun manager ni directive venant d’en haut. Les employés de Github avaient aussi la liberté de choisir de travailler sur les projets qu’ils souhaitaient. Ces dernières années, tandis que Github s’est développée pour atteindre presque 500 employés, l’entreprise a réorienté sa stratégie vers une orientation plus commerciale en recrutant des équipes de vente et des dirigeants, insérés dans un système hiérarchique plus traditionnel. Cette transition d’une culture décentralisée vers plus de centralité s’est faite dans la douleur chez Github : au moins 10 dirigeants ont quitté l’organisation durant les quelques mois de l’hiver 2015-2016, ces départs incluant l’ingénieur en chef, le directeur des affaires financières, le directeur stratégique et le directeur des ressources humaines. En raison de ces conflits internes, Github n’a toujours pas pris position publiquement pour jouer un rôle de promoteur de l’open source et assumer un leadership à même de résoudre les questions pressantes autour de l’open source, mais le potentiel est bel et bien là.

Pour le capital-risque, abordé précédemment, il y a un enjeu particulier dans l’avenir des infrastructures numériques. Comme les outils des développeurs aident les entreprises du secteur technologique à créer plus rapidement et plus efficacement, meilleurs sont les outils, meilleures sont les startups, meilleure sera la rentabilité du capital-risque. Néanmoins, l’infrastructure, d’un point de vue capitaliste, n’est en rien limitée à l’open source mais plus largement focalisée sur les plateformes qui aident d’autres personnes à créer. C’est pour cela que les investissements dans Github ou npm, qui sont des plateformes qui aident à diffuser du code source, ont un sens, mais tout aussi bien les investissements dans Slack, une plateforme de travail collaboratif que les développeurs peuvent utiliser pour construire des applications en ligne de commande connectées à la plateforme (à ce propos, le capital-risque a constitué un fonds de 80 millions dédié au support de projets de développement qui utilisent Slack). Même si le capital-risque apprécie les mécaniques sous-jacentes de l’infrastructure, il est limité dans ses catégories d’actifs : un capitaliste ne peut pas investir dans un projet sans modèle économique.

Enfin, les institutions universitaires ont joué un rôle historique éminent dans le soutien aux infrastructures numériques, tout particulièrement le développement de nouveaux projets. Par exemple, LLVM, un projet de compilateur pour les langages C et C++, a démarré en tant que projet de recherche au sein de l’Université de l’Illinois, à Urbana-Champaign. Il est maintenant utilisé par les outils de développement de Mac OS X et iOS d’Apple, mais aussi dans le kit de développement de la Playstation 4 de Sony.

Un autre exemple, R, un langage de programmation répandu dans la statistique assistée par ordinateur et l’analyse de données, a été d’abord écrit par Robert Gentleman et Ross Ihaka à l’Université d’Auckland. R n’est pas uniquement utilisé par des entreprises logicielles comme Facebook ou Google, mais aussi par la Bank of America, l’Agence américaine des produits alimentaires et médicamenteux et le Service météorologique national américain, entre autres.

Quelques universités emploient également des programmeurs qui ont alors la liberté de travailler à des projets open source. Par exemple, le protocole d’heure réseau ou NTP (Network Time Protocol) utilisé pour synchroniser le temps via Intrenet, fut d’abord développé par David Mills, maintenant professeur émérite de l’université du Delaware — le projet continuant à être maintenu par un groupe de volontaires conduit par Harlan Stenn. Bash, l’outil de développement dont nous parlions dans un chapitre précédent, est actuellement maintenu par Chet Ramsay, qui est employé par le département des technologies de l’information de l’université Case Western.

Les institutions universitaires ont le potentiel pour jouer un rôle important dans le soutien de nouveaux projets, parce que cela coïncide avec leurs missions et types de donation, mais elles peuvent aussi manquer de la réactivité nécessaire pour attirer les nouveaux programmeurs open source. NumFOCUS est un exemple d’une fondation 501(c)(3) qui soutient les logiciels scientifiques open source à travers des donations et  parrainages financiers. Le modèle de la fondation externe peut aider à fournir le soutien dont les logiciels scientifiques ont besoin dans un contexte d’environnement universitaire. Les fondations Alfred P. Sloan et Gordon & Betty Moore expérimentent aussi des manières de connecter les institutions universitaires avec les mainteneurs de logiciels d’analyse des données, dans le but de soutenir un écosystème ouvert et durable.

Chaque semaine, l’équipe Framalang vous propose la traduction d’un chapitre de Roads and Bridges de Nadia Eghbal, une enquête fouillée qui explore les problématiques des infrastructures numériques, et en particulier leur intrication avec l’écosystème open source.

Après avoir exploré dans le précédent chapitre différents types de modèles économiques adaptés aux projets open source (retrouvez ici tous les chapitres antérieurs), l’auteure examine ici les cas de projets s’appuyant sur les dons ou le mécénat : du financement participatif au soutien institutionnalisé d’une entreprise, elle analyse les avantages et les limites de chaque solution, et livre les témoignages de nombreux porteurs de projets ou contributeurs qui relatent leur expérience au cœur de projets aussi divers qu’OpenSSL, jQuery ou encore Node.js.

Traduction Framalang : goofy, dominix, Opsylac, Rozmador, lyn, Julien, Penguin, Luc, serici, pasquin, et 2 anonymes

La deuxième option pour financer des projets d’infrastructure numérique consiste à trouver des mécènes ou des donateurs. Il s’agit d’une pratique courante dans les cas de figure suivants :

• Il n’existe pas de demande client facturable pour les services proposés par le projet.
• Rendre l’accès payant empêcherait l’adoption (on ne pourrait pas, par exemple, faire payer l’utilisation d’un langage de programmation comme Python, car personne ne l’utiliserait ; ce serait comme si parler anglais étant payant).
• Le projet n’a pas les moyens de financer des emplois rémunérés, ou bien il n’y a pas de volonté de la part du développeur de s’occuper des questions commerciales.
• La neutralité et le refus de la commercialisation sont considérés comme des principes importants en termes de gouvernance.

Dans ce type de situation, un porteur de projet cherchera des mécènes qui croient en la valeur de son travail et qui sont disposés à le soutenir financièrement. À l’heure actuelle, il existe deux sources principales de financement : les entreprises de logiciel et les autres développeurs.

Le financement participatif

Certains travaux de développement obtiennent des fonds grâce à des campagnes de financement participatif (« crowdfunding ») via des plateformes telles que Kickstarter ou Indiegogo. Bountysource, le site de récompenses dont nous parlions dans un chapitre précédent, possède également une plateforme appelée Salt dédiée au financement participatif de projets open source.

Andrew Godwin, un développeur du noyau Django résidant à Londres, a ainsi réussi à récolter sur Kickstarter 17952£ (environ 21000€) de la part de 507 contributeurs, afin de financer des travaux de base de données pour Django. Le projet a été entièrement financé en moins de quatre heures.

Pour expliquer sa décision de lever des fonds pour un projet open source, Godwin écrit :

« Une quantité importante de code open source est écrit gratuitement. Cependant, mon temps libre est limité. Je dispose actuellement d’une seule journée libre par semaine pour travailler, et j’adorerais la consacrer à l’amélioration de Django, plutôt qu’à du conseil ou à de la sous-traitance.

L’objectif est double : d’une part, garantir au projet un temps de travail conséquent et au moins 80 heures environ de temps de codage ; et d’autre part prouver au monde que les logiciels open source peuvent réellement rémunérer le temps de travail des développeurs. »

À l’instar des récompenses, le financement participatif s’avère utile pour financer de nouvelles fonctionnalités, ou des développements aboutissant à un résultat clair et tangible. Par ailleurs, le financement participatif a moins d’effets pervers que les récompenses, notamment parce qu’organiser une campagne de financement demande plus d’efforts que de poster une offre de récompense, et parce que le succès du financement repose en grande partie sur la confiance qu’a le public dans la capacité du porteur de projet à réaliser le travail annoncé. Dans le cas de Godwin, il était l’un des principaux contributeurs au projet Django depuis six ans et était largement reconnu dans la communauté.

Toutefois, le financement participatif ne répond pas à la nécessité de financer les frais de fonctionnement et les frais généraux. Ce n’est pas une source de capital régulière. En outre, planifier et mettre en œuvre une campagne de financement participatif demande à chaque fois un investissement important en temps et en énergie. Enfin, les donateurs pour ces projets sont souvent eux-mêmes des développeurs ou des petites entreprises – et un porteur de projet ne peut pas éternellement aller toquer à la même porte pour financer ses projets.

Avec le recul, Godwin a commenté sa propre expérience :

« Je ne suis pas sûr que le financement participatif soit totalement compatible avec le développement open source en général ; non seulement c’est un apport ponctuel, mais en plus l’idée de rétribution est souvent inadéquate car elle nécessite de promettre quelque chose que l’on puisse garantir et décrire a priori.

S’en remettre uniquement à la bonne volonté du public, cela ne fonctionnera pas. On risque de finir par s’appuyer de manière disproportionnée sur des développeurs, indépendants ou non, à un niveau personnel – et je ne pense pas que ce soit viable. »

À côté des campagnes de financement participatif, plusieurs plateformes ont émergé pour encourager la pratique du « pourboire » (tipping en anglais) pour les contributeurs open source : cela consiste à verser une petite somme de revenu régulier à un contributeur, en signe de soutien à son travail. Deux plateformes populaires se distinguent : Patreon (qui ne se limite pas exclusivement aux contributeurs open source) et Gratipay (qui tend à fédérer une communauté plus technique).

L’idée d’un revenu régulier est alléchante, mais souffre de certains problèmes communs avec le financement participatif. On remarque notamment que les parrains (patrons ou tippers en anglais) sont souvent eux-mêmes des développeurs, avec une quantité limitée de capital à se promettre les uns aux autres. Les dons ont généralement la réputation de pouvoir financer une bière, mais pas un loyer. Gratipay rassemble 122 équipes sur sa plateforme, qui reçoivent collectivement 1000 $ par semaine, ce qui signifie qu’un projet touche en moyenne moins de 40$ par mois.

Même les très gros projets tels que OpenSSL ne généraient que 2000$ de dons annuels avant la faille Heartbleed. Comme expliqué précédemment, après Heartbleed, Steve Marquess, membre de l’équipe, a remarqué « un déferlement de soutien de la part de la base de la communauté OpenSSL » : la première vague de dons a rassemblé environ 200 donateurs pour un total de 9000$.

Marquess a remercié la communauté pour son soutien mais a également ajouté :

« Même si ces donations continuent à arriver au même rythme indéfiniment (ce ne sera pas le cas), et même si chaque centime de ces dons allait directement aux membres de l’équipe OpenSSL, nous serions encore loin de ce qu’il faudrait pour financer correctement le niveau de main-d’œuvre humaine nécessaire à la maintenance d’un projet aussi complexe et aussi crucial. Même s’il est vrai que le projet « appartient au peuple », il ne serait ni réaliste ni correct d’attendre de quelques centaines, ou même de quelques milliers d’individus seulement, qu’ils le financent à eux seuls. Ceux qui devraient apporter les vraies ressources, ce sont les entreprises lucratives et les gouvernements qui utilisent OpenSSL massivement et qui le considèrent comme un acquis. »

(À l’appui de l’argument de Marquess, les dons de la part des entreprises furent par la suite plus importants, les sociétés ayant davantage à donner que les particuliers. La plus grosse donation provint d’un fabricant de téléphone chinois, Smartisan, pour un montant de 160000$. Depuis, Smartisan a continué de faire des dons substantiels au projet OpenSSL.)

Au bout du compte, la réalité est la suivante : il y a trop de projets, tous qualitatifs ou cruciaux à leur manière, et pas assez de donateurs, pour que la communauté technique (entreprises ou individus) soit en mesure de prêter attention et de contribuer significativement à chacun d’eux.

Le mécénat d’entreprises pour les projets d’infrastructure

À plus grande échelle, dans certains cas, la valeur d’un projet devient si largement reconnue qu’une entreprise finit par recruter un contributeur pour travailler à plein temps à son développement.

John Resig est l’auteur de jQuery, une bibliothèque de programmation JavaScript qui est utilisée par près des 2/3 du million de sites web les plus visités au monde. John Resig a développé et publié jQuery en 2006, sous la forme d’un projet personnel. Il a rejoint Mozilla en 2007 en tant que développeur évangéliste, se spécialisant notamment dans les bibliothèques JavaScript.

La popularité de jQuery allant croissante, il est devenu clair qu’en plus des aspects liés au développement technique, il allait falloir formaliser certains aspects liés à la gouvernance du projet. Mozilla a alors proposé à John de travailler à plein temps sur jQuery entre 2009 et 2011, ce qu’il a fait.

À propos de cette expérience, John Resig a écrit :

« Pendant l’année et demi qui vient de s’écouler, Mozilla m’a permis de travailler à plein temps sur jQuery. Cela a abouti à la publication de 9 versions de jQuery… et à une amélioration drastique de l’organisation du projet (nous appartenons désormais à l’organisation à but non lucratif Software Freedom Conservancy, nous avons des réunions d’équipe régulières, des votes publics, fournissons des états des lieux publics et encourageons activement la participation au projet). Heureusement, le projet jQuery se poursuit sans encombre à l’heure actuelle, ce qui me permet de réduire mon implication à un niveau plus raisonnable et de participer à d’autres travaux de développement. »

Après avoir passé du temps chez Mozilla pour donner à jQuery le support organisationnel dont il avait besoin, John a annoncé qu’il rejoindrait la Khan Academy afin de se concentrer sur de nouveaux projets.

Cory Benfield, développeur Python, a suivi un chemin similaire. Après avoir contribué à plusieurs projets open source sur son temps libre, il est devenu un développeur-clé pour une bibliothèque essentielle de Python intitulée Requests. Cory Benfield note que :

« Cette bibliothèque a une importance comparable à celle de Django, dans la mesure où les deux sont des « infrastructures critiques » pour les développeurs Python. Et pourtant, avant que j’arrive sur le projet, elle était essentiellement maintenue par une seule personne. »

Benfield estime qu’il a travaillé bénévolement sur le projet environ 12 heures par semaine pendant presque quatre ans, en plus de son travail à plein temps. Personne n’était payé pour travailler sur Requests.

Pendant ce temps, HP embauchait un employé, Donald Stufft, pour se consacrer spécifiquement aux projets en rapport avec Python, un langage qu’il considère comme indispensable à ses logiciels. (Donald est le développeur cité précédemment qui est payé à plein temps pour travailler sur le packaging Python). Donald a alors convaincu son supérieur d’embaucher Cory pour qu’il travaille à temps plein sur des projets Python. Il y travaille toujours.

Les entreprises sont des acteurs tout désignés pour soutenir financièrement les projets bénévoles qu’elles considèrent comme indispensables à leurs activités, et quand des cas comme ceux de John Resig ou de Cory Benfield surviennent, ils sont chaleureusement accueillis. Cependant, il y a des complications.

Premièrement, aucune entreprise n’est obligée d’embaucher quelqu’un pour travailler sur des projets en demande de soutien ; ces embauches ont tendance à advenir par hasard de la part de mécènes bienveillants. Et même une fois qu’un employé est embauché, il y a toujours la possibilité de perdre ce financement, notamment parce que l’employé ne contribue pas directement au résultat net de l’entreprise. Une telle situation est particulièrement périlleuse si la viabilité d’un projet dépend entièrement d’un seul contributeur employé à plein temps. Dans le cas de Requests, Cory est le seul contributeur à plein temps (on compte deux autres contributeurs à temps partiel, Ian Cordasco et Kenneth Reitz).

Une telle situation s’est déjà produite dans le cas de « rvm », un composant critique de l’infrastructure Ruby. Michal Papis, son auteur principal, a été engagé par Engine Yard entre 2011 et 2013 pour soutenir le développement de rvm. Mais quand ce parrainage s’est terminé, Papis a dû lancer une campagne de financement participatif pour continuer de financer le développement de rvm.

Le problème, c’est que cela ne concernait pas seulement rvm. Engine Yard avait embauché plusieurs mainteneurs de projets d’infrastructure Ruby, qui travaillaient notamment sur JRuby, Ruby on Rails 3 et bundler. Quand les responsables d’Engine Yard ont été obligés de faire le choix réaliste qui s’imposait pour la viabilité de leur entreprise, c’est-à-dire réduire leur soutien financier, tous ces projets ont perdu leurs mainteneurs à temps plein, et presque tous en même temps.

L’une des autres craintes est qu’une entreprise unique finisse par avoir une influence disproportionnée sur un projet, puisqu’elle en est de facto le seul mécène. Cory Benfield note également que le contributeur ou la contributrice lui-même peut avoir une influence disproportionnée sur le projet, puisqu’il ou elle dispose de beaucoup plus de temps que les autres pour faire des contributions. De fait, une telle décision peut même être prise par une entreprise et un mainteneur, sans consulter le reste de la communauté du projet.

On peut en voir un exemple avec le cas d’Express.js, un framework important pour l’écosystème Node.js. Quand l’auteur du projet a décidé de passer à autre chose, il en a transféré les actifs (en particulier le dépôt du code source et le nom de domaine) à une société appelée StrongLoop dont les employés avaient accepté de continuer à maintenir le projet. Cependant StrongLoop n’a pas fourni le soutien qu’attendait la communauté, et comme les employés de StrongLoop étaient les seuls à avoir un accès administrateur, il est devenu difficile pour la communauté de faire des contributions. Doug Wilson, l’un des principaux mainteneurs (non-affilié à StrongLoop), disposait encore d’un accès commit et a continué de traiter la charge de travail du projet, essayant tant bien que mal de tout gérer à lui seul.

Après l’acquisition de StrongLoop par IBM, Doug déclara que StrongLoop avait bel et bien tué la communauté des contributeurs.

« Au moment où on est passé à StrongLoop, il y avait des membres actifs comme @Fishrock123 qui travaillaient à créer… de la documentation. Et puis tout à coup, je me suis retrouvé tout seul à faire ça sur mon temps libre alors que les demandes de support ne faisaient que se multiplier… et pendant tout ce temps, je me suis tué à la tâche, je me suis engagé pour le compte StrongLoop. Quoi qu’il arrive, jamais plus je ne contribuerai à aucun dépôt logiciel appartenant à StrongLoop. »

Finalement, le projet Express.js a été transféré de StrongLoop à la fondation Node.js, qui aide à piloter des projets appartenant à l’écosystème technologique Node.js.

En revanche, pour les projets open source qui ont davantage d’ampleur et de notoriété, il n’est pas rare d’embaucher des développeurs. La Fondation Linux a fait savoir, par exemple, que 80% du développement du noyau Linux est effectué par des développeurs rémunérés pour leur travail. La fondation Linux emploie également des Fellows [« compagnons » selon un titre consacré, NdT] payés pour travailler à plein temps sur les projets d’infrastructure, notamment Greg Kroah-Hartman, un développeur du noyau Linux, et Linus Torvalds lui-même, le créateur de Linux.

Nous nous sommes engagés avec la société Smile, spécialisée dans l’intégration de solutions libres, dans un mécénat de compétences autour de la refonte de notre annuaire de logiciels libres, appelé désormais « Framalibre ». Sa mise en œuvre et son suivi seront assurés par Cyrille Assire pour Smile (ci-dessous à droite) et Alexis Kauffmann pour Framasoft (à gauche).

L’annuaire de logiciels libres est le premier projet du réseau Framasoft. C’est celui pour lequel tout a commencé pour nous et même s’il côtoie désormais une vingtaine d’autres projets, il demeure encore le plus fréquenté. Mais force est de constater qu’il a pris la poussière avec le temps, dans le fond comme dans le forme. Il continue à rendre ses services au quotidien mais il a grand besoin d’être mis à jour. Smile va ainsi participer à la refonte ergonomique et graphique du site en nous aidant à repenser globalement le projet et proposer une interface plus fonctionnelle et aboutie.

Le mécénat se distingue du parrainage (sponsoring en anglais) en ce qu’il n’y a pas de contrepartie. Si le mécénat financier ou en nature sont connus, le mécénat de compétences reste un dispositif encore peu répandu. Il permet ici à Smile de mettre à disposition de Framasoft les compétences professionnelles de ses employés pendant leur temps de travail (et sans aucune perte financière). Il donne un nouveau visage au mécénat en le rendant plus solidaire et participatif et permet de faire en sorte que les entreprises et les associations se rencontrent et se rapprochent. Framasoft étant une association reconnue d’intérêt général, Smile va pouvoir déduire de son IS (Impôt sur les Sociétés) 60% des salaires chargés des collaborateurs missionnés, au prorata des heures effectuées pour nous.

Nous vous tiendrons régulièrement au courant des avancées de ce partenariat. Et nous serions ravis de voir d’autres entreprises prendre le sillage de Smile dans le mécénat de compétences parce que ce ne sont pas les besoins qui manquent dans le Libre associatif.

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